Die Adminseite des Routers öffnet sich vom Sofa aus in zwei Sekunden und läuft im Hotelzimmer in einen Timeout, während der VPN-Client durchgehend „verbunden“ meldet. Du hast einen Weg hinaus, keinen Weg zurück: Der Tunnel trägt deinen Verkehr ins Internet und hört dort auf. Um ein Gerät im eigenen LAN zu erreichen, braucht es eine Sitzung, die an etwas mit einer Route dorthin endet. Das ist eine Designentscheidung, keine Einstellung, und sie bestimmt, ob der Rest der Arbeit überhaupt möglich ist.

Der Unterschied geht leicht verloren, weil ein Produkt beides leisten kann. Ein kommerzieller Ausgangsclient und ein Fernzugriffsserver können dasselbe Protokoll auf demselben Port sprechen, und der Unterschied ist, welche Seite den Adressraum hinter dem Endpunkt besitzt.

Welche Tunnelseite besitzt das LAN

Für die Verwaltung muss der Endpunkt im Netz liegen, das du erreichen willst, oder einen autorisierten Weg dorthin haben. Ein Router mit eigenem VPN-Server erfüllt das; ein kleiner dauerhaft laufender Host mit fester Adresse und Route ins LAN ebenfalls. Ein Ausgangsdienst eines Drittanbieters erfüllt es nicht, weil sein Endpunkt keine Schnittstelle in deinem LAN und keine Regel hat, die eine entstehen ließe. Das ist die Prüfung, die vor allem anderen abgeschlossen sein muss.

Firmware kennzeichnet diesen Unterschied selten, lies also, was die Funktion tut, statt welches Protokoll sie nennt. WireGuard, OpenVPN und IKEv2 kommen auf beiden Marktseiten vor: Der eine Build schickt Haushaltsverkehr nach draußen, der andere nimmt dein entferntes Gerät an. Ein reiner Client-Build lässt sich nicht per Konfiguration in einen Server verwandeln, wie das Menü auch formuliert ist.

Die Rückroute entstehen lassen

Ein WireGuard-Server auf dem Router hat eine Schnittstellenadresse wie 10.8.0.1/24 und einen Peer-Eintrag für das Notebook. Der Client entscheidet, welche Ziele er in den Tunnel schickt, und eine Liste, die nur das Tunnelsubnetz enthält, lässt das LAN unsichtbar, wie auch immer der Server konfiguriert ist. Beide Seiten müssen übereinstimmen, und bearbeitet wird meist nur eine davon.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Der erste Befehl meldet, was jeder Peer aus Sicht des Servers senden darf; der zweite meldet, wohin eine LAN-Adresse auf dem Client tatsächlich ginge. Ein LAN-Ziel, das auf die Tunnelschnittstelle auflöst, ist funktionierendes Routing, und eines, das über das physische Gateway hinausgeht, kommt nie an, egal was die Firewall sagt. Trage das LAN-Präfix in die erlaubte Liste des Clients ein, und dieselben zwei Befehle werden vom Diagnosewerkzeug zum Verifikationsschritt.

Denselben Sprung für IPsec-Gateways beschreibt die strongSwan-Dokumentation zur Weiterleitung, wo Weiterleitung und eine Source-NAT-Regel einen Tunnelclient mit einem internen Host verbinden. Die Adressierung unterscheidet sich; die Anforderung nicht.

Wer die Adminseite öffnen darf

Zugriffskontrolle gehört auf den Router, nicht in die Absicht, vorsichtig zu sein. Erlaube nur der authentifizierten Tunnelidentität oder dem Quellbereich, der die Seite braucht, und lies sowohl die eigene Input-Kette des Routers als auch jede weitergeleitete LAN-Richtlinie. Eine Regel, die dem kabelgebundenen LAN den Zugriff auf die Adminseite erlaubt, sagt nichts über einen Client, der über die Tunnelschnittstelle ankommt. Schreibe die Ausnahme für eine bestimmte Identität und halte dann eine zweite Identität bereit, die abgelehnt werden muss.

Der Listener ist die andere Hälfte und in der Firewall-Ausgabe unsichtbar. ss -ltnp zeigt die Adresse, an die der Webserver gebunden ist, und ein Dienst, der nur an die LAN-Adresse gebunden ist, antwortet nicht auf der Tunneladresse, so freizügig die Regeln auch sind. Ihn neu zu binden oder eine Adresse hinzuzufügen ist eine Konfigurationsänderung am Router, keine Firewall-Änderung.

Halte Authentifizierung und Transportvalidierung im selben Durchgang aktiv. Erreichbar ist nicht vertrauenswürdig, und jedes Gerät in einem Tunnel wird dadurch nicht zum Administrator. Tunnel-Zugangsdaten und Router-Konto sind getrennte Rechte mit getrennten Lebenszyklen, sodass der Schlüssel eines verlorenen Notebooks widerrufen werden kann, ohne jedes Administratorkennwort zurückzusetzen.

Von außen testen, nicht vom Sofa

Teste aus einem Netz, das du nicht kontrollierst. Verbinde dich über den freigegebenen Tunnel, öffne eine frische Admin-Sitzung und ändere etwas Harmloses, das du auf der Seite siehst. Vom Sofa aus beweist du, dass das LAN funktioniert, was nie bezweifelt wurde.

Dann teste die Ablehnungen mit derselben Sorgfalt. Versuche die Seite ohne den Tunnel und bestätige, dass es scheitert, und bestätige, dass der Verwaltungsdienst gar nicht auf der WAN-Adresse lauscht. Eine Seite, die bloß nicht verlinkt ist, ist keine Zugriffskontrolle, und ein WAN-Listener mit Anmeldeformular ist immer noch ein WAN-Listener. Wenn ein Passwort das Einzige zwischen dem Internet und der Router-Konsole ist, dann ist das Design ein Passwort.

Haushaltsdienste verdienen einen Blick, solange du dort bist. Das Verschärfen von Verwaltungsregeln bricht oft das Gästenetz oder den Resolver, den die Familiengeräte nutzen, und das zeigt sich Tage später als unabhängige Beschwerde.

Sich einen Weg zurück bewahren, während man Dinge ändert

Bereite vor dem Fernändern von Routen oder Tuneleinstellungen einen unabhängigen Rückweg vor. Eine bestehende Sitzung kann die Änderung überleben, die neue Verbindungen bereits blockiert, und genau so sperren sich Leute aus, während sie eine Sitzung beobachten, die noch funktioniert. Die Optionen sind konkret: ein geplanter Neustart in eine bekannte Konfiguration, Konsolen- oder physischer Zugriff, ein zweiter Tunnel, der nicht von der bearbeiteten Einstellung abhängt, oder Out-of-Band-Verwaltung, wo die Hardware sie bietet. Wähle eine und weise sie vor dem Wartungsfenster nach, nicht währenddessen.

Halte die Aufzeichnung kurz und aktuell: welcher Host den Tunnel beendet, welche Identitäten die Seite erreichen dürfen, an welche Adresse der Dienst bindet und wie ein verlorenes Gerät widerrufen wird. Diese Liste dient zugleich als Wiederherstellungsplan, weil sie sagt, wo jede Abhängigkeit lebt. Eine fehlende Rückroute ist ein Routingproblem, das repariert wird, und nie ein Grund, Verwaltung im WAN zu veröffentlichen.

Ähnliche Artikel