¿Quién aplica realmente la configuración DNS de OpenConnect en Windows?
Windows guarda el estado del resolutor en tres sitios. Encuentre el asistente que posee la conexión antes de editar a mano el DNS del adaptador o añadir una regla de espacio de nombres.
Levantar el túnel no es lo mismo que instalar sus valores DNS. OpenConnect negocia y un asistente del lado de Windows aplica. La brecha entre esos dos pasos explica la mayoría de los fallos de nombres privados en este cliente, y el asistente casi nunca es la página de configuración de VPN de Windows.
Separe lo que ofreció la puerta de enlace de lo que Windows instaló
El cliente entrega los datos de conexión a una interfaz de script, y las variantes de Unix y Windows son programas separados. En Windows la implementación suele ser un asistente JavaScript que lee variables como el servidor DNS interno y el dominio interno antes de tocar cualquier adaptador. Nada dentro del túnel escribe el estado del resolutor.
Esa división importa porque un valor puede existir en la negociación y no llegar nunca al adaptador. Un asistente que falta, falla a mitad de camino o es una copia antigua incluida dentro de un envoltorio GUI deja Windows exactamente como estaba. La sesión parece conectada, el nombre privado sigue resolviéndose por el proveedor local y nada en la ventana del cliente indica la diferencia. Leer la salida propia del asistente es la única forma fiable de saber qué etapa se rompió.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
Un envoltorio GUI puede traer su propia copia del cliente y del asistente, así que un segundo openconnect.exe en otro lugar del disco no demuestra nada. Encuentre el ejecutable que inició la sesión antes de juzgar su configuración.
Lea el estado del resolutor sin cambiarlo
Tres consultas de solo lectura cubren la confusión habitual, y cada una responde a una pregunta distinta:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -EffectiveUn servidor a nivel de adaptador es lo que la mayoría de la gente entiende por DNS de VPN. Un sufijo específico de conexión decide si un nombre corto se expande siquiera. La lista de políticas de espacio de nombres se aplica a los nombres coincidentes independientemente del orden de los adaptadores, y un resultado vacío allí no es un fallo cuando el asistente nunca pretendió crear uno. Leer los tres antes de editar es lo que evita una reparación que solo mueve el síntoma a otro lugar.
Empiece por el nombre totalmente cualificado. Si el FQDN se resuelve y el nombre corto no, la brecha es el sufijo o la lista de búsqueda, no la dirección del servidor.
Consulte el servidor previsto directamente como segundo paso, con cualquier herramienta de resolutor que ya esté instalada. Una respuesta directa demuestra que el servidor es accesible y autoritativo para la zona. No demuestra nada sobre a qué servidor pregunta una aplicación por defecto.
Nombre el componente que posee la conexión
Dos disposiciones son habituales. Un cliente iniciado desde un terminal pasa la ruta de su script de forma explícita, así que el propietario es visible en el comando que se ejecutó. Una aplicación empaquetada inicia el cliente por usted y guarda el asistente dentro de su propio directorio, lo que significa que el proveedor decide cuándo cambia.
Compare las versiones del asistente entre instalaciones antes de cambiar nada. Ejecutar con derechos elevados un asistente descargado de un espejo porque el nombre del archivo resulta familiar convierte una brecha de DNS en un incidente de seguridad.
Una vez conocido el propietario, el objetivo de la reparación es obvio: una ruta de script compatible en el lanzador, una actualización del paquete o un perfil corregido en la puerta de enlace. Ninguno de ellos requiere editar a mano las propiedades del adaptador.
Repare el propietario, no el adaptador
El DNS puesto a mano en el adaptador a menudo sobrevive a la desconexión, por eso parece funcionar y luego causa problemas en la siguiente red. Un resolutor público atornillado a cada interfaz oculta el problema del espacio de nombres privado en lugar de resolverlo. Cuando el asistente nunca recibió un valor DNS, el perfil de la puerta de enlace es el lugar donde mirar. Cuando recibió uno y el adaptador sigue mostrando el servidor antiguo, el asistente falló durante la conexión y el registro del cliente suele anotarlo cerca de las líneas de configuración del túnel.
Reconstruya el estado por la vía compatible y luego verifique un ciclo completo: conéctese, resuelva el FQDN privado, abra el servicio, desconéctese y confirme que el adaptador volvió con sus servidores anteriores.
Compruebe la aplicación que realmente falla
Un navegador con su propia configuración de DNS cifrado ignora todo lo anterior y sigue respondiendo desde un resolutor público. Una aplicación que guarda una respuesta negativa en caché de antes de que subiera el túnel se comporta igual. Compárela con una consulta de sistema simple en la misma máquina antes de volver a cambiar las direcciones del resolutor.
Si la consulta del sistema es correcta y la aplicación no, el fallo restante está dentro de la configuración DNS de esa aplicación, no en la ruta de la VPN.