Ein kommerzielles VPN mit Internet-Ausgang verbirgt Ihre Adresse; es verbindet Sie nicht mit Ihrem eigenen Haus. Um das NAS oder den Drucker in einem Heimnetz zu erreichen, braucht es ein Gateway in diesem Netz und einen Client, der einen Tunnel dorthin aufbaut. Das Paket muss dann fünf Prüfungen bestehen, und jeder einzelne Fehlschlag sieht von außen gleich aus.

Hürde 1: Der Client muss den Tunnel wählen

Prüfen Sie, ob das Zielpräfix auf dem Client tatsächlich in den Tunnel geroutet wird. Ein Split-Tunnel-Profil, das nur das eigene Subnetz des VPN setzt, schickt 192.168.x.x direkt aus der lokalen Schnittstelle hinaus, wo es nirgendwo ankommt. Sehen Sie sich die Routing-Tabelle des Clients an, nicht den Profilnamen.

Das ist der häufigste Fehler bei Handy-Clients, die oft standardmäßig nur DNS oder nur ein Präfix senden. Fehlt die Route, kann der Handshake perfekt sein und das Gerät trotzdem unerreichbar.

Bestätigen Sie vor dem Weitermachen, dass sich die Pool-Adresse des Clients und das Heim-Subnetz nicht überschneiden.

Hürde 2: Das Gateway muss weiterleiten

Das VPN endet auf einem Host, der das entschlüsselte Paket ins LAN weiterleiten muss. Dafür muss IP-Weiterleitung aktiviert sein und eine Firewall-Regel den Fluss von der VPN-Schnittstelle zur LAN-Schnittstelle erlauben. Bei einer Router-Appliance ist das meist eingebaut; auf einer Linux-Kiste mit strongSwan oder WireGuard sind es zwei Einstellungen, die man vergisst. Prüfen Sie beide, bevor Sie den Dienst testen, denn jede allein erzeugt denselben Timeout.

Testen Sie mit einem Mitschnitt auf der LAN-Schnittstelle, denn ein Paket, das dort nie auftaucht, wurde verworfen oder nie weitergeleitet.

Das ist ein anderer Fehler als ein Dienst, der die Verbindung ablehnt, und die Unterscheidung spart viel Zeit. Halten Sie die Freigabe eng, begrenzt auf den Dienst und den VPN-Pool statt auf das ganze Subnetz.

Hürde 3: Der Rückweg entscheidet alles

Das Ziel antwortet an die Quelladresse, die es gesehen hat – je nachdem, ob Sie übersetzen, ist das die Pool-Adresse des Clients oder das Gateway. Ist das Standard-Gateway des Ziels der Heimrouter und hat dieser Router keine Route zum VPN-Pool, verlässt die Antwort das Netz über das Internet und stirbt. Das ist die klassische Einbahnverbindung.

Es gibt zwei legitime Lösungen: eine Route für den Pool auf dem LAN-Gateway hinzufügen oder Source-NAT am VPN-Gateway, damit das Ziel immer nur die Gateway-Adresse sieht. Die zweite ist einfacher und verliert die ursprüngliche Quellidentität.

Wählen Sie eine bewusst und schreiben Sie auf, welche, denn Firewall-Regeln und Protokolle hängen davon ab. Der strongSwan-Leitfaden zur Weiterleitung geht die Linux-Seite dieser Entscheidung durch.

Hürde 4: Namen und Präfix-Überschneidung

Lokale Discovery-Namen überschreiten keine geroutete Grenze, ein Gerät, das im Haus als freundlicher Name erscheint, kann über den Tunnel unsichtbar sein. Stellen Sie DNS für die private Zone bereit oder dokumentieren Sie die Adresse. Welchen Namen Sie auch verwenden, er muss sich in etwas auflösen, das der entfernte Client routen kann. Darum kann ein Gerät per Adresse erreichbar und per Name unsichtbar sein.

Überschneidende Präfixe sind die andere Falle: Ist der Client-Pool 192.168.1.0/24 und das Heimnetz ebenfalls, hält der Client das Ziel für lokal und schickt es nie durch den Tunnel.

Nummerieren Sie eine Seite neu, oder verwenden Sie einen Pool aus einem Bereich, dem Sie zu Hause nie begegnen.

Hürde 5: Von außerhalb des Hauses testen

Ein Test aus der Küche beweist nichts, denn der Verkehr verlässt das LAN vielleicht nie. Verbinden Sie sich über einen mobilen Hotspot oder ein anderes Netz und gehen Sie die Hürden der Reihe nach durch: Route auf dem Client, Mitschnitt auf der LAN-Schnittstelle, Antwort des Dienstes, Mitschnitt der Antwort und Namensauflösung. Die erste Hürde ohne Beleg ist die Stelle, an der die Arbeit liegt.

Antwortet der Dienst, aber der Name nicht, haben Sie ein DNS-Problem und kein Tunnelproblem.

Bewahren Sie die funktionierende Konfiguration in einer Notiz mit Pool, Route und NAT-Entscheidung auf, denn der nächste Routerwechsel setzt alle drei zurück.

Ähnliche Artikel