Ich hatte ja in meinem letzten Beitrag schon beschrieben, die Regel macht ein Masquerading für die Pakete vom Server über VPN in dein Heimnetz. Damit funktioniert das Split-Routing, weil du nicht den kompletten Internetverkehr über den VPN Tunnel leitest.
Ohne diese Regel werden die Pakete vom Server mit ihrer öffentlichen Absender-IP weitergeleitet (Hast du ja im tcpdump gesehen). Damit werden sie entweder sofort von den Allowed IPs kassiert und kommen gar nicht am Ziel an, oder dein Heimnetz kann nicht richtig drauf antworten. Denn wenn die Absenderadresse der Pakete in deinem Heimnetz noch eine öffentliche IP ist, dann will dein Heimnetz die Antwort über die Default-Route schicken, und das ist nicht der VPN Tunnel. Beim ursprünglichen Absender käme die Antwort von einer anderen Quell-IP an, als er ursprünglich mal als Ziel-IP benutzt hat. Das Antwortpaket wird verworfen, da der Absender die Antwort nicht seiner Frage zuordnen kann.
Mit der Regel ersetzt der Server die originale öffentliche Absender-IP durch die VPN Transportnetz-IP. Das geht durch den Tunnel, und dein Heimnetz weiß, wohin mit der Antwort. Man könnte die generische Masquerade Regel durch spezifischere SNAT Regeln ersetzen, aber ob es was bringt? Viel nicht. Was aber wieder gilt: Die Masquerade Regel darf nur 1x existieren!
Vielleicht noch zur Anschauung:
https://www.tech-island.com/kb/linux/reference/unterschied-zwischen-masquerade-snat-und-dnat
Zur Anschauung noch mal ein kompletter Regelsatz für einen Port mit SNAT anstatt generischem MASQUERADE:
iptables -t nat -A PREROUTING -i eth0 -d ÖFFENTLICHE_IP -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080
iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT
iptables -t nat -A POSTROUTING -o VPN -d 192.168.1.22 -p tcp --dport 8080 -j SNAT --to-source 10.0.0.1Zunächst wird die Zieladresse auf die Adresse im Heimnetz umgeschrieben. Dann wird das Forwarding für diese Zieladresse und den Zielport erlaubt. Zuletzt wird die Quelladresse für die Zieladresse und den Zielport umgeschrieben.
Die spezifischen Regeln haben den Vorteil, dass sie nur exakt in dem Moment greifen, wenn ein Paket für die Portweiterleitung bearbeitet wird. Die generische MASQUERADE Regel greift immer, und es kann ja durchaus Anwendungsfälle auf dem VPN abseits der Portweiterleitung geben, für die das nicht erwünscht ist.
Wenn man dann snat nutzen möchte im POSTROUTING dann muss man das dann für jede interne IP machen und braucht dann kein Masquerade mehr?
Man muss es für jede Kombination aus Port, Protokoll (tcp, udp) und interner IP machen. Natürlich kann man eine Multi-Port Regel machen, wenn man möchte, dann ist es nur ein iptables Eintrag, das ist auch ein wenig performanter (weniger Einträge, die iptables durchsuchen muss).
Multiport Regeln kannst du eigentlich immer einsetzen, wenn Portnummern vorkommen (bei DNAT natürlich nur, wenn Quell- und Zielport identisch sind). Also anstatt
iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPTkannst du
iptables -A FORWARD -i eth0 -p tcp -m multiport --dports 8080,8081,8082 -d 192.168.1.21 -j ACCEPTbenutzen.
Alle anderen Regeln kannst du synonym anlegen. Im Grunde brauchst du für jede Zieladresse und jedes Protokoll (tcp, udp) dann einen Eintrag, der alle nötigen Ports beinhaltet. Das natürlich jeweils für die drei PREROUTING, FORWARD, POSTROUTING Regeln oben aus dem Beispiel.
Dann braucht es für ein komplettes Setup vermutlich noch die ESTABLISHED,RELATED Regel. Generell muss das ganze Setup dann abgerundet werden mit einem Regelset, dass den Server an sich schützt. Also alles bis auf VPN zu oder so.
und zum abrunden sollte es doch reichen mit einer drop regel alle Ports die nicht benötigt werden zu sperren.
Genau. Man kann auch die Default Policy auf DROP stellen.
glaub man kann das doch negieren und somit alles dicht machen außer z.b. 8080 + Wireguard selbst.
Du musst unterscheiden zwischen INPUT und FORWARD. Für INPUT brauchst du den Wireguard Port, aber keine 8080 Regel. Für FORWARD brauchst du die Regeln für dein Heimnetz (8080 z.B.), aber keinen Wireguard Port.
dann kann man ja sogar den ssh Port dicht machen wenn man alles direkt über Wireguard macht.
Ein Fallback ist nie weg. Allerdings würde ich den SSH Port auf irgendwas Ungewöhnliches verlegen, in dem möglichst wenig "22" vorkommt. Das SCP bleibt natürlich als Fallback, ist aber auch echt unkomfortabel.
Genau. Man kann auch die Default Policy auf DROP stellen.
Du musst unterscheiden zwischen INPUT und FORWARD. Für INPUT brauchst du den Wireguard Port, aber keine 8080 Regel. Für FORWARD brauchst du die Regeln für dein Heimnetz (8080 z.B.), aber keinen Wireguard Port.
meine global alles zu blockieren außer die Ports die auch erreichbar sein sollen.
Und der ssh port wurde geändert, und stimmt natürlich das, dass über ssh viel einfacher zu bedienen ist.
meine global alles zu blockieren außer die Ports die auch erreichbar sein sollen.
Genau das meine ich auch. Abe rman muss sich überlegen, welche Ports man wo braucht. Bei Linux wird strikt unterschieden zwischen INPUT und FORWARD. INPUT braucht man für alles, was direkt auf dem Server verarbeitet wird. FORWARD braucht man dann, wenn der Server was weiterleitet. Wenn Port 8080 als Weiterleitung übers VPN ins Heimnetz dienen soll, kann er beim INPUT zugemacht werden, denn der Port ist auf der externen IP weg und wird lokal auf dem Server garantiert (bzw. hoffentlich) nicht mehr benutzt. Und nur weil man einen Port für FORWARD benutzt, muss er nicht auch bei INPUT geöffnet werden.
Oder direkt eine input drop Regel für alles und dann SSH freigeben.
Das ist der Weg. Alles droppen und nur die erlaubten Dinge öffnen.
