Zwei VPN-Hops auf einem Pi: welche Route welchen Peer trägt

Zwei Tunneladressen auf einer kleinen Platine wirken wie ein Fehler, und der Reflex ist, eine zu löschen. Dieser Reflex zerstört das, was er aufräumen sollte. Ein Host mit zwei Hops hält eine Adresse pro Anbindung, und jede Adresse wird von einer anderen Route ausgewählt. Die Frage, die sich lohnt, ist, welche Route welchen Träger für welches Ziel auswählt, nicht wie viele Adressen existieren.

Drei Ziele, die unterschiedliche Träger brauchen

Eine Kette aus zwei Hops sind drei gestapelte Zielklassen, und jede wird von einer anderen Anbindung getragen. Der äußere Peer muss über die physische Verbindung erreicht werden. Der innere Peer muss durch den äußeren Tunnel erreicht werden. Das Ziel der abgedeckten Anwendung muss durch den inneren Tunnel erreicht werden, dessen eigener Transport vom äußeren getragen wird.

Füllen Sie die Zeilen mit den echten Adressen des Lesers, bevor Sie eine Route anfassen, denn die Tabelle ist nur nützlich, wenn sie konkret ist. Eine funktionierende Kette erfüllt alle vier Zeilen gleichzeitig, und eine halb funktionierende erfüllt meist eine davon mit dem falschen Träger. Gerade das Lesen der falschen Zeile als Fehler macht aus einem Routingproblem einen ganzen Nachmittag voller Änderungen.

Adressen haben Rollen, keine Anzahl

Linux erlaubt mehrere Adressen auf einer Schnittstelle und mehrere Tunnel auf einem Host, daher sagt eine Anzahl nichts über Korrektheit aus. Entscheidend ist, welche Adresse zu welcher Anbindung gehört und ob die Route für einen bestimmten Peer die Anbindung auswählt, die Sie gemeint haben. Drei Ansichten beantworten das aus drei Richtungen, und es lohnt sich, sie jedes Mal in derselben Reihenfolge zu lesen.

Das Adressinventar zeigt, was existiert und welche Anbindung es besitzt. Die Routentabelle beantwortet die Trägerfrage für gewöhnlichen Zielverkehr. Die Richtlinienansicht beantwortet sie erneut für Verkehr, der nach Quelle oder Markierung ausgewählt wird, was die normale Anordnung ist, wenn zwei Clients einen Host teilen.

ip -4 addr show
ip -4 route show table all
ip rule show

Eine Adresse zu löschen, weil die Liste lang aussieht, kann einen Teil des Pfades entfernen, und eine Route zu löschen, weil sie überflüssig aussieht, tut dasselbe leiser. Keines von beiden erzeugt einen Fehler; der Peer antwortet einfach nicht mehr auf dem Pfad, den Sie gemeint haben, während er über einen anderen erreichbar bleibt. Eine Anwendung, die die Ausgangsadresse des inneren Peers meldet, beweist nicht, dass der Verkehr den äußeren Tunnel durchquert hat, denn direkter Zugriff erzeugt dieselbe Beobachtung. Genau diese Lücke zwischen Beobachtung und Beweis ist der Grund, warum der Träger auf der Routingebene geprüft wird.

Aktivierungsreihenfolge schlägt festes Warten

Hängt der innere Client von einer Adresse oder Route ab, die der äußere Client liefert, muss die Aktivierung auf diese Ressource warten statt auf eine Verzögerung. Ein fester Schlaf funktioniert bis zu dem Tag, an dem der äußere Tunnel langsam ist, und dann scheitert er sporadisch auf eine Weise, die niemand reproduzieren kann. Abhängigkeitsbasierte Reihenfolge beseitigt die Vermutung und kostet nichts außer einer einmaligen Beschreibung der Abhängigkeit. Auch Schnittstellennamen sind kein Ordnungsmechanismus.

Der Kernel vergibt Namen wie tun0 und tun1 in Erstellungsreihenfolge, und diese Reihenfolge kann sich zwischen Neustarts oder Neuverbindungen ändern. Binden Sie die Konfiguration an eine Identität, die das Werkzeug bereitstellt, oder an einen Namen, den Sie bewusst vergeben. Ein Name, den Sie wählen, ist ein Vertrag; ein Name, den der Kernel wählt, ist ein Zufall.

Halten Sie den Transport jedes Clients aus der Anwendungsroute des anderen heraus und seien Sie genau dabei, was die OpenVPN-2.6-Routingoptionen tatsächlich versprechen. Der dokumentierte Standard-Umleitungsmechanismus hält einen Client in der Lage, seinen eigenen entfernten Peer über das bereits vorhandene Gateway zu erreichen, was eine bestimmte Rekursionsschleife durchtrennt. Er macht einen Client nicht zum Träger eines anderen, daher bleibt der Rest der Kette Ihre Konstruktion. Wo die Kette eine Richtlinie statt einer Route braucht, schreiben Sie eine ausdrückliche Quell- oder Markierungsregel und testen Sie sie mit dem Verkehr, für den sie gedacht ist.

Was passiert, wenn der äußere Hop stirbt

Bevor die Kette als vollständig gilt, entscheiden Sie, was passiert, wenn der äußere Hop verschwindet. Der Transport des inneren Clients stirbt mit ihm, und der nächste Schritt ist eine Richtlinienfrage statt einer technischen: scheitern, erneut versuchen oder direkt über die physische Verbindung neu verbinden. Das dritte Ergebnis ist das, über das man nachdenken sollte. Es verwandelt still ein Zwei-Hop-Design in ein Ein-Hop-Design in dem Moment, in dem der Nutzer glaubt, die Abdeckung sei noch intakt.

Sind zwei Hops zwingend, darf der innere Client keinen direkten Pfad aufbauen können, wenn der äußere fehlt, und das herauszufinden gelingt, indem man den äußeren Hop bricht und beobachtet, was der innere tut. Ein genehmigter Rückfall ist eine legitime Antwort, aber er muss aufgeschrieben, getestet und kommuniziert werden. Ein Rückfall, den niemand dokumentiert hat, ist bei einer Incident-Überprüfung nicht von einem Leck zu unterscheiden.

DNS und die andere Adressfamilie gehören zur selben Entscheidung. Eine lokal erzeugte Auflösung folgt der eigenen Richtlinie des Hosts und nicht der eines weitergeleiteten Clients, daher ist der Resolver, der für weitergeleiteten Verkehr funktioniert, möglicherweise nicht der, den der Host selbst nutzt.

Akzeptieren Sie jede Schicht in der Reihenfolge, in der Sie sie gebaut haben

Testen Sie in der Reihenfolge, in der die Kette gebaut wurde: zuerst der äußere Tunnel allein, dann der Transport des inneren Clients durch den äußeren Tunnel, dann die Anwendung durch den inneren Tunnel. Jede Abnahme muss eine frische Verbindung sein statt einer bereits offenen Seite. Brechen und stellen Sie dann jede Schicht einzeln wieder her und beobachten Sie, was die nächste tut.

Das Rückfall-Ergebnis ist hier die wertvollste Beobachtung und die, die eine öffentliche IP-Seite nie zeigt. Speichern Sie die Peer-Pfade, die verwendeten Adressen und dieses Ergebnis neben der Konfiguration, denn der glückliche Pfad ist nicht der Teil, der später hinterfragt wird.