Грешка 868 са IP адресом? Шта Windows прво решава
Дијалог пријављује неуспех претраге док профил изгледа бројчано. Прочитајте стварно поље профила, затим одвојте проблем са именом од старе грешке поновног повезивања.
Дијалог саопштава да име сервера није могло бити разрешено, а поље профила у које гледате је адреса. Та комбинација није противречност: клијент разрешава нешто друго од вредности за коју мислите да је чита. Утврдите на шта се заправо повезује пре него што закључите да је DNS покварен. Редослед сопствених корака клијента показује вам где да тражите.
Клијент разрешава име пре него што се повеже
Уграђена Windows VPN веза чита свој профил, разрешава адресу сервера, покреће тунел и тек онда проверава идентитет. Грешка 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 запис био погрешан:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
Табелу читајте као скуп разликујућих запажања, а не као дијагнозу. Први ред је проблем са именом, други је стање клијента, а трећи је профил који никада није био исправан. Сваки води до друге особе и друге исправке.
Шта прикупити за администратора
Запишите назив профила, сачувану адресу, тип тунела, мрежу на којој је клијент био и да ли је грешка уследила после прекида везе. Тај запис одваја стварни неуспех претраге од историјског понашања при поновном повезивању без потребе да било ко нагађа. Сачувајте и дневник догађаја клијента око покушаја.
Заобилазно решење из старијих верзија доказ је да је понашање постојало, а не обећање да ће исти рестарт услуге поправити савремену машину. Замена документованог имена домаћина буквалном адресом такође није поправка.
Неки профили очекују идентитет сервера који одговара конфигурисаном имену, па бројчано заобилазно решење може заменити једну грешку другом. Ако име мора да остане, поправите пут разрешавања, а не текст профила. У сваком случају запишите шта сте променили и зашто.