web-dev-qa-db-fra.com

Routage IPsec sur site à site (Ubuntu, STUDSWAN)

Je suis coincé à essayer de connecter deux réseaux.

enter image description here

SITEA: est un certain nombre de VPS dans différents emplacements et postes de travail de bureau liés à OpenVPN dans un réseau privé 10.113.0.0/24. Chacun a son propre accès Internet et une passerelle par défaut. OpenVPN Server dispose d'une adresse IP publique 95.95.95.95 et représente également le point d'extrémité IPSec.

SITEB: est une construction réseau privée sur VMware Cloud derrière la passerelle Edge avec IP publique 212.212.212.212.

Le problème est que les hôtes de Siteb ne sont pas accessibles d'hôtes dans Sitea. En attendant, ils sont directement accessibles à partir du point de terminaison Sitea. Je suis sûr que j'ai manqué quelque chose de vraiment simple et évident.

Sitea EndPoint Configs

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)

Connexion 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 du point final 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

Politique 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

Table des itinéraires:

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   

Sitea VPS config

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)

J'ai ajouté une route statique

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 montre que le paquet est envoyé à 10.113.0.1 mais comme cela ne me semble pas acheminé vers ipsec là-bas.

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

Qu'est-ce qui est mal configuré? Merci!!

édité après @madhatter commente:

Tcpdump de la demande 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 de la réponse ACMP sur Servera après le transfert de la circulation Tunnel:

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

Liste de toutes les règles d'IPTABLES. Comme @madhatter a déclaré dans le renvoi des commentaires doit être sur défaut. Mais j'ai mentionné que c'était pour Tun0 -> Trafic Eth0, mais pour Eth0 -> Tun0, ce n'est pas le cas.

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      

J'ai ajouté la règle avant pour Eth0 -> Tun0

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

Et c'est magigentalement travaillé! 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 au karma pour le @madhatter.

5
Ivan Yaremchuk

Nous avons utilisé tcpdump pour examiner le trafic dans et sortir des deux nœuds de pare-feu. Je remarque en passant que tcpdump avec {Open, Libre, Strong} S/WAN dans un noyau moderne peut être un peu problématique, car sur l'interface sur laquelle le trafic crypté vient et va voir le trafic clair seulement quand il part et pas quand il arrive.

Néanmoins, en utilisant tcpdump _ Pour suivre le flux, nous avons établi que les demandes ECHO-Demandes ICMP obtiennent tout le chemin du réseau A au réseau B, et les réponses deviennent aussi loin que Servera (le réseau A OpenVPN Server/Point d'effondrement du tunnel IPsec), mais ils ne le transmettent pas au client OpenVPN.

Étant donné que le trafic est transféré en sortant, il n'existe aucun problème général avec le transfert de trafic et nous soupçonnons donc les règles de pare-feu. Vous avez ajouté une règle pour permettre le transfert du trafic du réseau externe à l'OpenVPN tun0 Interface et la connectivité complète a abouti.

Vous voudrez peut-être affiner cette règle légèrement, par exemple pour l'avoir explicitement applicable au trafic qui est arrivé via une connexion IPSec

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

ou peut-être pour le rendre stipuleusement informé, mais ce sont des raffinements et sont à vous.

7
MadHatter