Pacotes de clientes não encaminhados através do túnel strongswan IPsec site-a-site para cliente e gateway no mesmo servidor

1

Eu tenho um túnel IPsec site-to-site configurado com strongSwan entre meu servidor virtual privado do CentOS 7 (IP público xxx233 para sub-rede 172.25.10.0/24) e a rede de um cliente (IP público yyy24 para sub-rede 10.9. 200,0 / 24). O túnel parece estar se conectando bem, mas não consigo tráfego para passar por ele. Estou tentando configurar a sub-rede 172.25.10.0/24 no mesmo host que está atuando como o gateway, que presumo ter feito incorretamente.

A seção conn do ipsec.conf no VPS é:

conn customer
    esp=aes256-sha1-modp1024
    ike=aes256-sha1-modp1024
    keyexchange=ikev1
    authby=psk
    left=%defaultroute
    leftsubnet=172.25.10.0/24
    leftfirewall=yes
    right=y.y.y.24
    rightsubnet=10.9.200.0/24
    auto=start

Tanto quanto eu posso dizer, o próprio túnel está funcionando bem. strongswan statusall no VPS mostra:

Security Associations (1 up, 0 connecting):
      customer[29]: ESTABLISHED 110 minutes ago, x.x.x.233[x.x.x.233]...y.y.y.24[y.y.y.24]
      customer[29]: IKEv1 SPIs: 0123456789abcdef_i* 0123456789abcdef_r, pre-shared key reauthentication in 50 minutes
      customer[29]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      customer{88}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: 01234567_i 01234567_o
      customer{88}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 7 minutes
      customer{88}:   172.25.10.0/24 === 10.9.200.0/24

Eu configurei um IP de sub-rede (172.25.10.2) no VPS na mesma interface que mantém o IP público (x.x.x.233) com:

ip addr add 172.25.10.2/32 dev eth0

Mas quando faço ping em um IP na rede remota do VPS, o ping está falhando:

# ping -I 172.25.10.2 -c 3 10.9.200.254
PING 10.9.200.254 (10.9.200.254) from 172.25.10.2 : 56(84) bytes of data.

--- 10.9.200.254 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Um tcpdump mostra que o túnel IPsec não está sendo usado:

# tcpdump -n host 10.9.200.254 or host y.y.y.24
03:51:07.193494 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 1, length 64
03:51:08.193449 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 2, length 64
03:51:09.193452 IP x.x.x.233 > 10.9.200.254: ICMP echo request, id 10193, seq 3, length 64

Suponho que apenas adicionar o IP 172.25.10.2 a eth0 não é suficiente para descobrir que meu tráfego deve ser roteado pelo túnel, mas não tenho certeza de qual é a maneira correta de fazê-lo é.

Por que vale a pena, eu também executei os seguintes comandos antes de ativar o strongSwan:

# echo "net.ipv4.ip_forward=1" > /etc/sysctl.conf
# sysctl -p
# firewall-cmd --zone=public --permanent --add-service="ipsec"
# firewall-cmd --zone=public --permanent --add-port=4500/udp
# firewall-cmd --zone=public --permanent --add-masquerade
# firewall-cmd --reload

Caso contrário, não toquei nas regras de configuração / roteamento da máquina / etc.

    
por Ben 04.12.2017 / 14:22

2 respostas

1

O tráfego IPsec deve ser roteado, você provavelmente atingiu o problema NAT padrão da regra NAT padrão que afeta o tráfego IPsec. O remédio é:

iptables -t nat -I POSTROUTING 1 -m policy --pol ipsec --dir out -j ACCEPT

Ou um comando equivalente com firewall-cmd --add-rule .

    
por 04.12.2017 / 18:15
0

Se você tiver alguma regra de NAT configurada, como MASQUERADE via --add-masquerade , precisará excluir o tráfego que corresponde a uma diretiva IPsec. Caso contrário, o tráfego será apenas direcionado para o IP público e não corresponderá mais à diretiva IPsec e não passará pelo túnel. Conforme descrito no wiki strongSwan , você precisa inserir uma regra como a seguinte (antes de qualquer regra NAT, que -I tenta fazer se as regras NAT já estiverem em vigor):

iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT

Também pode ser mais específico, se necessário (por exemplo, para incluir apenas determinados IPs de origem). Eu não sei firewall-cmd , então não sei como você faria isso lá. Mas algo como o seguinte (executado antes da linha --add-masquerade ) pode funcionar:

firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 -m policy --pol ipsec --dir out -j ACCEPT
    
por 04.12.2017 / 18:19