Кой всъщност прилага DNS настройките на OpenConnect в Windows?
Windows пази състоянието на резолвера на три места. Намерете помощника, който притежава връзката, преди да редактирате ръчно DNS на адаптера или да добавите правило за пространство от имена.
Вдигането на тунела не е същото като инсталирането на неговите DNS стойности. OpenConnect преговаря, а помощник от страна на Windows прилага. Разликата между тези две стъпки обяснява повечето откази на частни имена при този клиент и помощникът почти никога не е страницата с настройки на VPN в Windows.
Отделете какво е предложил шлюзът от това, което Windows е инсталирал
Клиентът предава данните за връзката на скриптов интерфейс, а вариантите за Unix и Windows са отделни програми. В Windows реализацията обикновено е JavaScript помощник, който чете променливи като вътрешния DNS сървър и вътрешния домейн, преди да докосне който и да е адаптер. Нищо в самия тунел не записва състояние на резолвера.
Това разделение е важно, защото дадена стойност може да съществува в преговорите и никога да не стигне до адаптера. Помощник, който липсва, се проваля по средата или е по-стар екземпляр, вграден в GUI обвивка, оставя Windows точно както си е бил. Сесията изглежда свързана, частното име все още се разрешава през местния доставчик и нищо в прозореца на клиента не подсказва разликата. Четенето на собствения изход на помощника е единственият надежден начин да разберете кой етап се е счупил.
| 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 |
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.