OpenVPN på port 53: tre samtaler, som folk forveksler
Endepunktsopslag, den krypterede transport og DNS efter tunnelen er tre samtaler. Find ud af, hvilket trin der fejlede, før du ændrer en port eller en resolver.
Rapporter, der siger, at VPN’en er blokeret på port 53, blander tre observationer, som fejler af forskellige årsager. Opslaget af endepunktets navn sker, før der findes nogen tunnel, den krypterede transport er en separat samtale, og de DNS-forespørgsler, der laves bagefter, er en tredje. Hver har sin egen fejlsignatur, og kun én af dem handler om DNS overhovedet.
Sortér pakkerne efter formål, før du ændrer noget, fordi rettelsen følger trinnet.
Tre samtaler, ét portnummer
Den første samtale er et navneopslag for endepunktet: din maskine spørger sin konfigurerede resolver, hvor vpn.example.com ligger, og det svar kommer over almindelig DNS, før klienten sender en eneste tunnelpakke. Den anden er selve OpenVPN-transporten, som forbinder til den adresse, opslaget gav, på den protokol og den port, som profilen angiver. Den tredje sker, efter at tunnelen er oppe, når programmer beder om navne, og de pushede resolverindstillinger afgør, hvem der svarer.
De tre kan lykkes eller fejle uafhængigt. En klient kan slå sit endepunkt perfekt op og alligevel ikke nå lytteren, og den kan etablere en tunnel, mens hvert internt navneopslag fejler, fordi DNS-indstillingerne aldrig ankom.
| 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 |
Læs tabellen som en tjekliste, ikke som en beskrivelse. Hvis endepunktets navn ikke slår op, kan intet senere virke, og tunnelen starter aldrig.
Portnummeret navngiver ikke programmet
Port 53 bærer DNS efter konvention, og en OpenVPN-operatør kan også udgive en lytter der, og det er netop derfor, nummeret er en dårlig identifikator. En OpenVPN-session på UDP 53 er stadig en OpenVPN-session, og en DNS-forespørgsel til en server på port 53 siger intet om, hvorvidt en tunnel er tilladt. Profilens proto- og remote-linjer definerer det ydre endepunkt; portnummeret definerer intet i sig selv.
Det skærer begge veje, når man diagnosticerer: en generisk UDP-test til port 53 beviser, at en port svarer, ikke at VPN-tjenesten svarer. Test med den rigtige klient og den rigtige profil, fordi kun det udøver det håndtryk, som tjenesten forventer.
Bevis lytteren, før du bebrejder netværket
På serveren skal du bekræfte, hvad der er bundet med ss -lunp | grep 53 og sammenligne det med profilens protokol og port. Fra klientens netværk kan du køre klienten med højere detaljeringsgrad, så loggen viser, hvilken adresse og transport den forsøgte. Hvis serveren lytter, og klientens pakker ikke ankommer, afviser ruten eller politikken dem, og det er en samtale for netværksejeren snarere end en grund til at skifte porte.
En anden port hjælper kun, når tjenesten faktisk lytter der, og udrulningen tillader det. At flytte en lytter for at undgå et administreret netværks filtrering er en politisk beslutning, ikke et fejlfindingsskridt. Spørg netværksejeren, hvad der er tilladt, før du ændrer tjenesten, fordi en omvej, der bryder politikken, alligevel lukkes senere. Skriv svaret ned ved siden af profilen, så den næste person ikke gentager anmodningen.
Tjek DNS efter tunnelen, separat
Når tunnelen er oppe, skal du undersøge resolverens tilstand på VPN-interfacet og forespørge et internt navn og et offentligt navn. Hvis interne navne fejler, mens tunnelen bærer trafik, blev de pushede DNS-indstillinger ikke anvendt, hvilket er et spørgsmål om klientintegration og ikke om transport. Hvis offentlige navne fejler, og interne navne virker, gør split-tunnel-politikken det, den blev konfigureret til.
Hold DNS-ændringer hos resolverens ejer. At overskrive en administreret resolverkonfiguration for at få én test til at bestå kan ødelægge private navne for alt andet på maskinen. Hvis tunnelen pusher en resolver, og klienten ignorerer den, skal du rette klientintegrationen i stedet for at tilføje en statisk post et andet sted. Statiske poster skjuler fejlen, indtil nogen skifter netværk. Skriv ned, hvilken resolver der forventes at svare på hvert navneområde.