Маршрутизация IPSec между сайтами (Ubuntu, StrongSwan)
Я застрял в попытке соединить две сети.
SiteA : это несколько VPS в разных местах и офисных рабочих станций, подключенных к OpenVPN в частной сети 10.113.0.0/ 24. У каждого есть собственный доступ в Интернет и шлюз по умолчанию. Сервер OpenVPN имеет общедоступный IP-адрес 95.95.95.95 и также обозначает конечную точку IPSec.
SiteB : это частная сеть, построенная на облаке VMWare за пограничным шлюзом с общедоступным IP-адресом 212.212.212.212.
Проблема в том, что к хостам в SiteB нельзя получить доступ с хостов в SiteA. Между тем они доступны напрямую с конечной точки SiteA. Я уверен, что пропустил что-то действительно простое и очевидное.
Конфигурации конечной точки SiteA
Ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:00:46:76:84
inet addr:95.95.95.95 Bcast:95.95.95.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:249492177 errors:0 dropped:395296 overruns:0 frame:0
TX packets:13730009 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39576084672 (39.5 GB) TX bytes:8388420192 (8.3 GB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.113.0.1 P-t-P:10.113.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:13968 errors:0 dropped:0 overruns:0 frame:0
TX packets:11554 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1069136 (1.0 MB) TX bytes:4425784 (4.4 MB)
Соединение IPSec:
conn portal-vcd
authby=secret
auto=start
## phase 1 ##
ike=aes128-md5-modp1024
ikelifetime=28800
keyexchange=ikev1
## phase 2 ##
esp=aes128-sha1-modp2048
type=tunnel
leftid=95.95.95.95
left=95.95.95.95
leftsubnet=10.113.0.0/24
rightid=212.212.212.212
right=212.212.212.212
rightsubnet=10.200.0.0/24
Traceroute from Endpoint в порядке
traceroute 10.200.0.1
traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets
1 10.200.0.254 (10.200.0.254) 3.042 ms 2.979 ms 2.943 ms
2 10.200.0.1 (10.200.0.1) 3.457 ms 3.472 ms 3.051 ms
Политика IP xfrm:
ip xfrm policy
src 10.113.0.0/24 dst 10.200.0.0/24
dir out priority 2883
tmpl src 95.95.95.95 dst 212.212.212.212
proto esp reqid 1 mode tunnel
Таблица маршрутов:
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 95.95.95.254 0.0.0.0 UG 0 0 0 eth0
10.113.0.0 * 255.255.255.0 U 0 0 0 tun0
95.95.95.0 * 255.255.255.0 U 0 0 0 eth0
IPTABLES NAT:
Chain POSTROUTING (policy ACCEPT 174 packets, 12723 bytes)
num pkts bytes target prot opt in out source destination
1 96 5928 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec
2 0 0 MASQUERADE all -- * eth0 10.113.0.0/24 0.0.0.0/0
SiteA VPS Config
Ifconfig:
eth0 Link encap:Ethernet HWaddr 00:00:00:34:22:23
inet addr:178.X.X.X Bcast:178.X.X.255 Mask:255.255.254.0
inet6 addr: fe80::200:ff:fe34:2223/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5599082 errors:0 dropped:48196 overruns:0 frame:0
TX packets:300211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:918538724 (918.5 MB) TX bytes:706426556 (706.4 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.113.0.2 P-t-P:10.113.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:384 errors:0 dropped:0 overruns:0 frame:0
TX packets:1590 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:80459 (80.4 KB) TX bytes:124217 (124.2 KB)
Я добавил статический маршрут
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 178.X.X.X 0.0.0.0 UG 0 0 0 eth0
10.113.0.0 * 255.255.255.0 U 0 0 0 tun0
10.200.0.0 10.113.0.1 255.255.255.0 UG 0 0 0 tun0
178.X.X.0 * 255.255.254.0 U 0 0 0 eth0
Traceroute показывает, что пакет отправляется на 10.113.0.1, но, как мне кажется, не маршрутизируется на IPSec там. 1216] Что неправильно сконфигурировано? Спасибо !!
Отредактировано после комментариев @MadHatter:
Tcpdump запроса ICMP #ServerA tun0:
tcpdump -n -n -i tun0 host 10.200.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
08:52:32.011631 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 10, length 64
08:52:33.011614 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 11, length 64
Tcpdump ответа ACMP на ServerA после возврата трафика из туннеля:
tcpdump -n -n -i eth0 host 10.200.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:52:45.014288 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 23, length 64
08:52:46.014010 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 24, length 64
Список всех правил iptables. Как сказал @MadHatter в комментариях, пересылка должна быть включена по умолчанию. Но я упоминал, что это для трафика tun0 -> eth0, а для eth0 -> tun0 - нет.
iptables -L -n -v
Chain INPUT (policy ACCEPT 3380K packets, 1704M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 1095 packets, 91824 bytes)
pkts bytes target prot opt in out source destination
2886 236K DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0
2886 236K DOCKER-ISOLATION all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1020 85632 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
637 47172 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 105K packets, 13M bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
2886 236K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
24177 70M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Я добавил правило пересылки для eth0 -> tun0
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
И оно волшебным образом сработало! HostA:
ping 10.200.0.1
PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data.
64 bytes from 10.200.0.1: icmp_seq=1 ttl=62 time=3.17 ms
64 bytes from 10.200.0.1: icmp_seq=2 ttl=62 time=2.88 ms
+1 в карме для @MadHatter.
Мы использовали tcpdump для проверки входящего и исходящего трафика двух узлов межсетевого экрана. Попутно отмечу, что tcpdump с {Open, Libre, Strong} S / WAN в современном ядре может быть немного проблематичным, потому что на интерфейсе, из которого приходит и уходит зашифрованный трафик, виден открытый текст трафик только тогда, когда он уходит из , а не когда он приходит.
Тем не менее, используя tcpdump для отслеживания потока, мы установили, что эхо-запросы ICMP проходят весь путь от сеть A в сеть B, и ответы поступают так далеко, как serverA (точка обрушения сервера OpenVPN сети A / туннеля IPSec), но они не проходят через нее клиенту OpenVPN.
Поскольку трафик перенаправляется исходящим , общих проблем с пересылкой трафика нет, поэтому мы подозреваем правила брандмауэра. Вы добавили правило, разрешающее пересылку трафика из внешней сети на интерфейс OpenVPN tun0 , и в результате получилось полное подключение.
Возможно, вы захотите немного уточнить это правило, например, сделать его явно применяются к трафику, который поступает через соединение IPSec
iptables -A FORWARD -i eth0 -o tun0 -m policy --pol ipsec --dir in -j ACCEPT
, или, возможно, для того, чтобы сделать его с учетом состояния, но это уточнения и ваше усмотрение.