OpenVPN op poort 53: drie gesprekken die mensen verwarren
Het opzoeken van het endpoint, het versleutelde transport en DNS na de tunnel zijn drie gesprekken. Bepaal welke fase faalde voordat u een poort of resolver wijzigt.
Rapporten die zeggen dat de VPN op poort 53 geblokkeerd is, mengen drie observaties die om verschillende redenen mislukken. Het opzoeken van de endpointnaam gebeurt voordat er een tunnel bestaat, het versleutelde transport is een apart gesprek, en de DNS-query's die daarna worden gedaan zijn de derde. Elk heeft zijn eigen faalhandtekening, en slechts één ervan gaat helemaal over DNS.
Sorteer de pakketten op doel voordat u iets wijzigt, want de oplossing volgt de fase.
Drie gesprekken, één poortnummer
Het eerste gesprek is een naamopzoeking voor het endpoint: uw machine vraagt de geconfigureerde resolver waar vpn.example.com staat, en dat antwoord komt via gewone DNS binnen voordat de client ook maar één tunnelpakket verstuurt. Het tweede is het OpenVPN-transport zelf, dat verbinding maakt met het adres dat de opzoeking opleverde, op het protocol en de poort die het profiel noemt. Het derde gebeurt nadat de tunnel staat, wanneer toepassingen namen vragen en de gepushte resolverinstellingen bepalen wie antwoordt.
Die drie kunnen onafhankelijk slagen of falen. Een client kan zijn endpoint perfect opzoeken en toch de listener niet bereiken, en hij kan een tunnel opzetten terwijl elke interne naamopzoeking mislukt omdat de DNS-instellingen nooit zijn aangekomen.
| 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 |
Lees de tabel als een checklist en niet als een beschrijving. Als de endpointnaam niet oplost, kan niets later werken, en de tunnel begint nooit.
Het poortnummer noemt de toepassing niet
Poort 53 draagt DNS volgens afspraak, en een OpenVPN-beheerder kan daar ook een listener publiceren, en juist daarom is het nummer een slechte identificatie. Een OpenVPN-sessie op UDP 53 blijft een OpenVPN-sessie, en een DNS-query naar een server op poort 53 zegt niets over de vraag of een tunnel is toegestaan. De regels proto en remote van het profiel bepalen het buitenste endpoint; het poortnummer bepaalt op zichzelf niets.
Dat snijdt bij het diagnosticeren twee kanten op: een generieke UDP-probe naar poort 53 bewijst dat een poort antwoordt, niet dat de VPN-dienst antwoordt. Test met de echte client en het echte profiel, want alleen dat oefent de handshake die de dienst verwacht.
Bewijs de listener voordat u het netwerk de schuld geeft
Controleer op de server wat er gebonden is met ss -lunp | grep 53 en vergelijk dat met het protocol en de poort van het profiel. Voer vanuit het netwerk van de client de client uit met meer detail, zodat het log laat zien welk adres en transport hij probeerde. Als de server luistert en de pakketten van de client komen niet aan, dan weigeren het pad of het beleid ze, en dat is een gesprek met de netwerkbeheerder en niet een reden om van poort te wisselen.
Een andere poort helpt alleen als de dienst daar echt luistert en de uitrol het toestaat. Een listener verplaatsen om de filtering van een beheerd netwerk te omzeilen is een beleidsbeslissing, geen probleemoplossingsstap. Vraag de netwerkbeheerder wat is toegestaan voordat u de dienst wijzigt, want een omweg die het beleid schendt wordt later toch gesloten. Noteer dat antwoord naast het profiel zodat de volgende persoon het verzoek niet herhaalt.
Controleer DNS na de tunnel, apart
Zodra de tunnel staat, inspecteert u de resolverstatus op de VPN-interface en vraagt u één interne en één openbare naam op. Als interne namen falen terwijl de tunnel verkeer draagt, zijn de gepushte DNS-instellingen niet toegepast, wat een kwestie van clientintegratie is en niet van transport. Als openbare namen falen en interne namen werken, doet het split-tunnelbeleid wat het is geconfigureerd om te doen.
Laat DNS-wijzigingen bij de beheerder van de resolver. Een beheerde resolverconfiguratie overschrijven om één test te laten slagen kan privénamen breken voor al het andere op de machine. Als de tunnel een resolver pusht en de client die negeert, repareer dan de clientintegratie in plaats van elders een statische vermelding toe te voegen. Statische vermeldingen verbergen de fout tot iemand van netwerk wisselt. Schrijf op welke resolver welke naamruimte hoort te beantwoorden.