OpenVPN no porto 53: tres conversas que a xente confunde
A busca do extremo, o transporte cifrado e o DNS posterior ao túnel son tres conversas. Identifica que etapa fallou antes de cambiar un porto ou un resolver.
Os informes que din que a VPN está bloqueada no porto 53 mesturan tres observacións que fallan por motivos distintos. Resolver o nome do extremo ocorre antes de que exista ningún túnel, o transporte cifrado é unha conversa aparte, e as consultas DNS feitas despois son unha terceira. Cada unha ten a súa propia sinatura de fallo, e só unha delas ten que ver co DNS.
Ordena os paquetes por propósito antes de cambiar nada, porque a solución segue a etapa.
Tres conversas, un número de porto
A primeira conversa é unha busca de nome para o extremo: a túa máquina pregunta ao resolver configurado onde está vpn.example.com, e esa resposta chega por DNS común antes de que o cliente envíe un só paquete de túnel. A segunda é o propio transporte OpenVPN, que se conecta ao enderezo que produciu a busca co protocolo e o porto que nomea o perfil. A terceira ocorre despois de que o túnel estea levantado, cando as aplicacións piden nomes e a configuración de resolver empurrada decide quen responde.
Eses tres poden ter éxito ou fallar de forma independente. Un cliente pode resolver o seu extremo perfectamente e aínda así non chegar ao listener, e pode establecer un túnel mentres todas as buscas de nomes internos fallan porque a configuración DNS nunca chegou.
| 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 |
Le a táboa como unha lista de comprobación e non como unha descrición. Se o nome do extremo non resolve, nada posterior pode funcionar, e o túnel nunca comeza.
O número de porto non nomea a aplicación
O porto 53 leva DNS por convención, e un operador de OpenVPN tamén pode publicar alí un listener, que é exactamente por que o número é un mal identificador. Unha sesión OpenVPN en UDP 53 segue a ser unha sesión OpenVPN, e unha consulta DNS a un servidor no porto 53 non di nada sobre se se permite un túnel. As liñas proto e remote do perfil definen o extremo exterior; o número de porto non define nada por si mesmo.
Iso corta polos dous lados ao diagnosticar: unha sonda UDP xenérica ao porto 53 proba que un porto responde, non que responda o servizo VPN. Proba co cliente real e co perfil real, porque só iso exercita o apretón de mans que o servizo espera.
Demostra o listener antes de culpar á rede
No servidor, confirma o que está vinculado con ss -lunp | grep 53 e compárao co protocolo e o porto do perfil. Desde a rede do cliente, executa o cliente cunha verbosidade maior para que o rexistro mostre que enderezo e transporte tentou. Se o servidor está escoitando e os paquetes do cliente non chegan, o camiño ou a política están rexeitándoos, e iso é unha conversa para o dono da rede e non un motivo para cambiar de porto.
Un porto diferente axuda só cando o servizo escoita de verdade alí e o despregamento permíteo. Mover un listener para esquivar o filtrado dunha rede xestionada é unha decisión de política, non un paso de resolución de problemas. Pregunta ao dono da rede que está permitido antes de cambiar o servizo, porque unha solución alternativa que infrinxe a política acaba pechándose de todos os xeitos. Anota esa resposta xunto ao perfil para que a seguinte persoa non repita a petición.
Comproba o DNS despois do túnel, por separado
Unha vez levantado o túnel, inspecciona o estado do resolver na interface VPN e consulta un nome interno e un nome público. Se os nomes internos fallan mentres o túnel transporta tráfico, a configuración DNS empurrada non se aplicou, o que é unha cuestión de integración do cliente e non de transporte. Se os nomes públicos fallan e os internos funcionan, a política de túnel dividido está a facer o que se configurou para facer.
Deixa os cambios de DNS co dono do resolver. Sobrescribir unha configuración de resolver xestionada para facer pasar unha proba pode romper os nomes privados para todo o demais na máquina. Se o túnel empurra un resolver e o cliente ignórao, arranxa a integración do cliente en vez de engadir unha entrada estática noutro sitio. As entradas estáticas ocultan o fallo ata que alguén cambia de rede. Anota que resolver se espera que responda cada espazo de nomes.