sub-rede para sub-rede libreswan ipsec vpn

2

Estou configurando uma "sub-rede para VPN de sub-rede" entre dois servidores Centos 7 usando o libreswan. Cada servidor tem dois nic como mostrado na imagem a seguir.

Eu permitiria comunicação segura entre as sub-redes 172.18.0.0/16 e 172.19.0.0/16 estabelecendo uma vpn usando a rede 172.17.0.0/16, mas tenho problemas para permitir o tráfego entre essas duas sub-redes.

Euseguiadocumentaçãooficialdoredhatem link

Na verdade, parei de usar o firewall em ambos os nós.

Eu verifiquei os pré-requisitos do ipsec:

[root@node2 ~]# ipsec verify
Verifying installed system and configuration files

Version check and ipsec on-path                         [OK]
Libreswan 3.8 (netkey) on 3.10.0-123.el7.x86_64
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Pluto ipsec.conf syntax                                 [OK]
Hardware random device                                  [N/A]
Two or more interfaces found, checking IP forwarding    [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto ipsec.secret syntax                              [OK]
Checking NAT and MASQUERADEing                          [TEST INCOMPLETE]
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]
Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options                 [OK]
Opportunistic Encryption                                [DISABLED]

O conteúdo do ipsec.conf é:

config setup
    protostack=netkey

conn mytunnel
    leftid=@node1
    left=172.17.0.101
    leftrsasigkey=0sAQPXn...        
    rightid=@node2
    right=172.17.0.102
    rightrsasigkey=0sAQPxv...
    authby=rsasig

conn mysubnet
     also=mytunnel
     leftsubnet=172.18.0.0/16
     rightsubnet=172.19.0.0/16
     auto=start

Eu inicio o serviço ipsec em ambos os nós. Então eu verifico que "status ipsec" (aqui está o link ) e não encontrei nenhum erro.

A tabela de roteamento do node1 é:

[root@node1 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eno16777736
172.18.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eno33554992

Se tentar pingar do node1 o endereço IP 172.19.0.101, obtenho o erro "connect: Network is unreachable"

Há algo faltando na minha configuração? O que eu posso tentar para permitir o tráfego seguro entre essas duas sub-redes?

    
por NoNoNo 21.03.2015 / 21:01

2 respostas

0

Verifique as configurações de net.ipv4.ip_forward em sysctl .

Ou você pode tentar executar o tcpdump em ambos os lados e ver o que acontece.

Exemplo:

tcpdump -n -i interface esp or udp port 500 or udp port 4500

Tente também adicionar regras de iptables como esta:

-A FORWARD -i EXTIF -o INIF -j ACCEPT
-A FORWARD -i INIF -o EXTIF -j ACCEPT
-A POSTROUTING -s YOURNET1 ! -d YOURNET2 -j MASQUERADE

Mais alguns detalhes sobre o que está acima:

  • EXTIF é sua interface 172.17.0.0/16

  • INIF é outro 172.18.0.0 ou 172.19.0.0

Eu estava acostumado é COMO, minha rede está funcionando, mas não enviando pacote keepalive. Strongswan não tem problemas

    
por 01.04.2016 / 10:13
0

connect: Network is unreachable

Com apenas rotas para 172.17.0.0/16 e 172.18.0.0/24 , não há uma rota específica para 172.19.0.0/16 ou uma rota padrão que a cobriria, e é por isso que você recebe esse erro.

Portanto, você precisa adicionar uma rota específica à sub-rede remota ou adicionar uma rota padrão nos dois hosts.

A propósito, você deve usar ip route para gerenciar rotas em vez de route .

    
por 24.05.2018 / 17:37