OpenVPN ha enviat un servidor DNS, però Linux l’ignora

El servidor DNS enviat és al registre, el túnel està aixecat i els noms interns encara fallen. No hi ha res trencat en l’enviament; el paràmetre va arribar i es va aturar allà. Una opció DNS enviada és un missatge al client, no una instrucció al resolutor del sistema operatiu, i el lliurament entre tots dos és on acaben la majoria d’aquests casos. Cinc comprovacions, en ordre, troben el lliurament que no es va produir.

Comprovació primera: com comença la connexió

El propietari de la connexió determina qui pot aplicar la configuració del resolutor. Una ordre openvpn directa des d’un shell no posseeix res més que el seu propi procés, mentre que una unitat systemd, NetworkManager o un client de fabricant tenen cadascun la seva manera de publicar DNS. Llegiu la llista de processos i el nom de la unitat abans de suposar cap d’ells.

Un procés de línia d’ordres no és automàticament una connexió de NetworkManager, i una connexió de NetworkManager no és automàticament allò que va escriure resolv.conf. Aquestes dues suposicions expliquen la major part de les hores perdudes en aquesta investigació. Pregunteu quin component publicaria DNS per a la interfície que realment veieu.

Anoteu el propietari abans de continuar. Cada comprovació posterior en depèn.

Comprovació segona: què conté realment l’enllaç del resolutor

En un amfitrió amb systemd-resolved, resolvectl status llista cada enllaç amb els seus servidors DNS i dominis. Trobeu l’enllaç del túnel i llegiu-ne les entrades, i no suposeu que la interfície es diu tun0, perquè la numeració segueix l’ordre de creació. Si l’adreça enviada no és a l’enllaç, el que ha fallat és el lliurament, no la consulta.

Si l’adreça hi és, la pregunta següent és quins dominis reclama aquest enllaç. Un enllaç sense llista de dominis només respon els noms pels quals se li pregunta directament, cosa que poques vegades vol un desplegament split-DNS. L’adreça sola és necessària però no suficient.

Compareu el nom de l’enllaç a la sortida del resolutor amb el nom de la interfície al registre del VPN abans de treure cap conclusió. Una discrepància allà normalment vol dir que la línia del registre ve d’un altre procés.

Comprovació tercera: si l’espai de noms tria aquest enllaç

Un resolutor pot tenir el servidor correcte i tot i així no ser consultat. El domini per enllaç decideix quines consultes van a quin enllaç, i sense un domini d’encaminament l’espai de noms privat recau en el que diu l’enllaç per defecte. Per això resolvectl query pot tenir èxit per al nom intern mentre una aplicació encara falla. L’aplicació pot estar fent servir un camí de resolutor completament diferent.

Comproveu l’assignació de domini, no només l’adreça del servidor. Un domini escrit com ~corp.example és un domini d’encaminament, i la titlla canvia com es fa coincidir el nom.

Si l’aplicació té el seu propi resolutor, proveu amb el mateix mecanisme que fa servir ella i no amb l’eina del sistema. Una eina de consulta que evita el resolutor del sistema tindrà èxit sigui quin sigui l’estat de l’enllaç.

Comprovació quarta: un propietari, no dos

Si NetworkManager ja gestiona el VPN i l’estat del resolutor, afegir un script de ganxo no relacionat crea escriptors competidors. El ganxo que proporciona el paquet per a systemd-resolved és una integració suportada i espera un cicle de vida concret: script-security 2, un camí up, up-restart, un camí down i down-pre. Aquestes opcions fan que el registre i la retirada passin en els moments correctes i no només en la primera connexió.

Feu servir el camí instal·lat pel paquet i no un d’il·lustratiu copiat d’una guia. Els permisos també importen, perquè el ganxo s’executa després de deixar anar els privilegis.

Editar un script de resolutor de la distribució per canviar-ne la destinació de sortida registra una solució temporal d’un sol amfitrió. No és una reparació general.

Comprovació cinquena: el mateix resultat després de reconnectar

Reconnecteu i torneu a llegir l’enllaç. Un registre que apareix una vegada i desapareix a la transició següent és la fallada per a la qual existeix tota aquesta llista. Proveu després d’una suspensió, després d’una reconnexió forçada i després de reiniciar el servei del resolutor. Cada transició posa a prova una suposició d’ordenació diferent.

Només quan les cinc comprovacions passen en una reconnexió podeu dir que la configuració enviada s’està utilitzant. Qualsevol cosa anterior és una instantània d’un moment afortunat.