Heimlabor mit geteiltem Tunnel: nur das Nötige routen, nicht alles
Ein voller Tunnel ist eine Angewohnheit aus Anleitungen, keine Anforderung des Labors. Listen Sie die Subnetze, Namen und Verwaltungspfade auf, die Sie wirklich brauchen, und routen Sie dann nur diese.
Der Rat, ein Heimlabor brauche einen vollen Tunnel, stammt meist aus einer Anleitung, die einen hatte, nicht aus einer Anforderung. Split-Tunneling ist nicht die kompromittierte Version eines ordentlichen VPN; es ist die Version, deren Routingtabelle Sie erklären können. Ein Labor mit fünf Diensten und einer Verwaltungsoberfläche braucht nicht, dass jedes Paket, das das Haus verlässt, einen Tunnel durchläuft. Was es braucht, ist eine Bestandsaufnahme und eine Route für jeden Eintrag dieser Bestandsaufnahme.
Der Mythos: Split-Tunneling ist ein Kompromiss
Der Mythos hält sich, weil ein voller Tunnel einmal leichter zu konfigurieren und später schwerer zu debuggen ist. Dieser Handel ist für ein Notebook im öffentlichen Wi-Fi vernünftig und für ein Rack im Keller falsch.
Er verbirgt außerdem eine zweite Annahme, nämlich dass die Adressierung des Labors nichts mit dem Netz gemein hat, von dem aus Sie sich verbinden.
Erfassen Sie die Ressourcen vor den Routen
Schreiben Sie jedes Labor-Subnetz auf, den Dienst, der dort lebt, den Namen, über den Sie es auflösen, und wer es erreichen darf; die Hinweise zur Weiterleitung für Ihr Gateway beschreiben den Rückweg, gegen den Sie planen. Ergänzen Sie die Container-Bereiche und die LAN-Bereiche, die der entfernte Client womöglich schon nutzt, denn Überschneidung ist der Fehler, den diese Bestandsaufnahme verhindert. Eine Route, die jede private Adresse abdeckt, kollidiert früher oder später mit einem Heimnetz. Die Bestandsaufnahme ist zugleich der Testplan, deshalb lohnt sie sich vor der Konfiguration und nicht danach.
Weisen Sie jeder Ressource einen Weg zu: durch den Tunnel, direkt oder verweigert. Eine Ressource ohne zugewiesenen Weg ist die, die später die verwirrte Supportfrage erzeugt.
Fünf Zeilen und eine Spalte voller Entscheidungen schlagen eine Routingtabelle, die niemand lesen kann.
Das Gateway braucht einen Rückweg
Weiterleitung am Gateway ist nur die Hälfte. Das Labor braucht eine Route zurück zum Client-Pool oder eine unterstützte Übersetzungsregelung, die die Rückkehr möglich macht. Wenn Antworten den Client nicht finden, wirkt der Tunnel verbunden und jede Anfrage läuft in einen Timeout; das ist ein Routingsymptom und kein VPN-Fehler. Prüfen Sie den Rückweg als Teil des Entwurfs, nicht als Fehlerbehebungsschritt.
Ein Client-Pool, der die eigene Adressierung des Labors überschneidet, ist die andere Hälfte dieses Problems, und er scheitert auf genau dieselbe Weise.
Reparieren Sie den Plan statt der Symptome, wenn die beiden Bereiche kollidieren.
Verwaltung und Internet sind getrennte Rollen
Entscheiden Sie, ob nur der Laborverkehr den Tunnel nutzt oder ob er auch zum Internetausgang wird. Fügen Sie keine Standardroute hinzu, nur weil eine Anleitung eine verwendet hat, denn diese Entscheidung ändert, wohin jede DNS-Abfrage und jede Updateprüfung geht. Bewahren Sie einen Weg nach außen zum VPN-Endpunkt selbst, sonst versucht der Tunnel, seine eigene äußere Verbindung zu tragen. Halten Sie den Verwaltungszugang schmal und über eine freigegebene Wiederherstellungsmethode erreichbar.
Privates DNS lässt sich für Labornamen wählen, ohne anzunehmen, dass jede öffentliche Abfrage denselben Resolver braucht. Das ist eine Resolver-Entscheidung, keine Routenentscheidung.
Sie getrennt zu halten ist das, was die Fehlermodi später unterscheidbar macht.
Testen Sie von außen, nicht aus dem LAN
Nutzen Sie eine externe autorisierte Verbindung statt eines Tests aus demselben LAN, denn ein Test aus demselben LAN kann eine fehlende Rückroute vollständig verbergen. Prüfen Sie eine Laboradresse, ihren privaten Hostnamen, ein beabsichtigtes Direktziel und das geforderte Fehlerverhalten. Der Fehlerfall zählt so viel wie der Erfolgsfall: eine Ressource, die nicht erreichbar sein soll, muss tatsächlich unerreichbar sein. Halten Sie alle vier Ergebnisse fest, bevor Sie den Entwurf als fertig bezeichnen.
Dann speichern Sie die Routen- und DNS-Konfiguration neben der Bestandsaufnahme, mit einem benannten Verantwortlichen. Wenn das Labor ein weiteres Subnetz erhält, aktualisieren Sie beides und testen erneut.
Eine ungeklärte Route, die ein bestehendes Heimnetz überschneidet, ist das Standardergebnis, wenn dieser Schritt ausgelassen wird.
Der fertige Entwurf ist klein, dokumentiert und langweilig, und genau das will ein Labor von seinem Netz. Die interessante Version ist die, die bricht, während Sie nicht zu Hause sind.