4 votes

subnet-to-subnet libreswan ipsec vpn

Je suis en train de configurer un "VPN de sous-réseau à sous-réseau" entre deux serveurs Centos 7 en utilisant libreswan. Chaque serveur a deux réseaux comme indiqué dans l'image suivante.

Je voudrais permettre une communication sécurisée entre les sous-réseaux 172.18.0.0/16 et 172.19.0.0/16 en établissant un vpn utilisant le réseau 172.17.0.0/16 mais j'ai des problèmes pour autoriser le trafic entre ces deux sous-réseaux.

J'ai suivi la documentation officielle de redhat dans https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_Virtual_Private_Networks.html#Site-To-Site_VPN_Using_Libreswan

En fait, j'ai arrêté firewalld sur les deux noeuds.

J'ai vérifié les prérequis d'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]

Le contenu du fichier ipsec.conf est :

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

Je démarre le service ipsec sur les deux nœuds. Puis je vérifie que "ipsec status" (ici il y a la sortie http://pastebin.com/LYA9uqfJ ) et je n'ai pas trouvé d'erreur.

La table de routage du noeud1 est :

[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

Si j'essaie de faire un ping à partir du nœud 1 dont l'adresse IP est 172.19.0.101, j'obtiens l'erreur "connect : Network is unreachable"

Y a-t-il quelque chose qui manque dans ma configuration ? Que puis-je essayer pour permettre un trafic sécurisé entre ces deux sous-réseaux ?

0voto

wilful Points 1

Vérifiez net.ipv4.ip_forward paramètres dans sysctl .

Ou vous pouvez essayer d'exécuter tcpdump des deux côtés et regarder ce qui se passe.

Ejemplo:

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

Essayez également d'ajouter des règles iptables comme ceci :

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

Quelques détails supplémentaires sur ce qui précède :

  • EXTIF est votre interface 172.17.0.0/16

  • INIF est un autre 172.18.0.0 ou 172.19.0.0

J'ai été utilisé il est HOWTO, mon réseau fonctionne, mais pas l'envoi de paquet keepalive. Strongswan n'a pas de problème

0voto

ecdsa Points 3630

connecter : Le réseau est inaccessible

Avec seulement des routes vers 172.17.0.0/16 y 172.18.0.0/24 il n'y a pas de route spécifique pour 172.19.0.0/16 ou une route par défaut qui le couvrirait, c'est pourquoi vous obtenez cette erreur.

Vous devez donc ajouter soit une route spécifique vers le sous-réseau distant, soit une route par défaut sur les deux hôtes.

Au fait, vous devriez utiliser ip route pour gérer les routes au lieu de route .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X