OpenVPN på port 53: tre samtaler folk blander sammen
Oppslag av endepunktet, den krypterte transporten og DNS etter tunnelen er tre samtaler. Finn ut hvilket trinn som feilet før du bytter port eller resolver.
Rapporter som sier at VPN-en er blokkert på port 53 blander sammen tre observasjoner som feiler av ulike grunner. Oppslag av endepunktets navn skjer før noen tunnel finnes, den krypterte transporten er en egen samtale, og DNS-spørringene som gjøres etterpå er den tredje. Hver har sin egen feilsignatur, og bare én av dem handler om DNS i det hele tatt.
Sorter pakkene etter formål før du endrer noe, fordi rettelsen følger trinnet.
Tre samtaler, ett portnummer
Den første samtalen er et navneoppslag for endepunktet: maskinen din spør den konfigurerte resolven hvor vpn.example.com ligger, og svaret kommer over vanlig DNS før klienten sender én eneste tunnelpakke. Den andre er selve OpenVPN-transporten, som kobler til adressen oppslaget ga, på det protokoll og den porten profilen angir. Den tredje skjer etter at tunnelen er oppe, når applikasjoner ber om navn og de påtrykte resolverinnstillingene avgjør hvem som svarer.
Disse tre kan lykkes eller feile uavhengig av hverandre. En klient kan slå opp endepunktet sitt perfekt og likevel ikke nå lytteren, og den kan etablere en tunnel mens hvert internt navneoppslag feiler fordi DNS-innstillingene aldri kom frem.
| 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 |
Les tabellen som en sjekkliste og ikke som en beskrivelse. Hvis endepunktets navn ikke lar seg slå opp, kan ingenting senere virke, og tunnelen starter aldri.
Portnummeret navngir ikke applikasjonen
Port 53 bærer DNS av konvensjon, og en OpenVPN-operatør kan også publisere en lytter der, og nettopp derfor er nummeret en dårlig identifikator. En OpenVPN-økt på UDP 53 er fortsatt en OpenVPN-økt, og en DNS-spørring til en server på port 53 sier ingenting om hvorvidt en tunnel er tillatt. Linjene proto og remote i profilen definerer det ytre endepunktet; portnummeret definerer ingenting i seg selv.
Det skjærer begge veier under feilsøking: en generisk UDP-probe mot port 53 beviser at en port svarer, ikke at VPN-tjenesten svarer. Test med den ekte klienten og den ekte profilen, fordi bare det øver på håndtrykket tjenesten forventer.
Bevis lytteren før du klandrer nettet
På serveren, bekreft hva som er bundet med ss -lunp | grep 53 og sammenlign med profilens protokoll og port. Fra klientens nettverk, kjør klienten med høyere detaljgrad slik at loggen viser hvilken adresse og transport den forsøkte. Hvis serveren lytter og klientens pakker ikke kommer frem, er det ruten eller policyen som avviser dem, og det er en samtale med nettverkseieren og ikke en grunn til å bytte port.
En annen port hjelper bare når tjenesten faktisk lytter der og utrullingen tillater det. Å flytte en lytter for å unngå filtrering i et administrert nett er en policybeslutning, ikke et feilsøkingstrinn. Spør nettverkseieren om hva som er tillatt før du endrer tjenesten, fordi en omvei som bryter policyen blir stengt senere uansett. Skriv ned svaret ved siden av profilen slik at neste person ikke gjentar forespørselen.
Sjekk DNS etter tunnelen, separat
Når tunnelen er oppe, undersøk resolverens tilstand på VPN-grensesnittet og spør om ett internt navn og ett offentlig navn. Hvis interne navn feiler mens tunnelen bærer trafikk, er de påtrykte DNS-innstillingene ikke anvendt, noe som er et spørsmål om klientintegrasjon og ikke om transport. Hvis offentlige navn feiler og interne navn virker, gjør policyen for delt tunnel det den ble konfigurert til.
La DNS-endringene ligge hos resolverens eier. Å overskrive en administrert resolverkonfigurasjon for å få én test til å passere kan ødelegge private navn for alt annet på maskinen. Hvis tunnelen skyver ut en resolver og klienten ignorerer den, reparer klientintegrasjonen i stedet for å legge til en statisk oppføring et annet sted. Statiske oppføringer skjuler feilen til noen bytter nettverk. Skriv ned hvilken resolver som forventes å svare for hvert navnerom.