Dos VPN, un solo resolver: gana quien escribió al final

Hay dos clientes VPN conectados, uno para el trabajo y otro para una red de laboratorio, y los nombres internos solo se resuelven para el cliente que se conectó al final. Ese patrón parece un error en uno de los clientes. Normalmente es el resultado previsible de dos programas que escriben la misma configuración de resolutor sin ponerse de acuerdo sobre quién es dueño de cada nombre.

El mito: el VPN más nuevo es dueño del DNS

No existe una regla general de que gane la conexión más reciente. Lo que ocurre depende del mecanismo de la plataforma y de cómo lo escriba cada cliente. Un cliente que reemplaza un archivo de resolutor produce un resultado; un cliente que añade un dominio por enlace produce otro; un cliente que no hace nada deja intacto el estado anterior.

Así que el comportamiento observado es una propiedad de las dos implementaciones, no una prioridad documentada. Razonar sobre él solo a partir del orden de inicio acertará a veces y fallará de formas difíciles de reproducir. Escriba la correspondencia. Un diseño que vive en dos clientes no es un diseño.

Asigne espacios de nombres a resolutores

Enumere los sufijos privados y el resolutor que exige cada red, y luego decida adónde deben ir los nombres públicos. Esa lista es el diseño. Sin ella, los clientes toman la decisión por accidente.

Una plataforma que admite DNS por enlace o dominios de enrutamiento puede expresar la división deliberadamente: un dominio va a un enlace, otro dominio al otro, y todo lo demás sigue un valor predeterminado explícito. Dos scripts planos que sobrescriben el mismo archivo no pueden preservar ese diseño, porque cada uno cree que es dueño de toda la configuración.

En Windows, la tabla de directivas de resolución de nombres puede dirigir sufijos a servidores concretos, y un cliente VPN puede instalar reglas allí. Revise la directiva en lugar de la lista de adaptadores, porque la lista de adaptadores no es lo que resuelve el nombre.

Mantenga una ruta de arranque

Cada cliente debe localizar su propio punto final antes de poder usar el servicio que ese punto final ofrece. Si el nombre de host del punto final solo puede resolverse a través del túnel, y el túnel necesita el nombre de host resuelto, tiene una dependencia circular que aparece como un tiempo de espera de conexión. Mantenga una ruta de arranque fuera de ambos túneles. No cuesta nada hasta el día en que salva la conexión.

Mire la ruta hacia cada resolutor, no solo el nombre configurado para él. Un resolutor al que solo se llega a través del otro túnel se comporta como uno ausente, y el síntoma es un tiempo de espera en lugar de un error de enrutamiento.

Las direcciones superpuestas no son un problema de DNS

Dos redes privadas que usan el mismo rango de direcciones no se arreglan con el orden del DNS. Si ambos túneles reclaman 10.0.0.0/8, un nombre que se resuelve correctamente sigue apuntando a una dirección a la que el host no puede enrutar hacia el túnel correcto. Eso necesita una solución a nivel de dirección, como rangos distintos, un espacio de nombres o traducción, no otro ajuste de resolutor. Decidirlo pronto evita un largo desvío por una configuración de DNS que nunca habría funcionado.

Compare las asignaciones de direcciones de ambos túneles antes de culpar a la resolución de nombres. Cuando ambos extremos empujan el mismo prefijo, el host conserva una sola ruta para él, y un nombre resuelto a través del segundo túnel sigue aterrizando en una dirección que posee el primer túnel. Rangos distintos, un espacio de nombres por red o traducción son las correcciones; tras conectar cada cliente, confirme que la tabla de rutas muestra el camino que pretendía.

Demuéstrelo con aplicaciones reales

Elija dos hosts que solo existan dentro de su propio espacio de nombres y un nombre público, y luego resuelva cada uno a través del cliente que debería poseerlo. Una respuesta correcta del resolutor esperado no demuestra que la aplicación llegue al host, porque la ruta a esa dirección aún puede fallar. Acompañe cada consulta con una prueba de conexión desde el programa que el usuario ejecutará de verdad.

Un cliente con su propia opción de DNS cifrado puede saltarse la directiva que acaba de verificar, así que revise ese ajuste como parte de la revisión. Después reconecte ambos clientes en el orden que admite el proveedor y repita las consultas; si las respuestas se intercambian cuando cambia el orden, un escritor competidor sigue siendo dueño de parte de la configuración. Averigüe qué componente instala la regla - el cliente, el perfil del sistema operativo o un agente de gestión - antes de editar nada. Anote el orden y los propietarios para que la siguiente persona no tenga que redescubrirlos.