Это упрощение более серьезной проблемы, с которой я столкнулся, но я думаю, что она охватывает все. Производственная проблема возникает между StrongSWAN VPN и Juniper SSG550. Настройка сети явно не идеальна, но я унаследовал ее, и клиент не желает ничего менять без крайней необходимости.
Между экземпляром EC2 Боба и другим экземпляром, не относящимся к EC2, Джорджем, есть подсеть-подсеть StrongSWAN VPN. В той же подсети, что и Боб, есть еще один экземпляр EC2, Фред.
Боб и Джордж установили чистую Ubuntu. 14.04 и 14.10 соответственно. Фред - Oracle Linux Server 10.5
Для всех экземпляров EC2 отключена проверка источника / назначения.
---------------------- ----------------------
| | | |
| 192.168.1.0/24 | | 10.0.1.0/24 |
| | | |
| ---------------- | | ---------------- |
| | Bob | | | | George | |
| | 192.168.1.12 | | StrongSWAN | | 10.0.1.22 | |
| | |<-------------------->| | |
| | StrongSWAN | | | | StrongSWAN | |
| | | | | | | |
| ---------------- | | ---------------- |
| | | |
| ---------------- | ----------------------
| | Fred | |
| | 192.168.1.28 | |
| | | |
| ---------------- |
| |
----------------------
Файлы ipsec.conf следующие:
Боб:
# Connections into AWS VPC
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn client
keyexchange=ikev1
ikelifetime=24h
ike=aes256-sha2_256-modp1024
esp=aes256-sha2_256-modp1024
aggressive=no
lifetime=1h
leftsubnet=192.168.0.0/16
leftid=@vpn.amazon.com
leftfirewall=yes
rightfirewall=yes
right=PUBLIC_IP_OF_GEORGE
rightsubnet=10.0.1.0/24
rightid=@client.xxxx.com
auto=add
Джордж:
# Connections into AWS VPC
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn client
keyexchange=ikev1
lifetime=24h
ike=aes256-sha2_256-modp1024
esp=aes256-sha2_256-modp1024
aggressive=no
leftfirewall=yes
leftsubnet=10.0.1.0/24
leftid=@client.xxxx.com
right=PUBLIC_IP_OF_BOB
rightsubnet=192.168.0.0/16
rightid=@vpn.amazon.com
auto=add
Я также добавил маршрут от Фреда до Джорджа.
Fred> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.1.0 192.168.1.12 255.255.255.0 UG 0 0 0 eth0
...
У меня проблема в том, что трафик от Джорджа до Фреда не идет. Движение от Фреда до Джорджа. Боб и Фред оба могут позвонить Джорджу. Джордж может пинговать Боба.
Я установил прослушивающий сокет на порту 4000 на всех трех экземплярах. И Боб, и Фред могут подключиться к тому, что у Джорджа, а Джордж может подключиться к тому, что у Боба. Очевидно, Боб и Фред могут подключаться друг к другу.
Вот tcpdump для соединения Джорджа с Фредом, как показано на Бобе.
Bob> tcpdump port 4000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:55:37.791967 IP 10.0.1.22.46014 > 192.168.1.28.4000: Flags [S], seq 2922469699, win 29200, options [mss 1460,sackOK,TS val 3459391 ecr 0,nop,wscale 7], length 0
11:55:37.792052 IP 10.0.1.22.46014 > 192.168.1.28.4000: Flags [S], seq 2922469699, win 29200, options [mss 1460,sackOK,TS val 3459391 ecr 0,nop,wscale 7], length 0
11:55:38.792116 IP 10.0.1.22.46014 > 192.168.1.28.4000: Flags [S], seq 2922469699, win 29200, options [mss 1460,sackOK,TS val 3459641 ecr 0,nop,wscale 7], length 0
11:55:38.792188 IP 10.0.1.22.46014 > 192.168.1.28.4000: Flags [S], seq 2922469699, win 29200, options [mss 1460,sackOK,TS val 3459641 ecr 0,nop,wscale 7], length 0
11:56:07.434645 IP 10.0.1.22.46015 > 192.168.1.28.4000: Flags [S], seq 459738226, win 29200, options [mss 1460,sackOK,TS val 3466802 ecr 0,nop,wscale 7], length 0
11:56:07.434722 IP 10.0.1.22.46015 > 192.168.1.28.4000: Flags [S], seq 459738226, win 29200, options [mss 1460,sackOK,TS val 3466802 ecr 0,nop,wscale 7], length 0
11:56:08.436531 IP 10.0.1.22.46015 > 192.168.1.28.4000: Flags [S], seq 459738226, win 29200, options [mss 1460,sackOK,TS val 3467052 ecr 0,nop,wscale 7], length 0
11:56:08.436601 IP 10.0.1.22.46015 > 192.168.1.28.4000: Flags [S], seq 459738226, win 29200, options [mss 1460,sackOK,TS val 3467052 ecr 0,nop,wscale 7], length 0
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
На Фреде ничего не видно.
Правила iptables для двух экземпляров EC2 следующие:
Боб:
Bob> iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.0.1.0/24 192.168.0.0/16 policy match dir in pol ipsec reqid 1 proto esp
ACCEPT all -- 192.168.0.0/16 10.0.1.0/24 policy match dir out pol ipsec reqid 1 proto esp
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Фред:
Fred> iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Будем очень признательны за любые предложения относительно того, в чем может заключаться проблема. На данный момент я не уверен, проблема ли это в EC2 или в сети.
Мне удалось решить мою проблему с небольшой помощью из комментариев выше, tcpdump и Раздельное туннелирование.
Фактически было две проблемы, хотя в этом тестовом сценарии только одна.
Мне нужна была магия маскировки iptables
Bob> iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -m policy --dir out --pol ipsec -j ACCEPT
Bob> iptables -t nat -D POSTROUTING -s 10.0.1.0/24 -j MASQUERADE
При производстве возникла дополнительная сложность, связанная с тем, что сторона EC2 VPN (в то время как в подсети 192.168.1.0/24) была подсетью 172.22.70.192/28. Это потребовало некоторой магии маршрутизации, чтобы гарантировать, что пакеты от Фреда (eth0 10.0.1.28, eth0: 0 172.22.70.194) до Джорджа прибыли к Бобу (eth0 10.0.1.12, eth0: 0 172.22.70.193) с правильным IP-адресом.
Fred> ip route add 10.0.1.0/24 via 192.168.1.12 dev eth0:0 src 172.22.70.194
Теперь все работает.