Wem gehören Adresse, Route, DNS und Firewall auf einem Linux-VPN?

Zwei Skripte, die um dieselbe Route kämpfen, sind die übliche Form eines Linux-VPN-Problems, das als Routing-Fehler gemeldet wird. Eine Komponente erstellt das Tunnelgerät, eine andere fügt eine Standardroute hinzu, eine dritte schreibt die Resolver-Konfiguration neu, und eine vierte lädt Firewall-Regeln neu. Jede von ihnen kann die Arbeit einer anderen rückgängig machen, und gewonnen hat einfach diejenige, die zuletzt lief. Die Frage, die es zu beantworten gilt, ist nicht, welches Paket zu installieren ist, sondern welche Komponente für welchen Teil des Zustands zuständig ist.

Schreiben Sie diese Zuordnung einmal auf, und die meisten Fehler bei der Neuverbindung verlieren ihr Rätsel. Vier Objekte zählen: das Gerät und seine Adressen, die Routen und Richtlinien-Regeln, die DNS-Konfiguration und die Firewall.

Das Gerät und seine Adressen

Ein Tunnelgerät wird entweder von einem Manager erstellt, der das Profil kennt, oder von einem Daemon, den jemand von Hand gestartet hat. Beide Anordnungen funktionieren für sich; sie zu mischen nicht. Wenn NetworkManager das Profil besitzt, soll er auch das Gerät besitzen, und starten Sie keinen unverwalteten OpenVPN-Prozess gegen denselben Tunnelnamen.

Halten Sie fest, wer das Gerät entfernt, wenn die Sitzung endet. Ein Gerät, das seine Sitzung überlebt, ist die häufigste Quelle veralteter Adressen und der Verwirrung, die daraus folgt.

Routen und Richtlinien-Regeln

Bei Routen richten Eigentumskonflikte sichtbaren Schaden an. Ein Verbindungsmanager installiert eine Standardroute für den Tunnel plus eine spezifischere Route für das entfernte Netz; ein handgeschriebenes Skript fügt dann seine eigene Standardroute mit einer anderen Metrik hinzu und gewinnt oder verliert still, je nach Timing. Entscheiden Sie, welche Einträge verbindungsgebunden sind, welche dauerhafte Richtlinie sind und welche Komponente sie nach einer Neuverbindung aktualisiert. Dann halten Sie die anderen Komponenten aus dieser Tabelle heraus.

Richtlinien-Regeln verdienen dieselbe Klarheit, denn eine Regel, die auf eine Tabelle zeigt, die niemand füllt, erzeugt ein schwarzes Loch, das genau wie ein toter Tunnel aussieht. Wenn eine Regel existiert, um Datenverkehr irgendwohin zu zwingen, muss die Tabelle, die sie auswählt, vom selben Eigentümer gepflegt werden.

DNS hat immer einen eigenen Eigentümer

Ein Resolver-Daemon läuft als eigener Prozess unter eigener Identität, daher erbt er nicht versehentlich die Routing-Entscheidungen des Tunnels. Wenn das VPN DNS-Server überträgt, muss etwas das in eine pro Link gültige Konfiguration übersetzen, die der Resolver beachtet, und etwas muss sie danach wieder entfernen.

Der Mythos besagt, dass das Schreiben eines Nameservers ins Profil ändert, wohin Anfragen gehen. Es ändert, was dem Resolver gesagt wird, nicht, welchen Socket der Resolver upstream verwendet. Testen Sie mit einer Abfrage plus einer Routenabfrage, statt der Datei zu vertrauen.

Firewall-Zustand und wer ihn wiederherstellt

Firewall-Regeln sind das am häufigsten überschriebene Objekt auf einem VPN-Host. Ein Manager kann pro Verbindung NAT- oder Weiterleitungsregeln hinzufügen, während ein Firewall-Dienst beim Systemstart ein gespeichertes Regelwerk neu lädt und sie auslöscht. Wählen Sie eine zuständige Instanz für die Richtlinie und machen Sie die andere zu deren Nutzer, oder akzeptieren Sie, dass ein Neustart das Verhalten still ändert. Verbindungsgebundene Ausnahmen gehören in eine Datei, die derselbe Eigentümer lädt, nicht in eine iptables-Zeile, die bei der Fehlersuche getippt wird.

Wenn Regeln eine Neuverbindung überleben müssen, sagen Sie das ausdrücklich. Wenn nicht, sagen Sie auch das, denn der nächste Ingenieur wird die bequemere Antwort annehmen.

Lebenszyklus: Start, Neuverbindung, Abbau

Geben Sie jedem dieser drei Momente einen Eigentümer. Legen Sie beim Start fest, was Voraussetzungen vorbereitet und in welcher Reihenfolge. Denken Sie bei einem weichen Neustart daran, dass das Gerät überleben kann, während der Sitzungszustand es nicht tut, also muss ein Prüfer laufen statt eines Erzeugers. Entfernen Sie beim Abbau nur das, was diese Verbindung erstellt hat, denn jede Route zurückzusetzen oder die ganze Firewall zu leeren ist nicht dasselbe wie einen Tunnel außer Dienst zu stellen.

Zur Beobachtung zeigt ip monitor link address route Kernel-Änderungen, sobald sie passieren, aber es meldet Ereignisse statt Absicht: Eine gelöschte Route sagt nichts darüber, welcher Prozess sie gelöscht hat. Kombinieren Sie es mit der Eigentümer-Zuordnung, und ein verwirrender Shutdown wird zu einer kurzen Liste von Kandidaten.

Auch Ausnahmen haben ihren Preis. Eine ganze Geräteklasse als unverwaltet zu markieren, um einem Konflikt zu entkommen, übergibt diesen Zustand niemandem, und das ist eine Entscheidung statt einer Reparatur.