Warum eine Volltunnel-Route den Server abschneidet, der sie trägt

Schalten Sie einen Volltunnel ein, und jedes Ziel gehört jetzt zum VPN-Interface, einschließlich der Maschine, die ihn terminiert. Die äußeren Pakete, die den Tunnel tragen, sind an diese Maschine adressiert, also verbraucht die Route am Ende den Transport, von dem sie abhängt. Eine einzige zusätzliche spezifische Route löst das, und der Grund lohnt sich zu verstehen. Ohne diesen Grund führt der nächste Neuaufbau den Fehler wieder ein.

Eine Route, die ihren eigenen Transport frisst

Die Kapselung wickelt jedes Paket in einen zweiten Header. Der äußere ist von der lokalen physischen Adresse an die öffentliche Adresse des Servers adressiert und muss die physische Strecke überqueren, bevor irgendein Tunnel existieren kann.

Lassen Sie nun die Suche nach dieser öffentlichen Adresse den Tunnel wählen. Um das Paket zu senden, muss die Maschine es kapseln, was eine Route zur selben Adresse erfordert, die den Tunnel zurückgibt. Clients gehen damit auf eine von zwei Arten um. Ein sorgfältiger Client weigert sich, die Standardroute zu installieren, und meldet einen Fehler, während ein weniger sorgfältiger Erfolg meldet und dann nichts bewegt. Der stille Fehlschlag ist der, der einen Nachmittag kostet.

Die Übereinstimmung mit dem längsten Präfix entscheidet die Suche, bevor irgendeine Metrik herangezogen wird, also übertrifft eine Route für eine einzelne Adresse jede Standardroute auf der Maschine. Das ist der gesamte Mechanismus hinter der Reparatur.

Installieren Sie die Ausnahme vor der Standardroute

Erstellen Sie eine Route für eine einzelne Adresse für den Server, mit dem physischen Gateway als nächstem Hop, bevor die Standardroute sich bewegt. Die Reihenfolge zählt: sie danach zu installieren bedeutet, mit einem kaputten Tunnel zu leben, während Sie tippen.

Die meisten Clients tun das unaufgefordert. OpenVPN sucht die entfernte Adresse und fixiert sie, bevor das Standard-Gateway umgeschrieben wird, und seine Option route-delay existiert für Plattformen, auf denen diese Reihenfolge rennt. wg-quick nimmt einen ganz anderen Weg, indem es Pakete markiert und eine Policy-Regel heranzieht statt eine Ausnahme hinzuzufügen. Verschiedene Mechanismen, dieselbe Anforderung: Das äußere Paket muss dem Tunnel entkommen, den es erzeugt.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Die Ausgabe der Suche ist der Abnahmetest. Sie muss das physische Gerät und den physischen nächsten Hop nennen. Ein Tunnelgerät in dieser Antwort bedeutet, dass die Ausnahme fehlt oder nach etwas platziert wurde, das sie überstimmt.

Das Spiegelbild auf dem Server

Dieselbe Falle wartet auf der anderen Seite, umgekehrt. Geben Sie dem Server eine Standardroute durch einen anderen Tunnel oder schieben Sie ihm eine Route zu, die die öffentlichen Adressen der Clients abdeckt, und seine Antworten bekommen eine Gewohnheit in die falsche Richtung.

Stellen Sie sich einen Client vor, der sich verbindet und eine Anfrage sendet. Die Antwort ist an die öffentliche Adresse dieses Clients adressiert, die jetzt einer Tunnelroute entspricht, also geht sie von einem anderen Interface aus und trägt eine Quelle, die der Client nie gewählt hat. Der Client kann dieses Paket empfangen und trotzdem verwerfen, weil nichts es mit der gesendeten Anfrage verbindet. Arbeiten Sie von der Routing-Entscheidung des Servers aus statt vom Timeout des Clients, denn nur eine von beiden zeigt die tatsächliche Wahl.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Es gibt drei Reparaturen, und sie sind nicht gleich. Den Dienst an die physische Adresse zu binden oder die Quelle zu übersetzen verbirgt beides die Routing-Entscheidung, statt sie zu korrigieren. Antwortverkehr für den Tunnel-Pool über eine dedizierte Tabelle zu senden behebt die Ursache, und die anderen beiden sind nur akzeptabel, solange das Routing-Design eingefroren ist.

Ausnahmen, die der Tunnel immer wieder stiehlt

Eine Handvoll Aufgaben brauchen das offene Internet, selbst während der Tunnel die Standardroute besitzt, und jede braucht ihre eigene Ausnahme. Der dynamische DNS-Aktualisierer ist normalerweise der erste, der bricht.

Er löst den Anbieter auf, öffnet eine Verbindung und stellt fest, dass seine eigenen Pakete durch einen Tunnel reisen, dessen Adresse sich vor Sekunden geändert hat, also schlägt die Aktualisierung fehl oder veröffentlicht die falsche Adresse. Drei Auswege: den Anbieter mit einer Host-Route durch das physische Gateway fixieren, die Aktualisierung ausführen, bevor der Tunnel steigt, oder dem Aktualisierer eine Policy-Tabelle geben, die der Tunnel nie berührt. Die Zeitsynchronisation hat dieselbe Exposition auf einem Gerät, das ohne Resolver startet, und Zertifikatsprüfungs-Endpunkte gehören aus demselben Grund auf die Liste.

Eine Ausnahme, die niemand aufgeschrieben hat, ist eine Ausnahme, die der nächste Neuaufbau still fallen lässt.

Beweisen Sie es nach einer Wiederverbindung, nicht davor

Testen Sie drei Ziele, nicht eines: den Endpunkt, eine private Adresse hinter dem Tunnel und eine öffentliche Adresse dahinter. Eine einzelne erfolgreiche Suche sagt fast nichts über die anderen beiden.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Starten Sie dann die Verbindung neu, denn ein Client, der seine Tabelle bei der Wiederverbindung neu aufbaut, verwirft eine Route, die Sie von Hand eingegeben haben. Mit einem Kill-Switch im Spiel prüfen Sie, ob der Endpunkt erlaubt ist, sonst kann der Tunnel nach einer Netzwerkänderung nicht zurückkehren und das Symptom sieht wie ein Ausfall aus. Speichern Sie die Ausnahme im Profil oder in der Unit-Datei statt in einer Shell-Historie, damit die Wiederverbindung sie neu erzeugt, statt sie zu löschen.