Que ligazón responde: dominios de enrutamento para o DNS dunha VPN de túnel dividido

Manteña a navegación normal na ligazón local mentres os nomes da empresa se resolven polo servidor DNS que fornece o túnel. Desactivar a ruta predeterminada da VPN dá a primeira metade e deixa a segunda sen construír. O que segue é o axuste que falta, a puntuación que cambia o seu significado e o único comando que mostra que ligazón respondeu realmente. Supóñense NetworkManager e systemd-resolved en todo o texto, porque é nesa parella onde adoita comezar a confusión.

Primeiro paso: separe a ruta do resolutor

ipv4.never-default responde unha pregunta de enrutamento e impide que NetworkManager instale esta conexión como camiño para todo o tráfico IPv4. Un dominio de enrutamento DNS responde outra pregunta: que servidores de nomes de que ligazón reciben unha consulta para un sufixo coincidente. Ningún implica o outro, e un perfil pode levar un durante anos mentres lle falta o outro. Só ruta significa que o túnel transporta as subredes da empresa e o seu resolutor responde os nomes da empresa, mentres todo o demais queda intacto.

Configure só a propiedade de ruta e os nomes internos fallan, normalmente cun tempo de espera que soa a túnel roto. Configure só o dominio e terá engadido en silencio un sufixo de busca a cada nome curto da máquina. Ambos erros envían o ticket ao servidor VPN, que raramente é a parte equivocada.

Segundo paso: engada un dominio só de enrutamento ao perfil

Supoñamos que a conexión se chama corp-vpn, o sufixo da empresa é internal.example e o resolutor do túnel xa é accesible. Lea primeiro os valores actuais, porque os comandos de abaixo cambian propiedades que xa poden ter entradas.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Substitúa polo seu propio nome de conexión e sufixo, porque os valores de arriba son ilustrativos. O signo máis importa máis do que parece: con el o valor engádese á lista existente, mentres que sen el a propiedade substitúese e dominios non relacionados desaparecen dun perfil que onte funcionaba. O til cambia o comportamento, non o estilo, e o parágrafo de abaixo cobre que selecciona. Manteña a lectura antes da escritura, para que a forma de substitución nunca o sorprenda.

Un til inicial marca un dominio só de enrutamento, así que as consultas coincidentes van aos servidores desta ligazón e o sufixo non se engade aos nomes curtos. Quite o til e a mesma cadea tamén se converte en sufixo de busca, que é un resultado distinto que a xente raramente pretende. Ambos axustes de arriba son IPv4, así que un perfil de dobre pila necesita ipv6.never-default e o mesmo dominio de enrutamento en ipv6.dns-search, ou o lado IPv6 segue usando a ruta predeterminada e os nomes internos fallan alí.

Terceiro paso: pregunte a resolvectl que ligazón respondeu

Execute resolvectl status e lea os servidores DNS e os dominios de cada ligazón, despois execute resolvectl query host.internal.example contra un nome interno real que teña permiso para consultar. O segundo comando é a única proba directa de que o dominio de enrutamento fai o seu traballo, porque nomea a ligazón que respondeu. Unha listaxe de estado por si soa proba a configuración; a consulta proba a resolución.

systemd-resolved escolle o dominio de enrutamento que mellor coincide, así que un dominio máis específico noutra ligazón aínda pode gañar a carreira. Se a consulta volve dunha ligazón que non esperaba, lea as listas de dominios antes de tocar o servidor DNS da VPN. Un dominio raíz de ~. coincide con todo, e se xa está presente o seu dominio específico segue gañando para os seus propios nomes mentres a ligazón responde moito máis do que pediu. Elimine ou estreite esa entrada raíz cando a intención era só nomes da empresa.

Se a ligazón da VPN non lista ningún servidor DNS, o cliente nunca rexistrou un. Un dominio de enrutamento sen servidor detrás falla de forma distinta a un dominio ausente, así que arranxe primeiro o rexistro.

Cuarto paso: cando o nome resolve pero o servizo non

Unha resposta correcta só proba que a resolución funcionou, e a aplicación aínda necesita unha ruta cara ao enderezo que recibiu. Esa ruta ten que sobrevivir á ruta predeterminada dividida que acaba de configurar, así que compróbea antes de culpar de novo o DNS. Despois comprobe a accesibilidade no porto do servizo, porque un recurso compartido ou un servizo de directorio falla na resolución, no enrutamento ou na autenticación e produce mensaxes moi semellantes en cada caso. Manteña esas tres capas separadas ao informar do resultado, ou a persoa seguinte volve comprobar un DNS que xa era correcto.

O cambio de Samba que circula xunto a esta pregunta aborda a capa de acceso, non a elección de DNS. Aplicarlo a un fallo de resolución de nomes é como un problema pequeno adquire un segundo.

Quinto paso: non substitúa o resolutor para arranxar un dominio ausente

O consello que sobrescribe o ficheiro do resolutor ou instala outro xestor de resolutor resolve un problema distinto. Son cambios de integración do sistema cos seus propios modos de fallo, e ningún engade un dominio de enrutamento que nunca se configurou. Determine que compoñente posúe a resolución de nomes na máquina antes de substituílo, porque nun escritorio con NetworkManager e systemd-resolved esa propiedade xa está definida. Loitar contra ela é como unha configuración que funciona se converte en algo que ninguén pode reproducir.

Orde de traballo: confirme que o túnel fornece un resolutor, engada o dominio só de enrutamento, reconecte mediante os controis do perfil, verifique a ligazón que responde e despois probe o servizo no seu porto. Esa secuencia deixa un resultado que pode entregar á persoa seguinte sen unha segunda entrevista.