Grenzen Sie die OpenVPN-SNAT-Regel ein, bevor sie nginx bricht

Zwei Fehlerbilder kommen immer wieder von derselben Art Host. Beim ersten authentifizieren sich Clients und erreichen danach nichts jenseits des Tunnels. Beim zweiten kommt das VPN hoch und die eigene Website des Servers antwortet nicht mehr, was das beunruhigendere ist, weil es wie Kollateralschaden aussieht. Auf einem containerbasierten VPS führen beide meist auf dieselbe kurze Liste von Prüfungen zurück, und die Reihenfolge zählt: erst das Gerät, dann die Übersetzung, dann der Geltungsbereich.

Bestätigen Sie, dass der Container ein tun-Gerät anlegen kann

Nichts anderes zählt, wenn die Tunnelschnittstelle nicht existieren kann. Prüfen Sie, ob /dev/net/tun vorhanden ist und ob das Anlegen eines Testgeräts gelingt, denn viele Anbieter deaktivieren tun in Containern standardmäßig. Kein Aufwand an der Firewall wiegt ein Gerät auf, das nie angelegt wurde.

Fehlt das Gerät, können nur der Host oder der Anbieter es aktivieren. Ein anderer Tarif ist oft günstiger als ein offener Support-Thread, der eine Woche dauert. Bestätigen Sie das, bevor Sie eine einzige Zeile des OpenVPN-Logs lesen. Sonst verbringen Sie den Abend damit, Regeln zu justieren, die nie ein Paket sehen werden.

Entscheiden Sie, was MASQUERADE auf dieser Schnittstelle tut

Auf einer gewöhnlichen virtuellen Maschine ist die übliche Ausgangsregel POSTROUTING MASQUERADE aus der Hauptschnittstelle. In einem OpenVZ-Container ist das sichtbare Gerät oft venet0, eine hostverwaltete virtuelle Schnittstelle statt einer gerouteten NIC, und MASQUERADE verhält sich dort nicht immer so, wie Tutorials annehmen.

Die praktikable Form ist eine ausdrückliche Übersetzung auf die Adresse, die Clients bereits erreichen, mit erlaubter Weiterleitung in beide Richtungen. Den Pool aus der Serverkonfiguration zu ersetzen ist ebenso wichtig wie die Adresse zu ersetzen. Lesen Sie jede Zeile, bevor Sie sie einfügen.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ohne die Weiterleitungsregeln findet die Übersetzung weiterhin statt, und der Kernel weigert sich weiterhin weiterzuleiten. Diese Kombination erzeugt den verwirrenden Zustand, in dem die Zähler der NAT-Regel steigen, während der Client nichts empfängt. Die beiden FORWARD-Zeilen müssen außerdem vor jeder breiten Drop-Regel in derselben Kette stehen. Die Reihenfolge ist Teil der Konfiguration, kein Implementierungsdetail.

Grenzen Sie die Regel auf einen Pool und eine Schnittstelle ein

Das zweite Symptom hat eine andere Ursache: eine POSTROUTING-Regel ohne Quell- und ohne Ausgangsbeschränkung. Eine solche Regel schreibt jedes Paket um, das den Host verlässt.

Dienste, die auf die ursprüngliche Quelle angewiesen sind, verhalten sich dann falsch. Ein Webserver hinter einem lokalen Proxy kann aufhören zu antworten, und ein Neustart ändert nichts, weil die Regel weiterhin im Pfad liegt. Auch der Verkehr, den der Host an seine eigene öffentliche Adresse sendet, ist betroffen, weshalb der Fehler wie ein DNS- oder Zertifikatsproblem aussehen kann statt wie ein Firewall-Problem. Die Regel wurde fast sicher hinzugefügt, um das erste Symptom zu beheben.

Die Lösung besteht darin, die Übereinstimmung auf den Tunnel-Pool und die Ausgangsschnittstelle zu verengen und dann eine Regel pro Pool hinzuzufügen, statt eine einzelne Regel auf mehrere auszuweiten.

Machen Sie die Regeln dauerhaft und finden Sie heraus, wer sonst sie besitzt

Von Hand hinzugefügte Regeln verschwinden beim Neustart, speichern Sie sie daher mit iptables-save oder verwalten Sie sie über netfilter-persistent, wo es installiert ist. Bestätigen Sie, dass die Wiederherstellung läuft, bevor OpenVPN startet. Starten Sie dann einmal absichtlich neu, statt die Lücke während eines Vorfalls zu entdecken.

Auf einem Container-Host bestätigen Sie außerdem, dass die Persistenzdatei im beschreibbaren Containerspeicher liegt und dass der Anbieter die Filterung beim Booten nicht ersetzt. Manche Plattformen verwalten Richtlinien außerhalb des Containers, wo lokale Regeln entweder ignoriert werden oder mit denen des Hosts kollidieren.

Prüfen Sie mit Zählern und einem aufgezeichneten Fluss

Prüfen Sie von einem verbundenen Client aus die öffentliche Adresse, die ein externer Dienst meldet. Stimmt sie mit der Adresse des Servers überein, funktioniert die Übersetzung; wenn nicht, verlässt das Paket den Host über einen anderen Pfad oder gar nicht. Testen Sie dann sowohl einen auf dem Server gehosteten Dienst als auch einen im öffentlichen Internet, denn beide nehmen unterschiedliche Wege durch dieselbe Regelmenge.

Lesen Sie auf dem Server die Paketzähler der NAT- und FORWARD-Regeln mit iptables -t nat -L -v -n und beobachten Sie einen Fluss in einer Aufzeichnung. Erscheint die Adresse des Clients in der Aufzeichnung und folgt keine Antwort, liegt die Lücke auf dem Rückweg oder in der Filterung des Anbieters, nicht im Clientprofil. Vergleichen Sie die aufgezeichnete Quelle mit der Adresse, auf die die Regel übersetzt, denn eine Abweichung bedeutet, dass eine andere Regel zuerst gepasst hat. Ein beobachteter Fluss klärt mehr als eine Seite Konfigurationslektüre.

Halten Sie Pool, übersetzte Adresse und Schnittstellennamen zusammen im Änderungsprotokoll fest. Eine Regel, die für einen Pool korrekt ist, übersetzt den nächsten falsch.