Хто насамрэч прымяняе налады 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

Сервер на ўзроўні адаптара — гэта тое, што большасць людзей маюць на ўвазе пад DNS для VPN. Суфікс, спецыфічны для злучэння, вырашае, ці будзе кароткае імя пашырана наогул. Спіс палітыкі прасторы імёнаў прымяняецца да адпаведных імёнаў незалежна ад парадку адаптараў, і пусты вынік там не з’яўляецца дэфектам, калі памочнік ніколі не меў намеру стварыць яго. Чытанне ўсіх трох перад рэдагаваннем — гэта тое, што прадухіляе выпраўленне, якое проста пераносіць сімптом у іншае месца.

Пачніце з поўнага імя. Калі FQDN вызначаецца, а кароткае імя не, то разрыў — гэта суфікс або спіс пошуку, а не адрас сервера.

Запытайцеся ў меркаванага сервера напрамую як на другім кроку, выкарыстоўваючы любы ўжо ўсталяваны інструмент рэзалвера. Прамы адказ даказвае, што сервер даступны і аўтарытэтны для зоны. Ён нічога не даказвае пра тое, у якога сервера праграма запытвае па змаўчанні.

Назвіце кампанент, які валодае злучэннем

Распаўсюджаныя два варыянты. Кліент, запушчаны з тэрмінала, перадае шлях да свайго сцэнарыя яўна, таму ўладальнік бачны ў камандзе, якая выконвалася. Спакаваная праграма запускае кліент за вас і трымае памочнік у сваёй дырэкторыі, гэта значыць пастаўшчык вырашае, калі ён зменіцца.

Параўнайце версіі памочніка паміж усталёўкамі, перш чым нешта замяняць. Запуск памочніка, спампаванага з люстэрка, з павышанымі правамі толькі таму, што імя файла выглядае знаёмым, ператварае разрыў DNS у інцыдэнт бяспекі.

Калі ўладальнік вядомы, мэта рамонту становіцца відавочнай: падтрымліваемы шлях да сцэнарыя ў пускавым прыладзе, абнаўленне пакета або выпраўлены профіль на шлюзе. Нішто з гэтага не патрабуе ручнога рэдагавання ўласцівасцяў адаптара.

Выпраўляйце ўладальніка, а не адаптар

DNS, усталяваны ўручную на адаптары, часта выжывае пасля адключэння, таму здаецца, што ён працуе, а затым стварае праблемы ў наступнай сетцы. Публічны рэзалвер, прымацаваны да кожнага інтэрфейса, хавае праблему прыватнай прасторы імёнаў замест таго, каб вырашыць яе. Калі памочнік так і не атрымаў значэнне DNS, шукаць трэба ў профілі шлюза. Калі ён атрымаў яго, а адаптар усё яшчэ паказвае стары сервер, памочнік не справіўся падчас падключэння, і журнал кліента звычайна фіксуе гэта побач з радкамі наладкі тунеля.

Перабудуйце стан праз падтрымліваемы шлях, затым праверце поўны цыкл: падключыцеся, вызначце прыватны FQDN, адкрыйце сэрвіс, адключыцеся і пераканайцеся, што адаптар вярнуўся з папярэднімі серверамі.

Праверце праграму, якая насамрэч збіваецца

Браўзер з уласнай наладай зашыфраванага DNS ігнаруе ўсё вышэйшае і працягвае адказваць з публічнага рэзалвера. Праграма, якая трымае кэшаваны адмоўны адказ з часоў да падняцця тунеля, паводзіць сябе гэтак жа. Параўнайце яе са звычайным сістэмным запытам на той жа машыне, перш чым зноў змяняць адрасы рэзалвера.

Калі сістэмны запыт правільны, а праграма памылковая, пакінуты дэфект знаходзіцца ўнутры канфігурацыі DNS гэтай праграмы, а не ў шляху VPN.