OpenVPN auf Port 53: drei Gespräche, die Menschen verwechseln
Endpunkt-Auflösung, der verschlüsselte Transport und DNS nach dem Tunnel sind drei Gespräche. Stellen Sie fest, welche Stufe versagt hat, bevor Sie einen Port oder einen Resolver ändern.
Berichte, die sagen, dass das VPN auf Port 53 blockiert sei, vermischen drei Beobachtungen, die aus unterschiedlichen Gründen scheitern. Die Auflösung des Endpunktnamens geschieht, bevor irgendein Tunnel existiert, der verschlüsselte Transport ist ein separates Gespräch, und die danach gestellten DNS-Anfragen sind ein drittes. Jedes hat seine eigene Fehlersignatur, und nur eines davon handelt überhaupt von DNS.
Sortieren Sie die Pakete nach Zweck, bevor Sie etwas ändern, denn die Behebung folgt der Stufe.
Drei Gespräche, eine Portnummer
Das erste Gespräch ist eine Namensauflösung für den Endpunkt: Ihr Rechner fragt seinen konfigurierten Resolver, wo vpn.example.com liegt, und diese Antwort kommt über gewöhnliches DNS an, bevor der Client ein einziges Tunnelpaket sendet. Das zweite ist der OpenVPN-Transport selbst, der sich mit der Adresse verbindet, die die Auflösung ergeben hat, und zwar über das Protokoll und den Port, die das Profil nennt. Das dritte findet statt, nachdem der Tunnel steht, wenn Anwendungen Namen anfragen und die übertragenen Resolver-Einstellungen entscheiden, wer antwortet.
Diese drei können unabhängig voneinander gelingen oder scheitern. Ein Client kann seinen Endpunkt einwandfrei auflösen und dennoch den Listener nicht erreichen, und er kann einen Tunnel aufbauen, während jede interne Namensauflösung scheitert, weil die DNS-Einstellungen nie angekommen sind.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Lesen Sie die Tabelle als Checkliste, nicht als Beschreibung. Wenn der Endpunktname nicht aufgelöst wird, kann später nichts funktionieren, und der Tunnel startet nie.
Die Portnummer benennt nicht die Anwendung
Port 53 trägt DNS per Konvention, und ein OpenVPN-Betreiber kann dort ebenfalls einen Listener veröffentlichen, weshalb die Nummer ein schlechter Bezeichner ist. Eine OpenVPN-Sitzung auf UDP 53 bleibt eine OpenVPN-Sitzung, und eine DNS-Anfrage an einen Server auf Port 53 sagt nichts darüber aus, ob ein Tunnel erlaubt ist. Die Zeilen proto und remote im Profil definieren den äußeren Endpunkt; die Portnummer definiert für sich genommen nichts.
Das schneidet bei der Diagnose in beide Richtungen: Eine allgemeine UDP-Sonde auf Port 53 beweist, dass ein Port antwortet, nicht dass der VPN-Dienst antwortet. Testen Sie mit dem echten Client und dem echten Profil, denn nur das übt den Handshake aus, den der Dienst erwartet.
Beweisen Sie den Listener, bevor Sie das Netzwerk beschuldigen
Prüfen Sie auf dem Server mit ss -lunp | grep 53, was gebunden ist, und vergleichen Sie es mit Protokoll und Port des Profils. Starten Sie den Client aus dem Netz des Clients mit höherer Ausführlichkeit, damit das Protokoll zeigt, welche Adresse und welchen Transport er versucht hat. Wenn der Server lauscht und die Pakete des Clients nicht ankommen, weisen der Pfad oder die Richtlinie sie ab, und das ist ein Gespräch für den Netzwerkeigentümer statt ein Grund, Ports zu wechseln.
Ein anderer Port hilft nur, wenn der Dienst dort tatsächlich lauscht und die Bereitstellung es zulässt. Einen Listener zu verschieben, um die Filterung eines verwalteten Netzes zu umgehen, ist eine Richtlinienentscheidung, kein Fehlerbehebungsschritt. Fragen Sie den Netzwerkeigentümer, was erlaubt ist, bevor Sie den Dienst ändern, denn eine Umgehung, die gegen die Richtlinie verstößt, wird später ohnehin geschlossen. Notieren Sie diese Antwort neben dem Profil, damit die nächste Person die Anfrage nicht wiederholt.
Prüfen Sie DNS nach dem Tunnel, separat
Sobald der Tunnel steht, untersuchen Sie den Resolver-Zustand auf der VPN-Schnittstelle und fragen Sie einen internen und einen öffentlichen Namen ab. Wenn interne Namen scheitern, während der Tunnel Verkehr trägt, wurden die übertragenen DNS-Einstellungen nicht angewandt, was eine Frage der Client-Integration und nicht des Transports ist. Wenn öffentliche Namen scheitern und interne funktionieren, tut die Split-Tunnel-Richtlinie das, wofür sie konfiguriert wurde.
Lassen Sie DNS-Änderungen beim Eigentümer des Resolvers. Das Überschreiben einer verwalteten Resolver-Konfiguration, damit ein Test besteht, kann private Namen für alles andere auf dem Rechner brechen. Wenn der Tunnel einen Resolver überträgt und der Client ihn ignoriert, reparieren Sie die Client-Integration, statt anderswo einen statischen Eintrag hinzuzufügen. Statische Einträge verbergen den Fehler, bis jemand das Netz wechselt. Schreiben Sie auf, welcher Resolver welchen Namensraum beantworten soll.