Cine aplică de fapt setările DNS OpenConnect pe Windows?

Ridicarea tunelului nu este același lucru cu instalarea valorilor sale DNS. OpenConnect negociază, iar un helper din partea Windows aplică. Diferența dintre acești doi pași explică majoritatea eșecurilor numelor private pe acest client, iar helperul aproape niciodată nu este pagina de setări VPN din Windows.

Separați ce a oferit gateway-ul de ce a instalat Windows

Clientul predă datele conexiunii unei interfețe de script, iar variantele Unix și Windows sunt programe separate. Pe Windows implementarea este de obicei un helper JavaScript care citește variabile precum serverul DNS intern și domeniul intern înainte de a atinge vreun adaptor. Nimic din tunelul însuși nu scrie starea resolver-ului.

Această separare contează pentru că o valoare poate exista în negociere și nu ajunge niciodată la adaptor. Un helper lipsă, care eșuează la jumătatea drumului sau este o copie mai veche inclusă într-un înveliș GUI lasă Windows exact așa cum era. Sesiunea pare conectată, numele privat se rezolvă în continuare prin furnizorul local și nimic din fereastra clientului nu sugerează diferența. Citirea propriei ieșiri a helperului este singura modalitate fiabilă de a afla care etapă s-a rupt.

Un înveliș GUI poate livra propria copie a clientului și a helperului, așa că un al doilea openconnect.exe în altă parte pe disc nu dovedește nimic. Găsiți executabilul care a pornit sesiunea înainte de a-i judeca configurația.

Citiți starea resolver-ului fără a o modifica

Trei interogări doar pentru citire acoperă confuzia obișnuită, iar fiecare răspunde la o întrebare diferită:

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

Un server la nivel de adaptor este ceea ce majoritatea oamenilor înțeleg prin DNS VPN. Un sufix specific conexiunii decide dacă un nume scurt este extins. Lista de politici pentru spațiul de nume se aplică numelor potrivite indiferent de ordinea adaptoarelor, iar un rezultat gol acolo nu este un defect când helperul nu a intenționat niciodată să creeze unul. Citirea tuturor trei înainte de editare este ceea ce împiedică o reparație care doar mută simptomul în altă parte.

Începeți cu numele complet calificat. Dacă FQDN-ul se rezolvă și numele scurt nu, lacuna este sufixul sau lista de căutare, nu adresa serverului.

Întrebați direct serverul dorit ca al doilea pas, cu orice instrument de resolver deja instalat. Un răspuns direct dovedește că serverul este accesibil și autoritativ pentru zonă. Nu dovedește nimic despre ce server întreabă o aplicație în mod implicit.

Numiți componenta care deține conexiunea

Două aranjamente sunt obișnuite. Un client pornit dintr-un terminal transmite explicit calea scriptului său, așa că proprietarul este vizibil în comanda executată. O aplicație împachetată pornește clientul pentru dumneavoastră și ține helperul în propriul director, ceea ce înseamnă că furnizorul decide când se schimbă.

Comparați versiunile helperului între instalări înainte de a schimba ceva. Rularea cu privilegii ridicate a unui helper adus dintr-o oglindă pentru că numele fișierului pare familiar transformă o lacună DNS într-un incident de securitate.

Odată ce proprietarul este cunoscut, ținta reparației devine evidentă: o cale de script acceptată în lansator, o actualizare de pachet sau un profil corectat pe gateway. Niciuna dintre acestea nu necesită editarea manuală a proprietăților adaptorului.

Reparați proprietarul, nu adaptorul

DNS-ul setat manual pe adaptor supraviețuiește adesea deconectării, motiv pentru care pare să funcționeze și apoi creează probleme în rețeaua următoare. Un resolver public fixat pe fiecare interfață ascunde problema spațiului de nume privat în loc să o rezolve. Când helperul nu a primit niciodată o valoare DNS, profilul gateway-ului este locul de căutat. Când a primit una și adaptorul arată încă serverul vechi, helperul a eșuat la conectare, iar jurnalul clientului înregistrează de obicei asta lângă liniile de configurare a tunelului.

Reconstruiți starea prin calea acceptată, apoi verificați un ciclu complet: conectați-vă, rezolvați FQDN-ul privat, deschideți serviciul, deconectați-vă și confirmați că adaptorul a revenit cu serverele anterioare.

Verificați aplicația care eșuează de fapt

Un browser cu propria setare de DNS criptat ignoră tot ce este mai sus și continuă să răspundă de la un resolver public. O aplicație care păstrează un răspuns negativ din cache de dinainte de ridicarea tunelului se comportă la fel. Comparați-o cu o interogare simplă de sistem pe aceeași mașină înainte de a schimba din nou adresele resolver-ului.

Dacă interogarea de sistem este corectă și aplicația nu, defectul rămas se află în configurația DNS a acelei aplicații, nu în calea VPN.