Кој всушност ги применува DNS-поставките на OpenConnect во Windows?

Подигнувањето на тунелот не е исто што и инсталирање на неговите DNS-вредности. OpenConnect преговара, а помагач од страната на Windows применува. Јазот меѓу овие два чекори го објаснува повеќето неуспеси со приватни имиња кај овој клиент, а помагачот речиси никогаш не е страницата со поставки за VPN во Windows.

Одвојте го она што го понуди порталот од она што го инсталираше Windows

Клиентот ги предава податоците за врската на скрипт-интерфејс, а варијантите за Unix и Windows се одделни програми. Во Windows, имплементацијата обично е JavaScript-помагач што чита променливи како внатрешниот DNS-сервер и внатрешниот домен пред да допре било кој адаптер. Ништо во самиот тунел не запишува состојба на разрешувачот.

Оваа поделба е важна зашто вредноста може да постои во преговорот и никогаш да не стигне до адаптерот. Помагач што недостасува, паѓа на половина пат или е постара копија вградена во GUI-обвивка ги остава Windows точно какви што биле. Сесијата изгледа поврзана, приватното име сѐ уште се разрешува преку локалниот давател, и ништо во прозорецот на клиентот не укажува на разликата. Читањето на сопствениот излез на помагачот е единствениот сигурен начин да се дознае која етапа се скршила.

GUI-обвивката може да достави сопствена копија на клиентот и помагачот, така што втор openconnect.exe на друго место на дискот не докажува ништо. Најдете ја извршната датотека што ја започнала сесијата пред да ја оцените нејзината конфигурација.

Прочитајте ја состојбата на разрешувачот без да ја менувате

Три прашања само за читање ја покриваат вообичаената збунетост, и секое одговара на различно прашање:

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

Сервер на ниво на адаптер е она што повеќето луѓе го подразбираат под VPN DNS. Наставката специфична за врската одлучува дали краткото име воопшто ќе се прошири. Списокот со правила за именски простор се применува на соодветните имиња без оглед на редоследот на адаптерите, и празен резултат таму не е дефект кога помагачот никогаш немал намера да создаде еден. Читањето на сите три пред уредување е она што спречува поправка што само го преместува симптомот на друго место.

Започнете со целосно квалификуваното име. Ако FQDN се разрешува, а краткото име не, јазот е наставката или списокот за пребарување, а не адресата на серверот.

Како втор чекор прашајте го предвидениот сервер директно, со кој било веќе инсталиран алат за разрешување. Директниот одговор докажува дека серверот е достапен и надлежен за зоната. Тој не докажува ништо за тоа кој сервер го прашува апликацијата по стандард.

Именувајте ја компонентата што го поседува поврзувањето

Вообичаени се два распореди. Клиент започнат од терминал го пренесува патот до својата скрипта експлицитно, така што сопственикот е видлив во извршената команда. Пакувана апликација го започнува клиентот наместо вас и го држи помагачот во сопствениот директориум, што значи дека добавувачот одлучува кога ќе се промени.

Споредете ги верзиите на помагачот меѓу инсталациите пред да смените нешто. Извршување на помагач преземен од огледало со зголемени права само затоа што името на датотеката изгледа познато, претвора DNS-јаз во безбедносен инцидент.

Откако сопственикот е познат, целта на поправката станува очигледна: поддржан пат до скриптата во стартувачот, ажурирање на пакетот или поправен профил на порталот. Ниту едно од овие не бара рачно уредување на својствата на адаптерот.

Поправете го сопственикот, а не адаптерот

Рачно поставениот DNS на адаптерот често го преживува прекинот, затоа изгледа дека работи, а потоа создава проблеми во следната мрежа. Јавен разрешувач завртен на секој интерфејс ја крие проблема со приватниот именски простор наместо да ја реши. Кога помагачот никогаш немал добиено DNS-вредност, профилот на порталот е местото каде треба да се погледне. Кога ја добил, а адаптерот сѐ уште го покажува стариот сервер, помагачот не успеал при поврзувањето и дневникот на клиентот тоа обично го запишува близу редовите за поставување на тунелот.

Обновете ја состојбата преку поддржаниот пат, потоа проверете го целиот циклус: поврзете се, разрешете го приватниот FQDN, отворете ја услугата, исклучете се и потврдете дека адаптерот се вратил со претходните сервери.

Проверете ја апликацијата што навистина не успева

Прелистувач со сопствена поставка за шифриран DNS ги игнорира сите горенаведени работи и продолжува да одговара од јавен разрешувач. Апликација што држи кеширан негативен одговор од пред подигнувањето на тунелот се однесува исто. Споредете ја со едноставно системско прашање на истиот компјутер пред повторно да ги смените адресите на разрешувачот.

Ако системското прашање е точно, а апликацијата погрешна, преостанатиот дефект е во DNS-конфигурацијата на таа апликација, а не во патот на VPN.