iptables-Host nur mit VPN: Tun-Gerät benennen, nicht tun+

-o tun+ zu schreiben wirkt wie eine präzise Anweisung und ist in Wahrheit ein Platzhalter für jeden Tunnel, den der Kernel hat. Ein zweiter VPN-Client, eine Container-Bridge oder eine Schnittstelle, die eine abgestürzte Sitzung hinterlassen hat, erfüllen ihn alle, und der Host erlaubt dann Datenverkehr, den die Richtlinie verhindern sollte. Die Anleitung unten legt einen Gerätenamen fest, ordnet die Ausnahmen so, dass der Tunnel tatsächlich entstehen kann, und lässt Ihnen einen Weg zurück, falls die Regeln schlecht ausfallen. Jeder Schritt ist kurz genug, um ihn allein rückgängig zu machen.

Schritt 1: Notieren Sie die Regeln, die Sie jetzt haben

Bevor Sie eine Standardrichtlinie ändern, sichern Sie den aktuellen Zustand, damit das Zurückrollen ein Befehl ist und keine Erinnerung. iptables-save > /root/iptables.pre schreibt jede Tabelle in eine Datei, die Sie wiederherstellen können, und ein zweites Terminal mit offener Root-Sitzung ist keine Paranoia, wenn die Richtlinie, die Sie gleich setzen, die Verbindung verwirft, die sie trägt. Wenn Sie remote arbeiten, planen Sie zusätzlich einen Flush als Notausschalter ein.

Listen Sie dann die Schnittstellen auf, denn ein Name, den Sie angenommen haben, ist ein Name, den Sie hätten lesen sollen: ip -br link zeigt, was gerade existiert, und der Tunnel erscheint erst, wenn er oben ist. Schreiben Sie die Gerätenamen mit, während Sie sie lesen.

Schritt 2: Geben Sie dem Tunnel seinen eigenen Namen

OpenVPN akzeptiert dev tun_work in der Client-Konfiguration, und Linux erstellt dann eine Schnittstelle mit genau diesem Namen, statt tun0 zu vergeben. Der Name bleibt über Wiederverbindungen hinweg stabil, solange nichts anderes ihn beansprucht, und genau das macht eine Regel, die das Gerät benennt, aussagekräftig.

Wo der Name nicht kontrolliert werden kann, gleichen Sie stattdessen auf die Tunneladresse oder eine Paketmarke ab. Beides funktioniert, beides ist schwerer zu lesen, und beides scheitert leiser, wenn der Tunnel neu nummeriert. Gleichen Sie in jedem Fall auf eine Sache ab und seien Sie ausdrücklich, auf welche.

Schritt 3: Schreiben Sie die Richtlinie mit der Endpoint-Ausnahme zuerst

Ein Host nur mit VPN ist ein Host mit Standardverweigerung und einer kurzen Ausnahmeliste, und die Ausnahme, die am meisten zählt, ist die, die den Tunnel existieren lässt. Bauen Sie sie in dieser Reihenfolge auf, mit der Endpoint-Regel vor der Tunnel-Geräte-Regel, damit der Handshake ein Ziel hat:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Die wörtliche Endpoint-Adresse und der Port gehören Ihrem Anbieter, nicht dieser Seite. Wenn der Endpoint ein Hostname ist, lösen Sie ihn einmal auf und legen Sie das Ergebnis fest, denn eine Regel kann keinen Namen nachschlagen, und eine rotierende Antwort bricht die Richtlinie stillschweigend nach der nächsten DNS-Änderung. Prüfen Sie auch den Port, denn Anbieter, die Sie auf TCP 443 verschieben, brauchen sonst eine Regel, die niemand aufgeschrieben hat. Ein Tunnel, der nur über ein Protokoll funktioniert, ist meist genau diese Auslassung und kein Firewall-Fehler.

Auf einem Router geht dieselbe Form in die FORWARD-Kette für die Clients dahinter, und der eigene Verkehr des Routers braucht eigene Regeln. Ein Regelsatz, der nur weitergeleitete Pakete abdeckt, lässt SSH und DNS auf dem alten Pfad, und so wird ein Router in dem Moment unerreichbar, in dem der Tunnel hochkommt.

Schritt 4: Prüfen Sie die Reihenfolge, nicht nur die Anwesenheit

Regeln werden der Reihe nach ausgewertet, ein früheres ACCEPT verdeckt also einfach das REJECT, das Sie danach hinzugefügt haben. Der established- und related-Abgleich ist es, der Antworten auf Ihre eigenen ausgehenden Anfragen zurückkehren lässt, ohne einen allgemeinen eingehenden Pfad zu öffnen, und ihn nach dem Tunnel-Accept zu platzieren bedeutet, dass ein verworfener Tunnel immer noch Rückverkehr auf seiner eigenen Schnittstelle durchlässt.

Halten Sie die Regelzahl klein genug, um sie auf einem Bildschirm zu lesen. Ein Regelsatz, den Sie nicht prüfen können, ist einer, den Sie flicken werden, indem Sie Ausnahmen oben ergänzen, und so bekommen Standardverweigerungsrichtlinien allmählich eine Standarderlaubnis-Kante. Zählen Sie die ACCEPTs vor und nach der Änderung.

Schritt 5: Sorgen Sie dafür, dass es Start und Adressfamilie überlebt

Von Hand eingegebene Regeln verschwinden beim Neustart, laden Sie sie also aus dem Firewall-Dienst der Distribution oder aus einer Unit, die läuft, nachdem die Tunnel-Schnittstelle existiert. In einem Skript, das vor dem Start von OpenVPN läuft, auf tun_work zu verweisen, ist ein häufiger Weg, eine Startschleife mit verworfenem Verkehr zu erzeugen.

Prüfen Sie dann IPv6 getrennt, denn eine gute Standardverweigerungsrichtlinie für IPv4 sagt nichts über die andere Familie. ip -6 route sagt Ihnen, ob der Host eine Route hat, die Verkehr um einen Tunnel herum tragen könnte, der nur IPv4 verarbeitet, und ip6tables oder nftables braucht seine eigenen entsprechenden Regeln. Testen Sie mit einem IPv6-only-Ziel, statt der Symmetrie des Regelsatzes zu vertrauen.

Schritt 6: Verifizieren und bereit sein zurückzurollen

Bringen Sie den Tunnel hoch, bestätigen Sie, dass der beabsichtigte Dienst funktioniert, und versuchen Sie dann etwas, das die Richtlinie ablehnen sollte. Stellen Sie mit iptables-restore < /root/iptables.pre wieder her, wenn die Antwort Sie überrascht, und beginnen Sie erst dann, Regeln zu bearbeiten. Beständigkeit plus ein getesteter Wiederherstellungspfad ist es, was daraus eine Änderung macht, die Sie zweimal machen können.