#NAT? Wir machen kein NAT, wir sind Profis. Wir machen #DoppelNAT
https://www.youtube.com/shorts/TFADvpycMvk
#AVM #FritzBox #network #IoT
Schlagwort-Archive: NAT
adlerweb // BitBastelei 2024-06-15 15:28:36
#NAT? Wir machen kein NAT, wir sind Profis. Wir machen #DoppelNAT
https://www.youtube.com/shorts/TFADvpycMvk
#AVM #FritzBox #network #IoT
adlerweb // BitBastelei 2024-06-15 15:28:36
#NAT? Wir machen kein NAT, wir sind Profis. Wir machen #DoppelNAT
https://www.youtube.com/shorts/TFADvpycMvk
#AVM #FritzBox #network #IoT
Interfacebasiertes OpenVPN-Routing und martian packets
Ab und an sehen meine Wünsche recht speziell aus, ich weiß. Heut sieht die Aufgbe wie folgt aus:
Ein Router besitzt 3 Netzwerkkarten, eth0 ist direkt an das Internet angeschlossen, eth1 versogt das Netzwerk A und eth2 das Netzwerk B. Zusätzlich gibt es über OpenVPN (tap0) einen Link zu einem externen Internetzugang. Ziel ist nun, dass alle Internetanfragen von Netzwerk B (eth2) über das VPN versendet werden, der Rest jedoch nicht.
Der (zusammenkopierte) Entwurf lautete wie folgt:
iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-xmark 0x1/0xffffffff
-> Alles was aus Netzwerk B kommt wird mit Flag 0x1 verseheniptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
-> Alles was über tap0 raus geht wird per NAT maskiertip route add unreachable default table 42
-> Alles auf der Routingtabelle 42 wird per default abgelehntip rule add from all fwmark 0x1 table 42
-> Alles mit der Markierung 0x1 gehört zur Tabelle 42ip route replace 0.0.0.0/1 via *OpenVPN-IP* table 42
ip route replace 128.0.0.0/1 via *OpenVPN-IP* table 42
-> Alles auf Tabelle 42 wird über den VPN-Server abgewickeltnet.ipv4.ip_forward ist auf 1
Auf den ersten Blick ist auch alles OK, Netzwerk A und der Server funktionieren fehlerfrei. Vom Netzwerk B ist jedoch kein Internetzugriff möglich. Getreu dem guten alten Troubleshooting-Guide also auf die Suche.
Wenn ich von einem Client in Netzwerk B pinge kommt das Paket am Router auf eth2 an:
[eth2] 10.222.100.53 > 8.8.8.8: ICMP echo request
…und wird auf tap0 nach draußen gesendet:
[tap0] 10.8.0.16 > 8.8.8.8: ICMP echo request
Kurz drauf trifft auch von draußen über das VPN eine Antwort ein:
[tap0] 8.8.8.8 > 10.8.0.16: ICMP echo reply
und dann hing es… Die Antwort wird nicht auf eth2 wieder weitergegeben, dort ist kein Traffic erkennbar. Scheint, als ob irgendwas beim NAT schief geht. Wenn ich logging auf Maximum stelle (net.ipv4.conf.tap0.log_martians=1) ist im syslog folgendes zu lesen:
kernel: IPv4: martian source 10.222.100.53 from 8.8.8.8, on dev tap0
Ich vermute, dass hier das NAT durch die verschiedenen Routing-Tabellen ein zu großes Chaos verursacht. Als „Workarround“ ist auf dem VPN-Interface jetzt Source-Filterung ausgeschaltet (net.ipv4.conf.tap0.rp_filter=0). Da die Gegenseite ohnehin nochmals nattet sollte da nichts böses(™) drüber eintrudeln.
Sollte jemand genauer erklären können was hier passiert freue ich mich über einen Kommentar.