Quen aplica realmente a configuración DNS de OpenConnect en Windows?

Levantar o túnel non é o mesmo que instalar os seus valores DNS. OpenConnect negocia e un axudante do lado de Windows aplica. A fenda entre eses dous pasos explica a maioría dos fallos de nomes privados neste cliente, e o axudante case nunca é a páxina de configuración da VPN de Windows.

Separe o que ofreceu a pasarela do que Windows instalou

O cliente entrega os datos da conexión a unha interface de script, e as variantes de Unix e Windows son programas separados. En Windows a implementación adoita ser un axudante JavaScript que le variables como o servidor DNS interno e o dominio interno antes de tocar calquera adaptador. Nada dentro do túnel escribe o estado do resolvedor.

Esa división importa porque un valor pode existir na negociación e nunca chegar ao adaptador. Un axudante que falta, falla a medio camiño ou é unha copia antiga incluída nun envoltorio GUI deixa Windows exactamente como estaba. A sesión parece conectada, o nome privado aínda se resolve polo provedor local e nada na ventá do cliente indica a diferenza. Ler a saída propia do axudante é a única forma fiable de saber que etapa se rompeu.

Un envoltorio GUI pode traer a súa propia copia do cliente e do axudante, así que un segundo openconnect.exe noutro lugar do disco non demostra nada. Atope o executable que iniciou a sesión antes de xulgar a súa configuración.

Lea o estado do resolvedor sen cambialo

Tres consultas de só lectura cobren a confusión habitual, e cada unha responde unha pregunta distinta:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Un servidor a nivel de adaptador é o que a maioría da xente entende por DNS de VPN. Un sufixo específico de conexión decide se un nome curto se expande sequera. A lista de políticas de espazo de nomes aplícase aos nomes coincidentes independentemente da orde dos adaptadores, e un resultado baleiro alí non é un defecto cando o axudante nunca pretendeu crear un. Ler os tres antes de editar é o que evita unha reparación que só move o síntoma a outro lugar.

Comece polo nome totalmente cualificado. Se o FQDN se resolve e o nome curto non, a fenda é o sufixo ou a lista de busca, non o enderezo do servidor.

Consulte o servidor previsto directamente como segundo paso, con calquera ferramenta de resolvedor xa instalada. Unha resposta directa demostra que o servidor é accesible e autoritativo para a zona. Non demostra nada sobre a que servidor pregunta unha aplicación por defecto.

Nomee o compoñente que posúe a conexión

Dúas disposicións son habituais. Un cliente iniciado desde un terminal pasa a ruta do seu script explicitamente, así que o propietario é visible na orde que se executou. Unha aplicación empaquetada inicia o cliente por vostede e garda o axudante dentro do seu propio directorio, o que significa que o provedor decide cando cambia.

Compare as versións do axudante entre instalacións antes de cambiar nada. Executar con dereitos elevados un axudante baixado dun espello porque o nome do ficheiro parece familiar converte unha fenda de DNS nun incidente de seguridade.

Unha vez coñecido o propietario, o obxectivo da reparación é obvio: unha ruta de script compatible no iniciador, unha actualización do paquete ou un perfil corrixido na pasarela. Ningún deles require editar a man as propiedades do adaptador.

Repare o propietario, non o adaptador

O DNS posto a man no adaptador a miúdo sobrevive á desconexión, e por iso parece funcionar e despois causa problemas na seguinte rede. Un resolvedor público atafegado a cada interface oculta o problema do espazo de nomes privado en lugar de resolvelo. Cando o axudante nunca recibiu un valor DNS, o perfil da pasarela é o lugar onde mirar. Cando recibiu un e o adaptador aínda mostra o servidor antigo, o axudante fallou durante a conexión e o rexistro do cliente adoita anotalo preto das liñas de configuración do túnel.

Reconstruír o estado pola vía compatible e despois verificar un ciclo completo: conéctese, resolva o FQDN privado, abra o servizo, desconéctese e confirme que o adaptador volveu cos servidores anteriores.

Comprobe a aplicación que realmente falla

Un navegador coa súa propia configuración de DNS cifrado ignora todo o anterior e segue respondendo desde un resolvedor público. Unha aplicación que garda unha resposta negativa en caché de antes de que subise o túnel compórtase igual. Compárea cunha consulta de sistema simple na mesma máquina antes de volver cambiar os enderezos do resolvedor.

Se a consulta do sistema é correcta e a aplicación non, o fallo restante está dentro da configuración DNS desa aplicación, non na ruta da VPN.