OpenVPN hinter stunnel: den Wrapper weiterleiten, nicht Port 1194

Setzen Sie einen TLS-Wrapper vor OpenVPN, und das Deployment erhält einen zweiten Listener, von dem nur einer jemals ins Internet zeigen sollte. Wenn der Tunnel von derselben Maschine aus funktioniert und von außen scheitert, zielt die Weiterleitung meist auf den falschen der beiden. Was zusammenpassen muss, ist eine Kette: Die öffentliche Regel erreicht den Wrapper, und die eigene Backend-Verbindung des Wrappers erreicht den echten VPN-Socket. Vier Sprünge tragen diese Kette, und jeder davon kann die Untersuchung früh beenden.

Zwei Sockets, zwei Eigentümer, einer davon öffentlich

Der Wrapper beendet TLS für die äußere Verbindung und reicht den entschlüsselten Bytestrom an einen einfachen OpenVPN-TCP-Listener weiter. Das sind getrennte Sockets mit getrennten Konfigurationsdateien, also lässt eine Änderung an einem den anderen unberührt und weiterhin scheinbar gesund. Es bedeutet auch, dass beide auseinanderdriften können, wann immer einer ohne den anderen geändert wird.

Die Arbeit von der Maschine selbst beweist daher sehr wenig über den öffentlichen Weg. Eine direkte Verbindung zum nativen Port überspringt den Wrapper, eine Verbindung zum Wrapper auf seiner LAN-Adresse überspringt die Übersetzung, und nur die vollständige Anordnung auf Clientseite übt, was ein Außenstehender tut. Auch Namen müssen sorgfältig gelesen werden, denn localhost bedeutet den Host, auf dem genau diese Komponente läuft, und nicht den Host, auf dem Sie gerade zufällig tippen. Halten Sie diese Unterscheidung in Ihren Notizen fest, denn ein Test, der ohne den abgedeckten Sprung aufgezeichnet wurde, lädt zu einem Vergleich zweier verschiedener Dinge ein.

Wo die Weiterleitung tatsächlich landet

Die Kette lässt sich als vier Sprünge leichter halten als als drei Portnummern, weil dieselbe Nummer an jedem Ende etwas anderes bedeuten kann. Lesen Sie die Tabelle Zeile für Zeile: Jede Zeile ist ein Socket, der eine Verbindung annehmen und dann die nächste öffnen muss. Zielt eine Zeile auf den falschen Partner, ist das Symptom in der letzten Spalte das, was der Nutzer meldet.

Eine Regel, die auf den nativen VPN-Port statt auf den Wrapper zielt, überspringt die TLS-Beendigung vollständig, und das ist die häufigste Form dieses Fehlers: Der Client eröffnet einen Handshake mit einem Listener, der OpenVPN-Rahmung erwartet, sodass die Verbindung sich öffnen und dann hängen bleiben kann. Prüfen Sie den übersetzten Port gegen die Konfigurationsdatei des Wrappers statt gegen das Gedächtnis, denn die nächste Person, die diese Datei bearbeitet, hat vielleicht eine andere Nummer gewählt. Die beiden Befehle unten zeigen beide Seiten dieser Frage auf einmal.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Die Bind-Adresse, die Sie abweist

Eine accept-Zeile, die an 127.0.0.1 gebunden ist, beantwortet nur den Host selbst, also kann eine Weiterleitung, die auf der LAN-Adresse ankommt, keine Verbindung aufbauen, und der Client sieht eine Ablehnung, die wie ein Paketfilterproblem klingt. Sehen Sie sich den Socket an, bevor Sie die Firewall anfassen, denn der Socket ist die billigere Antwort. Binden Sie den Wrapper entweder an das Interface, auf das die Weiterleitung zielt, oder lassen Sie ihn auf loopback und sorgen Sie dafür, dass die Weiterleitung loopback über etwas erreicht, das wirklich funktioniert. Das sind zwei Entwürfe, und jeder braucht seine eigene Regel.

Sie zu vermischen ist der Grund, warum ein funktionierender Wrapper von außen unerreichbar wird, während jede Datei korrekt aussieht. Die Prüfung unten ist ein Befehl, und sie beantwortet eine Frage, die eine Durchsicht der Firewall-Regeln nicht beantworten kann. Wenn die Ausgabe eine loopback-Adresse zeigt, während die Weiterleitung auf die LAN-Adresse zielt, gehört die Korrektur in die accept-Zeile und nicht in den Paketfilter.

ss -lntp '( sport = :8443 )'

Was der lokale Test tatsächlich bewies

Ein Erfolg, der ohne den Sprung aufgezeichnet wird, den er abdeckte, ist kein Beweis über die anderen Sprünge. Notieren Sie, welche Adresse der Test verwendete und welcher Prozess antwortete. Wiederholen Sie es dann von außerhalb des Netzwerks statt von einem Telefon im selben WLAN, denn das Hairpin-Verhalten variiert zwischen Routern, und eine Verbindung, die das LAN nie verlassen hat, kann einen Client zufriedenstellen, ohne dass die Weiterleitung überhaupt beteiligt ist. Nur dieser zweite Versuch übt den Weg, den ein Fremder nimmt.

Wenn der Versuch scheitert, verfolgen Sie eine einzelne Verbindung über beide Logs: die angenommenen und verbundenen Zeilen des Wrappers, dann das eigene Sitzungsprotokoll des VPN-Daemons. Die erste Grenze, die nichts aufzeichnet, ist der Ort der nächsten Änderung. Sobald OpenVPN Peer-Optionen vergleicht, beurteilen Sie diese Meldungen nach den Regeln dieser Implementierung. Eine Warnung über eine link-mtu-Inkonsistenz ist nicht automatisch fatal, link-mtu auf 1500 festzunageln beweist nicht, dass die Fragmentierung aufgehört hat, und die Cipher-Aushandlung gehört zur inneren OpenVPN-Konfiguration und nicht zur Weiterleitung des Routers.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Diese Sonden decken den Backend-Socket und das Wrapper-Log ab, was einen abgelehnten Backend von einem abgelehnten Handshake trennt. Führen Sie sie aus, während ein einzelner Versuch läuft, und nicht danach. Zeitstempel aus einem einzigen Versuch machen den Vergleich glaubwürdig.

Zwei Identitäten, zwei Fehlerreihenfolgen

Das äußere Zertifikat gehört dem Wrapper und die innere Identität gehört OpenVPN, und sie können von verschiedenen Stellen stammen. Eine der beiden Prüfungen abzuschalten, damit ein Weg gesund aussieht, tauscht einen echten Schutz gegen ein kosmetisches Ergebnis. Behalten Sie beide Prüfungen und debuggen Sie sie in der Reihenfolge, denn die Reihenfolge der Meldungen benennt die Schicht: Ein Zertifikatsproblem des Wrappers erscheint, bevor irgendeine VPN-Option ausgehandelt wird, während ein Fehler der inneren Identität erst erscheint, wenn der Strom steht.

Das stunnel-Handbuch definiert accept, connect und den Client-Modus präzise, und diese Abschnitte beantworten die Socket-Frage schneller als Raten. Wenn Sie immer noch nicht sagen können, welche Schicht geantwortet hat, lesen Sie das Zertifikat, das der öffentliche Port präsentiert, mit dem Befehl unten. Ein Wrapper-Zertifikat in der Ausgabe bedeutet, dass die Weiterleitung den Wrapper erreicht hat, und Stille oder ein Protokollfehler bedeutet, dass sie es nicht tat. Diese eine Unterscheidung spart mehr Zeit als jede andere Prüfung hier.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer