Dous VPN, un só resolver: gaña quen escribiu o último

Hai dous clientes VPN conectados, un para o traballo e outro para unha rede de laboratorio, e os nomes internos só se resolven para o cliente que se conectou ao final. Ese patrón parece un erro nun dos clientes. Normalmente é o resultado previsible de dous programas que escriben a mesma configuración de resolvedor sen acordar quen é dono de cada nome.

O mito: o VPN máis novo é dono do DNS

Non existe unha regra xeral de que gañe a conexión máis recente. O que ocorre depende do mecanismo da plataforma e de como o escriba cada cliente. Un cliente que substitúe un ficheiro de resolvedor produce un resultado; un cliente que engade un dominio por ligazón produce outro; un cliente que non fai nada deixa intacto o estado anterior.

Así que o comportamento observado é unha propiedade das dúas implementacións, non unha prioridade documentada. Razoar sobre el só a partir da orde de inicio acertará ás veces e fallará de formas difíciles de reproducir. Escriba a correspondencia. Un deseño que vive en dous clientes non é un deseño.

Asigne espazos de nomes a resolvedores

Enumere os sufixos privados e o resolvedor que esixe cada rede, e despois decida onde deben ir os nomes públicos. Esa lista é o deseño. Sen ela, os clientes toman a decisión por accidente.

Unha plataforma que admite DNS por ligazón ou dominios de encamiñamento pode expresar a división deliberadamente: un dominio vai a unha ligazón, outro dominio á outra, e todo o demais segue un valor predeterminado explícito. Dous scripts planos que sobrescriben o mesmo ficheiro non poden preservar ese deseño, porque cada un cre que é dono de toda a configuración.

En Windows, a táboa de directivas de resolución de nomes pode dirixir sufixos a servidores concretos, e un cliente VPN pode instalar regras alí. Revise a directiva en lugar da lista de adaptadores, porque a lista de adaptadores non é o que resolve o nome.

Manteña unha ruta de arranque

Cada cliente debe localizar o seu propio punto final antes de poder usar o servizo que ese punto final ofrece. Se o nome de host do punto final só se pode resolver a través do túnel, e o túnel necesita o nome de host resolto, ten unha dependencia circular que aparece como un tempo de espera de conexión. Manteña unha ruta de arranque fóra de ambos túneles. Non custa nada ata o día en que salva a conexión.

Mire a ruta cara a cada resolvedor, non só o nome configurado para el. Un resolvedor ao que só se chega a través do outro túnel compórtase como un ausente, e o síntoma é un tempo de espera en lugar dun erro de encamiñamento.

Os enderezos superpostos non son un problema de DNS

Dúas redes privadas que usan o mesmo rango de enderezos non se arranxan coa orde do DNS. Se ambos túneles reclaman 10.0.0.0/8, un nome que se resolve correctamente segue apuntando a un enderezo ao que o host non pode encamiñar cara ao túnel correcto. Iso necesita unha solución a nivel de enderezo, como rangos distintos, un espazo de nomes ou tradución, non outro axuste de resolvedor. Decidilo pronto evita un longo desvío por unha configuración de DNS que nunca ía funcionar.

Compare as asignacións de enderezos de ambos túneles antes de culpar a resolución de nomes. Cando ambos extremos empuxan o mesmo prefixo, o host conserva unha soa ruta para el, e un nome resolto a través do segundo túnel segue aterrando nun enderezo que posúe o primeiro túnel. Rangos distintos, un espazo de nomes por rede ou tradución son as correccións; tras conectar cada cliente, confirme que a táboa de rutas mostra o camiño que pretendía.

Demostre isto con aplicacións reais

Escolla dous hosts que só existan dentro do seu propio espazo de nomes e un nome público, e despois resolva cada un a través do cliente que debería posuílo. Unha resposta correcta do resolvedor esperado non demostra que a aplicación chegue ao host, porque a ruta cara a ese enderezo aínda pode fallar. Acompañe cada consulta cunha proba de conexión desde o programa que o usuario executará de verdade.

Un cliente coa súa propia opción de DNS cifrado pode saltar a directiva que acaba de verificar, así que revise ese axuste como parte da revisión. Despois reconecte ambos clientes na orde que admite o provedor e repita as consultas; se as respostas se intercambian cando cambia a orde, un escritor competidor segue sendo dono de parte da configuración. Avereigüe que compoñente instala a regra - o cliente, o perfil do sistema operativo ou un axente de xestión - antes de editar nada. Anote a orde e os propietarios para que a seguinte persoa non teña que redescubrilos.