Dialoglodziņš ziņo, ka servera nosaukumu neizdevās atrisināt, un profila lauks, kurā skatāties, ir adrese. Šī kombinācija nav pretruna: klients atrisina kaut ko citu, nevis vērtību, kuru, jūsuprāt, tas nolasa. Noskaidrojiet, uz ko tas faktiski zvana, pirms secināt, ka DNS ir salauzts. Klienta paša soļu secība parāda, kur meklēt.

Klients atrisina nosaukumu pirms zvana

Vietējais Windows VPN savienojums nolasa savu profilu, atrisina servera adresi, palaiž tuneli un tikai pēc tam autentificē. Kļūda 868 pieder otrajam solim. Tā kā vēlākie soļi nekad netiek izpildīti, dialoglodziņš var izskatīties kā akreditācijas datu problēma, kad meklēšana neizdevās pirmā.

Šī secība ir noderīga, jo sašaurina pārbaudāmo slāni. Kad viens un tas pats profils darbojas no viena tīkla un neizdodas no cita, atšķirība parasti ir nosaukumu atrisināšanā, nevis tuneļa tipā vai kontā. Pārbaudiet meklēšanu tur, kur rodas kļūda, nevis tur, kur profils tika izveidots.

Kurš nosaukums, kad lauks rāda adresi

Lasiet saglabāto vērtību, nevis parādīto nosaukumu. Savienojuma etiķete nav tā servera adrese, un divi ieraksti ar līdzīgām etiķetēm sūta jūs pakaļ nepareizajam:

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

Ja profils ir sagatavots visiem lietotājiem, vaicājiet arī šo tvērumu ar -AllUserConnection. Pēc tam atrisiniet tieši to vērtību, ko izdrukāja komanda, no tīkla, kurā rodas kļūda. Izmantojiet operatora dokumentēto vārteju, nevis lietojumprogrammas iekšējo nosaukumu, kas tiek atrisināts tikai pēc tuneļa pacelšanas. Otrais vaicājums neizdodas sagaidāma iemesla dēļ un neko nepasaka par zvanu:

Resolve-DnsName vpn.example.com

Kad saglabātā vērtība patiešām ir skaitliska, meklējiet otru vietu, kur klients nolasa nosaukumu. EAP konfigurācija var norādīt serveri, no cita rīka importēts profils var nest savu vērtību, un agrāks instalators var atstāt dublētu ierakstu. Dialoglodziņa lauks ne vienmēr ir vienīgā ievade.

Windows 7 atkārtotas savienošanas modelis

Šīs kļūdas pavediens apraksta datorus, kas vienreiz savienojās un pēc tam vēlākā mēģinājumā neizdevās ar 868, profilā nekam nemainoties. Dalībnieki ziņoja, ka pakalpojuma Remote Access Connection Manager restartēšana vai izrakstīšanās un atkārtota pierakstīšanās īslaicīgi atjaunoja savienojumu. Tie ir apiešanas paņēmieni, nevis pierādīts pamatcēlonis.

Uztveriet šo modeli kā atsevišķu hipotēzi. Restartēšana atiestata klienta stāvokli, tāpēc vēlāki īslaicīgi panākumi nepierāda, ka DNS ieraksts bija nepareizs:

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

Lasiet tabulu kā atšķirošu novērojumu kopumu, nevis diagnozi. Pirmā rinda ir nosaukuma problēma, otrā ir klienta stāvoklis, bet trešā ir profils, kas nekad nav bijis pareizs. Katra ved pie cita cilvēka un cita labojuma.

Kas jāsavāc administratoram

Pierakstiet profila nosaukumu, saglabāto adresi, tuneļa tipu, tīklu, kurā atradās klients, un vai kļūda sekoja pēc atvienošanas. Šis ieraksts atšķir īstu meklēšanas kļūdu no vēsturiskās atkārtotas savienošanas uzvedības, nevienam nav jāmin. Saglabājiet arī klienta notikumu žurnālu ap mēģinājumu.

Apiešanas risinājums no vecākām versijām ir pierādījums, ka uzvedība pastāvēja, nevis solījums, ka tas pats pakalpojuma restarts salabos pašreizējo datoru. Dokumentēta resursdatora nosaukuma aizstāšana ar burtisku adresi arī nav labojums.

Daži profili gaida servera identitāti, kas atbilst konfigurētajam nosaukumam, tāpēc skaitlisks apiešanas risinājums var apmainīt vienu kļūdu pret citu. Ja nosaukumam jāpaliek, labojiet atrisināšanas ceļu, nevis profila tekstu. Jebkurā gadījumā pierakstiet, ko un kāpēc mainījāt.

Saistītie raksti