Roteamento IPSec de site a site (Ubuntu, StrongSwan)

Question

Estou preso ao tentar conectar duas redes.

SiteA : é um número de VPS em diferentes locais e estações de trabalho de escritório conectadas com o OpenVPN em uma rede privada 10.113.0.0/24. Cada um tem seu próprio acesso à Internet e gateway padrão. O servidor OpenVPN possui o ip público 95.95.95.95 e também significa o terminal IPSec.

SiteB : é uma rede privada criada na nuvem VMWare atrás do Edge Gateway com o ip público 212.212.212.212.

O problema é que os hosts no SiteB não podem ser acessados pelos hosts no SiteA. Enquanto isso, eles são acessíveis diretamente do terminal do SiteA. Tenho certeza de que perdi algo muito simples e óbvio.

configurações do SiteA Endpoint

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)

Conexão 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 do Endpoint está OK

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

Política de 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

Tabela de rotas:

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   

Configuração do VPS do siteA

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)

Eu adicionei uma rota estática

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 mostra que o pacote é enviado para 10.113.0.1, mas parece que não foi roteado para o IPSec lá.

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  * * *

O que está mal configurado? Obrigado !!

Editado após comentários de @MadHatter:

Tcpdump do pedido 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 da resposta do ACMP no ServerA após o tráfego ter retornado ao túnel de formulário:

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

Lista de todas as regras do iptables. Como disse @MadHatter nos comentários, o encaminhamento deve estar ativado por padrão. Mas eu mencionei que é para tun0 - > tráfego eth0, mas para eth0 - > tun0 isso não acontece.

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      

Eu adicionei a regra de encaminhamento para eth0 - > tun0

iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

E é magigamente trabalhado! 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 no Karma para o @MadHatter.

    

Answer 1

Usamos tcpdump para examinar o tráfego de entrada e saída dos dois nós de firewall. Observo de passagem que tcpdump com {Open, Libre, Strong} S / WAN em um kernel moderno pode ser um pouco problemático, porque na interface a partir da qual o tráfego criptografado vai e vem, o tráfego de texto plano somente quando sai e não quando chega.

No entanto, usando tcpdump para acompanhar o fluxo, estabelecemos que as solicitações de eco ICMP estão indo da rede A para a rede B, e as respostas estão chegando até o servidorA (a rede Um servidor OpenVPN / IPSec tunnel collapse point), mas eles não estão passando por ele para o cliente OpenVPN.

Como o tráfego está sendo encaminhado para saída, não há nenhum problema geral com o encaminhamento de tráfego e, portanto, suspeitamos de regras de firewall. Você adicionou uma regra para permitir o encaminhamento do tráfego da rede externa para a interface tun0 do OpenVPN e resultou em conectividade completa.

Você pode querer refinar essa regra ligeiramente, por exemplo, para que ela seja explicitamente aplicada ao tráfego que chegou por meio de uma conexão IPSec

iptables -A FORWARD -i eth0 -o tun0 -m policy --pol ipsec --dir in -j ACCEPT

ou talvez para torná-lo com conhecimento de estado, mas esses são refinamentos e estão à sua disposição.