Volltunnel oder Endpunkt-Route: Den VPN-Server erreichbar halten

Fügen Sie eine Standardroute durch den Tunnel hinzu, und die Pakete des Tunnels folgen ihr. Die Tabelle enthält dann eine Regel, die sich selbst aushebelt. Die verschlüsselte Verbindung zum Server versucht, innerhalb der Verbindung zu verlaufen, die sie gerade aufbauen will.

Zwei Mechanismen verhindern diese Schleife. Einer ist in der Routingtabelle sichtbar, der andere lebt in der Anwendung.

Innerer und äußerer Verkehr sind unterschiedliche Entscheidungen

Ein Anwendungspaket tritt in das virtuelle Interface ein und wird gekapselt. Das Ergebnis ist ein neues Paket, das an die öffentliche Adresse des Servers adressiert ist. Dieses Paket braucht eine Route im physischen Netz, denn nichts daran darf in den Tunnel gelangen.

Beides sind Routingentscheidungen, und nur die erste gehört zum Tunnel. Wenn der Client eine Standardroute installiert, die auch den Server abdeckt, wird das äußere Paket ebenfalls eingefangen.

Die Symptome sind sofort und total. Der Handshake läuft durch, und dann fließt nichts mehr, oder die Verbindung bricht in dem Moment ab, in dem die Route installiert wird. In beiden Fällen kann der Keepalive nicht mehr hinaus.

Option eins: eine Host-Route für den Endpunkt

Der direkte Ansatz fügt eine Route für die Adresse des Servers über das ursprüngliche Gateway hinzu. Das kostet eine Zeile. Jeder, der die Tabelle liest, sieht sie. Und sie lässt sich in einem Änderungsdatensatz leicht erklären.

Ihre Schwäche zeigt sich, wenn sich der zugrunde liegende Pfad ändert. Die gespeicherte Route nennt ein Gateway und ein Interface aus dem alten Netz. Nach einem Wi-Fi-Wechsel existiert dieses Gateway vielleicht nicht mehr, und die Route bleibt zurück, sieht richtig aus und tut nichts.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Ein Hostname macht das schwieriger. Wenn der Endpunkt ein Name ist, der auf mehrere Adressen auflöst, muss die Ausnahme die tatsächlich genutzte Adresse abdecken. Eine spätere Auflösung kann etwas liefern, das die Route nie abgedeckt hat.

Option zwei: den Socket schützen

Der andere Ansatz berührt die Routingtabelle nie. Der Client markiert oder schützt den Socket, der den Tunnel trägt, sodass das Betriebssystem den Verkehr dieses Sockets per Richtlinie am Tunnel vorbei schickt. Android stellt den Mechanismus VPN-Anwendungen direkt bereit. Desktop-Clients implementieren Entsprechungen mit Firewall-Marken oder Bind-to-Device-Aufrufen.

Der Vorteil ist, dass die Ausnahme der Verbindung folgt und nicht einem gespeicherten Gateway. Ein Netzwerkwechsel schreibt den zugrunde liegenden Pfad um, und der geschützte Socket wandert mit, weil er nie an eine Adresse gebunden war. Die Routingtabelle bleibt sauber.

Der Preis ist Sichtbarkeit. Nichts in der Routingtabelle zeigt die Ausnahme, ein Prüfer, der nach einer Host-Route sucht, findet nichts und könnte das Design für unsicher halten. Der Schutz lebt im Code des Clients und in den Richtlinienregeln, die dieser Code installiert.

Die Wahl zwischen beiden

Wählen Sie den Socket-Mechanismus, wenn der Client ihn unterstützt, denn er übersteht die Netzwerkwechsel, die eine festgelegte Route zerstören. Wählen Sie die Host-Route, wenn die Ausnahme für andere Werkzeuge sichtbar sein muss oder wenn der Client nichts Besseres bietet.

Keiner der Mechanismen ersetzt die Notwendigkeit, dass die Serveradresse überhaupt erreichbar ist. Ein privates Gateway hat eine öffentliche Listener-Adresse, und genau diese Adresse muss außerhalb des Tunnels bleiben. Die internen Netze dahinter werden erst erreichbar, wenn der Tunnel existiert.

Was immer Sie wählen, halten Sie es bei der Komponente, die den Tunnel besitzt. Eine von Hand gesetzte Host-Route funktioniert bis zum nächsten Netz, und dann wird sie zum rätselhaften Ausfall von morgen.