NordVPN unter Linux blockiert das LAN: Allowlist und DNS

Alles sieht normal aus, bis Sie etwas auf Ihrem eigenen Schreibtisch erreichen wollen. Der Tunnel steht, Seiten laden, und das Netzlaufwerk läuft in eine Zeitüberschreitung. Trennen Sie die Verbindung, und das Laufwerk ist zurück, bevor Sie den Satz beendet haben, was Ihnen mehr sagt als jedes Protokoll: Der Client lehnt Verkehr bewusst ab, der nicht in den Tunnel gelangt, und Ihr lokales Netz liegt auf der falschen Seite dieser Grenze.

Der Kill Switch tut seine Arbeit

Ein Kill Switch existiert, um zu verhindern, dass Verkehr entweicht, wenn der Tunnel nicht verfügbar ist. Private Adressbereiche gelten als Verkehr, der nicht in den Tunnel gelangt, also blockiert eine strikte Umsetzung sie zusammen mit allem anderen. Das ist kein Fehler in dem Sinn, den Leute meinen, wenn sie den Bericht einreichen.

Lesen Sie zuerst die Sicht des Clients selbst. Ein Befehl gibt die aktuellen Einstellungen aus, ein zweiter zeigt die Firewall-Objekte, die der Client angelegt hat. Sie suchen ein Drop oder Reject, das vor jeder Tunnel-Ausnahme erscheint, denn genau diese Reihenfolge macht das lokale Netz unerreichbar.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Führen Sie dann einen Test aus, der das Problem halbiert. Erreichen Sie das Gerät über die Adresse und dann über den Namen. Adresse funktioniert und Name scheitert heißt, die Firewall ist unschuldig und der Resolver nicht. Beides scheitert heißt, die Firewall weist das Paket ab, und der Rest dieses Artikels gilt.

Allowlist: Wählen Sie den Eintragstyp nach Symptom

Der Client bietet eine Allowlist mit drei Arten von Einträgen, und die richtige Art zu wählen ist der größte Teil der Arbeit. Ein Subnetz deckt Hosts ab. Ein Port deckt einen Dienst unabhängig vom Ziel ab. Eine Multicast-Gruppe deckt Discovery-Verkehr ab, und das ist eine andere Form von Verkehr als alles, was an einen einzelnen Host adressiert ist.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

Discovery-Fehler überraschen Leute, weil ein Drucker oder Medienserver über eine gruppenadressierte Abfrage gefunden werden kann statt über eine Suche nach seiner eigenen Adresse. Das Subnetz des Hosts hinzuzufügen deckt diese Gruppe nicht automatisch ab, also bleibt das Gerät unsichtbar, während seine Webseite einwandfrei lädt, wenn Sie die Adresse eintippen.

Halten Sie die Ausnahme so eng, wie das Symptom es erlaubt. Ein breites Präfix, einmal eingetippt, wird jahrelang vergessen, und niemand kann später erklären, welche Maschinen es aufnehmen sollte. Löschen Sie Einträge, wenn das Projekt endet, das sie brauchte, und prüfen Sie, was nach einem Update übrig bleibt.

Neuere Builds bieten außerdem eine einzelne LAN-Discovery-Einstellung. Sie ist praktisch, und sie wirkt mit der Allowlist zusammen, statt sich darauf zu stapeln: Sie einzuschalten kann bestehende Einträge für private Subnetze löschen, und eine manuelle Regel für ein privates Subnetz kann abgelehnt werden, solange sie aktiv bleibt.

Hostnamen brauchen eine eigene Entscheidung

Ein Subnetz zu erlauben stellt die Verbindung über die Adresse wieder her und lässt die Namensgebung unberührt. Lokale Hostnamen gehen weiterhin an den Resolver, den der Client beim Aufbau des Tunnels konfiguriert hat, also liefert ein Name, der früher aufgelöst wurde, jetzt nichts mehr.

Den Client auf den Resolver des Routers zu richten behebt das in einem Schritt und ändert still, was Sie gekauft haben. Jede Abfrage, nicht nur lokale, verlässt dann den Weg über den Router, sodass der Tunnel den Teil Ihres Surfens nicht mehr schützt, der Absichten verrät.

Der engere Weg behält den Tunnel-Resolver und ergänzt die wenigen Namen, die zählen, entweder als Suchdomäne oder als einzelne Einträge. Er kostet mehr Aufmerksamkeit und bewahrt die Eigenschaft, für die Sie bezahlt haben.

Prüfen Sie das Ergebnis mit einem Aufruf des System-Resolvers statt mit einem Browser. Browser führen zunehmend ihre eigene verschlüsselte Auflösung aus und antworten gern über einen Weg, den Ihre Shell nie nutzt, sodass die Adressleiste gesund aussehen kann, während der System-Resolver noch kaputt ist.

Das Installationsproblem, das zuerst kommt

Ein guter Teil dieser Berichte erreicht die Firewall nie, weil der Befehl gar nicht da ist. Das Bootstrap-Paket des Anbieters registriert ein Repository und einen Signaturschlüssel. Es installiert den Client nicht, also ist ein fehlender Befehl direkt danach das erwartete Ergebnis und kein Fehlschlag.

Aktualisieren Sie die Paketlisten und installieren Sie nach Namen. Wenn sich der Paketmanager über einen fehlenden öffentlichen Schlüssel beschwert, ist der Schlüssel nicht dort gelandet, wo er danach sucht, und die Lösung ist, ihn dort abzulegen, bevor Sie erneut aktualisieren.

Wenn der Hostname des Repositorys zu einer privaten Adresse auflöst, halten Sie an und lesen Sie dieses Ergebnis zweimal. Möglicherweise läuft bereits ein Tunnel, dessen Resolver für öffentliche Namen antwortet, und ein erneuter Installationsversuch erzeugt dieselbe Meldung endlos.

Schreiben Sie es auf, bevor Sie den Deckel schließen

Stellen Sie fest, dass der Tunnel das Einzige ist, was sich geändert hat, und erlauben Sie dann das Kleinste, was das Symptom wiederherstellt. Behalten Sie die Namensgebung als eigene Entscheidung mit eigener Notiz.

Notieren Sie, welche Ausnahme für welches Gerät existiert und wer darum gebeten hat. Ein lokales Netz, das nur funktioniert, weil jemand ein breites Präfix eingetippt hat, ist eine Entscheidung, die ihren Grund längst überlebt hat.

Testen Sie nach dem Update des Clients erneut. Der Firewall-Aufbau ändert sich zwischen Versionen, und die Allowlist des letzten Monats ist keine Tatsache über diesen Monat.