OpenVPN enviou un servidor DNS, pero Linux ignórao

O servidor DNS enviado está no rexistro, o túnel está levantado e os nomes internos seguen fallando. Nada está roto no envío en si; o axuste chegou e detívose alí. Unha opción DNS enviada é unha mensaxe ao cliente, non unha instrución ao resolutor do sistema operativo, e a entrega entre ambos é onde rematan a maioría destes casos. Cinco comprobacións, en orde, atopan a entrega que non ocorreu.

Comprobación un: como comeza a conexión

O dono da conexión determina quen pode aplicar os axustes do resolutor. Un comando openvpn directo desde un shell non posúe nada máis que o seu propio proceso, mentres que unha unidade systemd, NetworkManager ou un cliente de fabricante teñen cada un a súa propia forma de publicar DNS. Lea a lista de procesos e o nome da unidade antes de supoñer calquera deles.

Un proceso de liña de ordes non é automaticamente unha conexión de NetworkManager, e unha conexión de NetworkManager non é automaticamente o que escribiu resolv.conf. Esas dúas suposicións explican a maior parte das horas perdidas nesta investigación. Pregunte que compoñente publicaría DNS para a interface que realmente ve.

Anote o dono antes de continuar. Cada comprobación posterior depende del.

Comprobación dous: que contén realmente a ligazón do resolutor

Nun host con systemd-resolved, resolvectl status enumera cada ligazón cos seus servidores DNS e dominios. Atope a ligazón do túnel e lea as súas entradas, e non supoña que a interface se chama tun0, porque a numeración segue a orde de creación. Se o enderezo enviado non está na ligazón, o que fallou foi a entrega, non a consulta.

Se o enderezo está presente, a seguinte pregunta é que dominios reclama esa ligazón. Unha ligazón sen lista de dominios só responde os nomes polos que se lle pregunta directamente, e iso raramente é o que quere un despregamento split-DNS. O enderezo só é necesario pero non abonda.

Compare o nome da ligazón na saída do resolutor co nome da interface no rexistro do VPN antes de sacar calquera conclusión. Unha discrepancia alí adoita significar que a liña do rexistro veu doutro proceso.

Comprobación tres: se o espazo de nomes escolle esa ligazón

Un resolutor pode ter o servidor correcto e aínda así non ser consultado. O dominio por ligazón decide que consultas van a que ligazón, e sen un dominio de encamiñamento o espazo de nomes privado recae no que di a ligazón predeterminada. Por iso resolvectl query pode ter éxito para o nome interno mentres unha aplicación segue fallando. Pode que a aplicación use unha ruta de resolutor completamente distinta.

Comprobe a asignación de dominio, non só o enderezo do servidor. Un dominio escrito como ~corp.example é un dominio de encamiñamento, e a til cambia como se fai coincidir o nome.

Se a aplicación ten o seu propio resolutor, probe co mesmo mecanismo que usa ela en lugar de coa ferramenta do sistema. Unha ferramenta de consulta que evita o resolutor do sistema terá éxito independentemente do estado da ligazón.

Comprobación catro: un dono, non dous

Se NetworkManager xa xestiona o VPN e o estado do resolutor, engadir un script de gancho non relacionado crea escritores que compiten. O gancho que o paquete proporciona para systemd-resolved é unha integración soportada e espera un ciclo de vida concreto: script-security 2, unha ruta up, up-restart, unha ruta down e down-pre. Esas opcións fan que o rexistro e a retirada ocorran nos momentos correctos e non só na primeira conexión.

Use a ruta instalada polo paquete en lugar dunha ilustrativa copiada dunha guía. Os permisos tamén importan, porque o gancho execútase despois de que baixen os privilexios.

Editar un script de resolutor da distribución para cambiar o seu destino de saída rexistra unha solución temporal dun só host. Non é unha reparación xeral.

Comprobación cinco: o mesmo resultado tras reconectar

Reconecte e volva ler a ligazón. Un rexistro que aparece unha vez e desaparece na seguinte transición é o fallo para o que existe toda esta lista. Probe tras unha suspensión, tras unha reconexión forzada e tras reiniciar o servizo do resolutor. Cada transición pon a proba unha suposición de orde distinta.

Só cando as cinco comprobacións pasan nunha reconexión pode dicir que os axustes enviados están en uso. Calquera cousa anterior é unha instantánea dun momento afortunado.