OpenVPN al port 53: tres converses que la gent confon
La consulta de l’extrem, el transport xifrat i el DNS posterior al túnel són tres converses. Identifiqueu quina etapa ha fallat abans de canviar un port o un resolutor.
Els informes que diuen que la VPN està bloquejada al port 53 barregen tres observacions que fallen per motius diferents. La resolució del nom de l’extrem passa abans que existeixi cap túnel, el transport xifrat és una conversa a part i les consultes DNS fetes després són una tercera. Cadascuna té la seva pròpia signatura de fallada, i només una de les tres tracta realment de DNS.
Classifiqueu els paquets per propòsit abans de canviar res, perquè la solució segueix l’etapa.
Tres converses, un número de port
La primera conversa és una consulta de nom per a l’extrem: la vostra màquina pregunta al resolutor configurat on és vpn.example.com, i aquesta resposta arriba per DNS ordinari abans que el client enviï cap paquet de túnel. La segona és el transport d’OpenVPN mateix, que es connecta a l’adreça que ha produït la consulta amb el protocol i el port que indica el perfil. La tercera passa quan el túnel ja és actiu, quan les aplicacions demanen noms i la configuració de resolutor empenyuda decideix qui respon.
Aquestes tres poden tenir èxit o fallar de manera independent. Un client pot resoldre perfectament el seu extrem i tot i així no arribar a l’oient, i pot establir un túnel mentre tota consulta de nom interna falla perquè la configuració DNS mai no ha arribat.
| 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 |
Llegiu la taula com una llista de verificació, no com una descripció. Si el nom de l’extrem no es resol, res del que ve després pot funcionar i el túnel no s’inicia mai.
El número de port no anomena l’aplicació
El port 53 porta DNS per convenció, i un operador d’OpenVPN també pot publicar-hi un oient, i per això mateix el número és un mal identificador. Una sessió d’OpenVPN sobre UDP 53 continua sent una sessió d’OpenVPN, i una consulta DNS a un servidor al port 53 no diu res sobre si es permet un túnel. Les línies proto i remote del perfil defineixen l’extrem exterior; el número de port no defineix res per si mateix.
Això talla en les dues direccions en diagnosticar: una sonda UDP genèrica al port 53 demostra que un port respon, no que respongui el servei VPN. Proveu amb el client real i el perfil real, perquè només això exerceix l’intercanvi que el servei espera.
Demostreu l’oient abans de culpar la xarxa
Al servidor, confirmeu què està lligat amb ss -lunp | grep 53 i compareu-ho amb el protocol i el port del perfil. Des de la xarxa del client, executeu el client amb més verbositat perquè el registre mostri quina adreça i quin transport ha provat. Si el servidor escolta i els paquets del client no arriben, el camí o la política els rebutgen, i això és una conversa per al propietari de la xarxa, no un motiu per canviar de port.
Un port diferent ajuda només quan el servei hi escolta de debò i el desplegament ho permet. Moure un oient per esquivar el filtratge d’una xarxa gestionada és una decisió de política, no un pas de resolució de problemes. Pregunteu al propietari de la xarxa què està permès abans de canviar el servei, perquè una solució alternativa que vulnera la política es tancarà més tard igualment. Anoteu aquesta resposta al costat del perfil perquè la propera persona no repeteixi la petició.
Comproveu el DNS després del túnel, per separat
Un cop el túnel és actiu, inspecteu l’estat del resolutor a la interfície VPN i consulteu un nom intern i un nom públic. Si els noms interns fallen mentre el túnel transporta trànsit, la configuració DNS empenyuda no s’ha aplicat, cosa que és una qüestió d’integració del client i no de transport. Si els noms públics fallen i els interns funcionen, la política de túnel dividit fa allò per a què es va configurar.
Deixeu els canvis de DNS a mans del propietari del resolutor. Sobreescriure una configuració de resolutor gestionada per fer passar una prova pot trencar noms privats per a tota la resta de la màquina. Si el túnel empeny un resolutor i el client l’ignora, corregiu la integració del client en lloc d’afegir una entrada estàtica en un altre lloc. Les entrades estàtiques amaguen la fallada fins que algú canvia de xarxa. Anoteu quin resolutor ha de respondre cada espai de noms.