Не может соединиться в подсеть через StrongSWAN VPN
Это - упрощение большей проблемы, которую я испытываю, но я думаю, что это покрывает все. Производственная проблема между StrongSWAN VPN и Juniper SSG550. Настройка сети ясно не идеальна, но я наследовал ее, и клиент не желает изменить что-либо, если не абсолютно необходимо.
Существует подсеть подсети StrongSWAN VPN между экземпляром EC2 Bob и другим экземпляром non-EC2 George. Существует также другой экземпляр EC2 Fred в той же подсети как Bob.
Bob и George являются чистыми установками Ubuntu. 14.04 и 14.10 соответственно. Fred является Oracle Сервер Linux 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 файлы следующие:
Bob:
# 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
George:
# 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 George.
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
...
Проблема, которую я имею, состоит в том, что трафик от George Fred не добирается там. Трафик от Fred George делает. Bob и Fred могут оба проверить с помощью ping-запросов George. George может проверить с помощью ping-запросов Bob.
Я настроил сокет слушания на порте 4000 на всех трех экземплярах. Bob и Fred могут и соединиться с тем на George и George, может соединиться с тем на Bob. Очевидно, Bob и Fred могут соединиться друг с другом.
Вот tcpdump для соединения от George Fred, как замечено на Bob.
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
Ничто не замечено на Fred.
Правила iptables для двух экземпляров EC2 следующие:
Bob:
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:
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 и Split Tunneling .
На самом деле было две проблемы, хотя только одна в этом тестовый сценарий.
Мне потребовалась магия маскировки 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
Теперь все работает.