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

Кліент развязвае імя перад тым, як падключыцца

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

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

Якое імя, калі поле паказвае адрас

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

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

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

Resolve-DnsName vpn.example.com

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

Схема перападключэння Windows 7

Тэма, што стаіць за гэтай памылкай, апісвае машыны, якія аднойчы падключыліся, а потым пацярпелі збой з 868 пры пазнейшай спробе, хоць у профілі нічога не змянілася. Удзельнікі паведамлялі, што перазапуск службы Remote Access Connection Manager або выхад і зноў уваход у сістэму часова аднаўлялі злучэнне. Гэта абыходныя шляхі, а не даказаная першапрычына.

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

ObservationPoints towardWhat to do next
Fails from one network, works from anotherName resolution on that pathResolve the stored name from both networks
Fails after a disconnect, works after service restartClient state, not DNSRecord the sequence for the vendor
Fails only on a newly provisioned machineProfile content or scopeCompare ServerAddress and TunnelType

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

Што сабраць для адміністратара

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

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

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

Падобныя артыкулы