Openswan encapsula, mas funciona apenas em uma direção

Question

Eu estabeleci com sucesso uma conexão IPsec, mas funciona apenas parcialmente. Um lado não envia pacotes pelo túnel. Parece que a topologia da rede não está clara para esse lado.

Qualquer ajuda é muito apreciada! Obrigado !!

Este é o esquema de rede:

"office"(192.168.73.0/24) == "vpn"(192.168.73.1) == "router"(6.6.6.6) <====> "server"(7.7.7.7) == "VM_LAN"(192.168.133.0/24)

6.6.6.6 e 7.7.7.7 são IPs públicos simbólicos, ou seja, "roteador" e "servidor" estão diretamente conectados à Internet.

"vpn" e "server" ambos executam o CentOS 6. "roteador" é um modem a cabo, fazendo o NAT e o encaminhamento de porta.

A conexão é estabelecida.

Em "vpn" eu posso pingar o IP interno do "servidor":

[root@vpn]# ping 192.168.133.1
PING 192.168.133.1 (192.168.133.1) 56(84) bytes of data.
64 bytes from 192.168.133.1: icmp_seq=1 ttl=64 time=74.8 ms

Em "servidor" não consigo pingar "vpn", não há nem mesmo um pacote enviado.

O seguinte é um dump de "server" mostrando o pacote ping acima. Eu uso o mesmo comando para testar se os pacotes são enviados de "server" para "vpn", ao pingar de "server", mas nenhum pacote é exibido para cima.

[root@server]# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:40:21.793577 IP 6.6.6.6.ipsec-nat-t > 7.7.7.7.ipsec-nat-t: UDP-encap: ESP(spi=0x712a1d37,seq=0x2), length 132
14:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,seq=0x2), length 132

A verificação do ipsec parece ok:

[root@server]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.2.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing for disabled ICMP send_redirects              [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

iptables está desativado:

[root@server]# iptables -L -n
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


[root@server]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
7.7.7.7         0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         7.7.7.1         0.0.0.0         UG    0      0        0 eth0

Meu ipsec.conf:

config setup
    # Debug-logging controls:  "none" for (almost) none, "all" for lots.
    # klipsdebug=none
    # plutodebug="control parsing"
     plutodebug="all"
    # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
    protostack=netkey
    nat_traversal=yes
    virtual_private="%v4:192.168.73.0/24"
    oe=off
    # Enable this if you see "failed to find any available worker"
    # nhelpers=0

conn aaa-office
    authby=secret
    left=7.7.7.7
    leftsubnet=192.168.133.0/24
    right=6.6.6.6
    rightsubnet=192.168.73.0/24
    rightid=192.168.73.8
    auto=add

    

Answer 1

Eu respondo a mim mesmo e espero que essa informação seja útil para outras pessoas com o mesmo problema.

A causa principal foi que os pacotes do "servidor" não foram roteados pelo túnel. Usando ip xfrm policy , pude ver que a política de roteamento através do túnel é que os pacotes precisam ser originados em 192.168.133.0/24.

Um ping de "servidor" para "vpn" resultou nestes pacotes:

17:29:16.549349 IP 7.7.7.7 > 192.168.73.8: ICMP echo request, id 43864, seq 1, length 64

Então, ao fazer o ping, o IP de origem usado naturalmente era o IP público do servidor. Este não era o caso da máquina "vpn", já que esta máquina já estava na sub-rede. O problema foi resolvido quando adicionei a seguinte declaração ao arquivo de configuração de "servidor":

leftsourceip=192.168.133.1

Agora as coisas funcionam como esperado e eu posso alcançar a sub-rede por trás de "vpn" de "servidor".

    

Answer 2

Não conheço o openswan, mas: em um túnel VPN, verifique se você tem uma VPN baseada em rota ou baseada em política. ie. se for baseado em uma rota, deve haver uma rota que diz "leva essa interface de túnel para chegar à rede do 192.168.73.1". Se for baseado em políticas, deve haver uma política que diz "tráfego de origem do x enviado para o destino y = túnel no túnel da VPN"

Desculpe ... removi muito ... pouca compreensão de leitura ... Eu vejo as informações na interface LAN / IP do seu servidor agora e percebo que você está tentando fazer o ping daquele IP de origem de 192.168.133.1.

Eu ainda verificaria se uma política ou rota no openswan é definida no lado do servidor para a origem de tráfego 192.168.133.0/24 destinada a 192.168.73.0/24 e verifique se ele usa o encapsulamento. Parece que o tráfego não está usando o túnel, mas fazendo algo como:

192.168.133.1 - - tentando pingar 192.168.73.1 (o que falharia)