Je suis coincé à essayer de connecter deux réseaux.
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.
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.