Gabim 868 me një adresë IP? Çfarë zgjidh Windows së pari

Dialogu thotë se emri i serverit nuk mund të zgjidhej, dhe fusha e profilit ku po shikoni është një adresë. Ky kombinim nuk është kundërshtim: klienti po zgjidh diçka tjetër nga vlera që mendoni se lexon. Zbuloni se çfarë telefonon në të vërtetë përpara se të konkludoni se DNS është prishur. Rendi i hapave të vetë klientit ju tregon ku të shikoni.

Klienti zgjidh një emër përpara se të telefonojë

Një lidhje VPN e brendshme e Windows lexon profilin e saj, zgjidh adresën e serverit, nis tunelin dhe vetëm më pas vërteton identitetin. Gabimi 868 i përket hapit të dytë. Meqenëse hapat e mëvonshëm nuk ekzekutohen kurrë, dialogu mund të duket si problem kredencialesh kur kërkimi dështoi i pari.

Ky rend është i dobishëm sepse ngushton shtresën për t’u inspektuar. Kur i njëjti profil funksionon nga një rrjet dhe dështon nga një tjetër, ndryshimi është zakonisht zgjidhja e emrave dhe jo lloji i tunelit ose llogaria. Testoni kërkimin atje ku ndodh dështimi, jo atje ku u krijua profili.

Cili emër, kur fusha tregon një adresë

Lexoni vlerën e ruajtur në vend të emrit të shfaqur. Etiketa e një lidhjeje nuk është adresa e serverit të saj, dhe dy zëra me etiketa të ngjashme ju dërgojnë pas atij të gabuar:

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

Nëse profili është përgatitur për të gjithë përdoruesit, pyesni edhe atë shtrirje me -AllUserConnection. Më pas zgjidhni saktësisht vlerën që printoi komanda, nga rrjeti ku ndodh dështimi. Përdorni portën e dokumentuar të operatorit, jo emrin e brendshëm të aplikacionit që zgjidhet vetëm pasi tuneli të jetë ngritur. Ajo pyetje e dytë dështon për një arsye të pritur dhe nuk ju thotë asgjë për thirrjen:

Resolve-DnsName vpn.example.com

Kur vlera e ruajtur është vërtet numerike, kërkoni një vend të dytë ku klienti lexon një emër. Një konfigurim EAP mund të referojë një server, një profil i importuar nga një mjet tjetër mund të mbajë vlerën e vet, dhe një instalues i mëparshëm mund të lërë një zë të dyfishuar. Fusha në dialog nuk është gjithmonë e vetmja hyrje.

Modeli i rilidhjes në Windows 7

Fija pas këtij gabimi përshkruan makina që u lidhën një herë dhe më pas dështuan në një përpjekje të mëvonshme me 868, pa ndryshuar asgjë në profil. Kontribuesit raportuan se rinisja e shërbimit Remote Access Connection Manager ose dalja dhe rihyrja rikthente përkohësisht lidhjen. Këto janë zgjidhje anësore, jo një shkak rrënjësor i provuar.

Trajtojeni atë model si një hipotezë të veçantë. Rinisja rivendos gjendjen e klientit, kështu që një sukses i përkohshëm më pas nuk provon se regjistri DNS ishte i gabuar:

Lexoni tabelën si një grup vëzhgimesh dalluese, jo si diagnozë. Rreshti i parë është problem emri, i dyti gjendja e klientit, dhe i treti një profil që nuk ishte kurrë i saktë. Secili të çon te një person tjetër dhe një rregullim tjetër.

Çfarë të mblidhni për administratorin

Shkruani emrin e profilit, adresën e ruajtur, llojin e tunelit, rrjetin në të cilin ishte klienti, dhe nëse dështimi pasoi një shkëputje. Ai regjistrim ndan një dështim të vërtetë kërkimi nga sjellja historike e rilidhjes pa kërkuar që dikush të hamendësojë. Ruani gjithashtu regjistrin e ngjarjeve të klientit rreth përpjekjes.

Zgjidhja anësore nga ndërtimet e vjetra është provë se sjellja ekzistonte, jo një premtim se e njëjta rinisje e shërbimit do të rregullojë një makinë aktuale. Zëvendësimi i një emri hosti të dokumentuar me një adresë të mirëfilltë nuk është as riparim.

Disa profile presin një identitet serveri që përputhet me emrin e konfiguruar, kështu që një zgjidhje numerike anësore mund të shkëmbejë një gabim me një tjetër. Nëse emri duhet të mbetet, rregulloni rrugën e zgjidhjes dhe jo tekstin e profilit. Në çdo rast, shkruani çfarë ndryshuat dhe pse.