Ко заправо примењује OpenConnect DNS поставке на 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 путу.