☰

SNAT funktioniert nicht, um die echte Client-IP zu behalten, MASQUERADE funktioniert

tag-icon • tag-icon openvpn nat masquerade
SNAT funktioniert nicht, um die echte Client-IP zu behalten, MASQUERADE funktioniert

Ich habe 3 Hosts: AAA, BBB, CCC.

  1. GastgeberAAAist einOpenVPN-Serverr mit IP172.17.10.1und Maske 255.255.255.0.
  2. GastgeberBBBhat 2 Tun-Schnittstellen: • eineOpenVPN-Servermit IP172.16.10.1und Maske 255.255.255.0 • eineOpenVPN-Clientmit IP172.17.10.50(verbunden mit OpenVPN-Server AAA)
  3. GastgeberCCCist ein OpenVPN-Client mit IP172.16.10.50(verbunden mit OpenVPN-Server BBB).Es verfügt über Routing zu 172.17.10.0/24 über 172.16.10.1.

Bildbeschreibung hier eingeben

Mein Ziel ist, dass Host CCC Host AAA erfolgreich anpingt und Host AAA den Datenverkehr von der ursprünglichen IP von Host CCC (172.16.10.50) sieht.

iptables -A FORWARD... -J ACCEPTIch habe es auf Host BBB eingerichtet .

Auf dem Host BBB habe ich eingerichtetNach dem RoutingRegel. Beispielsweise ist der Ping mit MASQUERADE erfolgreich, aber das Problem besteht darin, dass Host AAA auf diese Weise die Quell-IP 172.17.10.50 (die IP von Host BBB) sieht: iptables -t nat -D POSTROUTING -s 172.16.10.50 -d 172.17.10.1 -o tun17 -j MASQUERADE

Ich ändere MASQUERADE zu SNAT, aber der Ping schlägt fehl: iptables -t nat -A POSTROUTING -s 172.16.10.50 -d 172.17.10.1 -o tun17 -j SNAT --to-source 172.16.10.50

Das Problem besteht darin, dass ich mit tcpdump sehe, dass der Datenverkehr den Host BBB nicht verlässt und kein Datenverkehr zum Host AAA vorhanden ist:

root@BBB:# tcpdump -ni tun17
listening on tun17, link-type RAW (Raw IP), capture size 262144 bytes
12:16:45.777464 IP 172.16.10.50 > 172.17.10.1: ICMP echo request, id 30730, seq 1149, length 64
12:16:46.801548 IP 172.16.10.50 > 172.17.10.1: ICMP echo request, id 30730, seq 1150, length 64

Ich habe versucht, SNAT auf die Quell-IP 172.17.10.55 zu ändern(eine IP-Adresse aus dem Netzwerk 172.17.10.0/24), aber der Ping schlägt erneut fehl und erneut verlässt der Datenverkehr den Host BBB nicht:

iptables -t nat -A POSTROUTING -s 172.16.10.50 -d 172.17.10.1 -o tun17 -j SNAT --to-source 172.17.10.55

12:16:47.825419 IP 172.17.10.55 > 172.17.10.1: ICMP echo request, id 30730, seq 1151, length 64
12:16:48.849460 IP 172.17.10.55 > 172.17.10.1: ICMP echo request, id 30730, seq 1152, length 64

Warum kann ich SNAT nicht mit --to-source 172.16.10.50 oder sogar mit --to-source 172.17.10.55 verwenden?(welche IP-Adresse stammt aus demselben Netzwerk 172.17.10.0/24), um 172.17.10.1 vom Host CCC aus anzupingen?

Der Datenverkehr scheint auf Host BBB zu sitzen und verlässt dessen tun17 nicht. Ich sehe, dass der Datenverkehr von HOST CCC zu HOST BBB geht, der Datenverkehr wird von tun16 zu tun17 weitergeleitet, kann dann aber nicht mit SNAT an Host AAA gesendet werden.

Der Ping funktioniert nur, wenn die Quell-IP-Adresse des Pakets 172.17.10.50 ist. Wenn ich die Quell-IP beispielsweise auf 172.17.10.55 ändere, schlägt der Ping fehl.

Ich denke, das Problem liegt weder an der Firewall noch am Routing. Ich vermute eine OpenVPN-Einschränkung, bin mir aber nicht sicher. Die beiden OpenVPN-Server sind im --topology subnetModus mit /24-Netzwerkmasken.

Antwort1

Sie müssen hinzufügenichroutein CCD, um die interne OpenVPN-Routingtabelle zu manipulieren.

Andernfalls weiß OpenVPN nicht, wohin die Pakete zurückgeleitet werden sollen. Im OpenVPN-Protokoll muss eine Zeile wie „MULTI: ungültige Quelladresse vom Client [IP-ADRESSE], Paket verloren“ stehen.

Lesen Sie hier mehr:

https://community.openvpn.net/openvpn/wiki/RoutedLans

verwandte Informationen