Назад | Перейти на главную страницу

Маршрутизация 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 от конечной точки в порядке

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

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.

traceroute 10.200.0.1
traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets
 1  10.113.0.1 (10.113.0.1)  1.887 ms  2.453 ms  2.452 ms
 2  * * *

Что неправильно настроено? Спасибо!!

Отредактировано после комментариев @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

или, возможно, сделать это с учетом состояния, но это уточнения, которые зависят от вас.