Warum sich hinter demselben Router nur ein VPN-Client verbindet

Zwei Laptops hängen im selben Heimnetz, und das Büro-VPN akzeptiert genau einen von ihnen. Der zweite läuft entweder in eine Zeitüberschreitung oder wartet, bis der erste die Verbindung trennt, und niemand hat zwischen den beiden Versuchen eine Clienteinstellung angefasst. Die Zugangsdaten sind dieselben, die vor einer Minute funktionierten, und das ist der Hinweis darauf, dass die Authentifizierung nicht die Ursache ist. Drei Mechanismen erzeugen dieses Muster, und das eigene Protokoll des Servers sagt, welcher davon vorliegt.

Lesen Sie das Protokoll des Gateways, bevor Sie einen Client anfassen

Der Eintrag des Servers zu beiden Versuchen beantwortet die erste Frage, und zwar auf eine von drei Arten. Taucht der zweite Versuch in diesem Protokoll nie auf, hat das Paket den Zuhörer nie erreicht, und der Heimrouter oder der Weg des Anbieters trägt das Problem. Vermerkt das Protokoll einen Versuch und weist ihn ab, ist der Tunnel angekommen, also geht es um Identität, Lizenzierung oder eine Sitzungsobergrenze und nicht um etwas auf dem Draht. Vermerkt das Protokoll eine erfolgreiche Sitzung, während der Client weiterhin einen Fehler meldet, prüfen Sie den Rückweg oder ob zwei Clients dieselbe Tunneladresse erhalten.

Ein Handy-Hotspot trennt diese beiden Familien günstig: Lassen Sie den zweiten Client über mobile Daten laufen, während der erste verbunden bleibt. Gelingt es dort, deutet das auf das Heimnetz, scheitert es dort genauso, deutet das auf das Gateway, und der Router bleibt unschuldig. Kein Ergebnis ist für sich entscheidend, aber jedes halbiert den Suchraum mit einem Versuch.

Schreiben Sie das Ergebnis auf, bevor Sie etwas ändern, denn die drei Protokollausgänge führen zu drei unabhängigen Reparaturen. Eine Notiz, die benennt, welchen der drei Fälle Sie gesehen haben, ist mehr wert als ein Bildschirmfoto eines Clientfehlers.

Was der Router mit GRE und NAT-T macht

PPTP ist der klassische Übeltäter: Der Steuerkanal ist TCP 1723, während der Datenpfad GRE ist, IP-Protokoll 47. Viele Heimrouter bringen einen PPTP-Helfer mit, der eine einzige Steuerverbindung verfolgt, sodass ein zweiter Client hinter demselben NAT seinen Steuerkanal öffnet und danach gar keinen Datenpfad erhält. Eine TCP-Portweiterleitung mit der Nummer 47 bewirkt für GRE nichts, weil GRE eine Protokollnummer und kein Port ist.

L2TP über IPsec verhält sich konstruktionsbedingt anders: IKE nutzt UDP 500, NAT-Traversal verschiebt die geschützte Nutzlast auf UDP 4500, und die Kapselung existiert genau deshalb, damit mehrere Clients hinter einer Adresse dasselbe Gateway erreichen können. Diese Konstruktion hindert ein Gateway oder eine Zwischenbox nicht daran, eine Obergrenze pro Adresse durchzusetzen, und vom Sofa aus sehen beide Fehler gleich aus. Das native Protokoll von SoftEther hat dieselbe Problemklasse: Ein Router ohne funktionierende Durchleitung nimmt den ersten Client aus dem LAN an und verwirft den zweiten. Testen Sie den ALG- oder Durchleitungsschalter des Routers in beiden Stellungen, denn ein für einen älteren Client geschriebener Helfer kann Pakete beschädigen, die ein aktueller sendet.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Identitätsobergrenzen, die wie Transportgrenzen aussehen

Der Router ist nicht der einzige Verdächtige, und das Protokoll unterscheidet ihn von der Alternative. Wenn ein OpenVPN-Server einen gemeinsamen Namen an eine Tunneladresse bindet, erhalten beide Geräte diese Adresse, und ohne duplicate-cn verdrängt die neuere Sitzung die ältere. Diese Option einzuschalten lässt beide verbunden, gibt ihnen aber eine Identität, ein Zertifikat und eine Widerrufsentscheidung, was schlimmer ist, als es aussieht. Das zweite Gerät lässt sich dann nie allein widerrufen, sodass ein Bequemlichkeitsschalter still eine Kontrolle entfernt, die Sie später brauchen könnten.

Lesen Sie das Journal des Servers und seine Statusdatei zusammen, denn das eine zeigt die Authentifizierungsentscheidung und die andere, wer gerade verbunden ist. Zwei Einträge mit demselben gemeinsamen Namen und einer virtuellen Adresse bestätigen eine Identitätskollision und nicht eine Routergrenze. Kommerzielle Gateways fügen eigene Grenzen hinzu, etwa einen Tarif mit genau einer gleichzeitigen Sitzung, eine Lizenzanzahl oder eine Regel, die eine Sitzung pro öffentlicher Adresse erlaubt, und keine Routerseinstellung ändert daran etwas.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Ordnen Sie die Reparatur dem Protokolleintrag zu

Eine Ablehnung im Protokoll verlangt getrennte Zugangsdaten pro Gerät, eine höhere Grenze vom Betreiber des Dienstes oder einen zweiten Gateway-Endpunkt für eine Maschine. Erreicht kein zweiter Versuch je den Server, ist die dauerhafte Reparatur ein Router, der das Protokoll weiterleitet und mehr als eine Sitzung hält, oder ein Transport, den der Router gut beherrscht, etwa ein einzelner TCP- oder UDP-Strom. Die Wahl dazwischen ist eine Entscheidung über die Lebensdauer der Hardware, nicht über Clienteinstellungen.

Kopieren Sie nicht das Profil eines funktionierenden Geräts auf die zweite Maschine und erklären Sie die Sache für erledigt. Das macht aus einem Verbindungsproblem ein Problem der Zugriffskontrolle, weil ein verlorener Laptop nicht mehr von der noch genutzten Kopie zu unterscheiden ist. Es verbirgt außerdem den ursprünglichen Fehler, der in dem Moment zurückkehrt, in dem ein drittes Gerät auftaucht.

Zwei laufende Sitzungen überprüfen

Verbinden Sie beide Geräte gleichzeitig, starten Sie die vorgesehene Anwendung auf jedem, verbinden Sie dann eines erneut und wiederholen Sie das. Ein zweites Symbol, das kurz erscheint, beweist nichts über den Verkehr, und eine Sitzung, die nach zehn Minuten abbricht, ist ein anderer Fehler mit einem anderen Verantwortlichen. Vergleichen Sie, was der Server am Ende meldet, mit dem, was die Nutzer gesehen haben, denn diese beiden Berichte stimmen oft nicht überein.

Überleben beide Sitzungen und tragen Verkehr, hält die Lösung, und die Notiz, die Sie am Anfang geschrieben haben, wird zum Beleg dafür, was falsch war. Überlebt nur eine, kehren Sie zum ersten Schritt zurück und prüfen Sie, welchen der drei Protokollausgänge Sie jetzt haben, denn die Antwort kann sich geändert haben. Routerhelfer können ein Problem verdecken, das in einem anderen Netz wieder auftaucht, während eine Grenze pro Adresse dem Nutzer folgt und nicht dem Gerät. Aus einem zweiten Netz zu testen ist der billigste Weg herauszufinden, was davon Sie tatsächlich behoben haben.