Windows-VPN-erarkodoj: kiu stadio malsukcesis kaj kion protokoli

Malfermu la Windows-VPN-dialogon post malsukceso kaj ĝi donas al vi numeron kaj frazon, el kiuj la frazo kutime estas la malpli utila duono. La numero identigas, kiun stadion de la konekto malsukcesis, kaj la stadio difinas, kiun protokolon, kiun agordon kaj kiun teamon vi rigardu poste. Trapasi la stadiojn laŭorde daŭras ĉirkaŭ dek minutojn kaj malhelpas la konatan sinsekvon de reinstalo de adaptiloj, ŝanĝo de protokoloj kaj restarigo de la stako por ripari konton, al kiu neniam estis permesite alvoki.

Legu la numeron kiel stadion

Denaska konekto trapasas kvar etapojn. Ĝi atingas la servilon kaj starigas ligon, ĝi interkonsentas sekurecon, ĝi aŭtentikigas la uzanton, kaj ĝi aplikas adresadon kaj enkursigadon. Malsukceso ĉe ĉiu el ili lasas malsamajn pruvojn, kaj kodo apartenanta al unu stadio diras nenion utilan pri la aliaj.

La eraro evitebla estas trakti la kodon kiel severecon. Ligo-malsukceso kaj rajtig-malsukceso ambaŭ legiĝas kiel "ne eblis konekti", kaj ili havas nenion alian komunan. Severecont diras, kiom urĝa io estas; la stadio diras, kion malfermi.

Stadio unu: la ligo kaj la alvoka provo

829 signifas, ke la suba ligo falis. Ĝi ne diras, ĉu la fora samtavolano ĉesis respondi, ĉu meza skatolo mortigis la seancon, aŭ ĉu politiko sur la kliento fermis ĝin. Alvokfina kodo kiel 703 estas eĉ pli frua: la provo neniam atingis ligon, kio kutime montras al la profilo, la servostato aŭ loka politiko.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

La eventserĉo estas la parto, kiun homoj preterlasas. Klientflanka rikordo kun tempostampo kaj interfaca nomo valoras pli ol la dialogo, ĉar ĝi diras, ĉu la provo eĉ forlasis la maŝinon. Neniu rikordo kaj neniu respondo de la aŭskultanto estas atingebla problemo, kaj neniu kvanto da klienta redaktado ŝanĝas tion.

Se la sama profilo funkcias en alia reto, haltu ĉi tie. La kodo priskribas kondiĉon de vojo, ne agordan eraron, kaj la sekva utila komparo estas la du registraĵoj, ne plia reinstalo.

Stadio du: PPP kaj la ligo de la miniporto

720 kuŝas inter la ligo kaj la uzanto. La tunelo leviĝis kaj poste la PPP-tavolo ne povis interkonsenti adreson aŭ kontrolprotokolon, kio ofte estas liga problemo sur la kliento, ne rifuzita legitimilo. Tiu distingo estas la tuta valoro de la kodo: ĝi diras, ke la legitimilo neniam estis atingita, do la konto ne estas la suspektato.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Legi tiujn du eligojn pli informas ol restarigi ion ajn. Miniporto, kiu ĉeestas sed ne startis, aŭ protokolligo malŝaltita de alia programo, produktas ĝuste la malsukceson de ĉi tiu stadio. Ambaŭ ripareblas sen tuŝi la reston de la stako. Plena restarigo, kontraste, forigas adresadon kaj filtran staton, kiuj havis nenion komunan kun la misfunkcio.

Stadio tri: identeco kaj rajtigo

691 signifas, ke la legitimiloj estis rifuzitaj. 649 signifas, ke la konto ne rajtas alvoki, kaj 812 signifas, ke fora alirpolitiko rifuzis la konekton. Tiuj estas decidoj, ne transportaj misfunkcioj, kaj la kliento povas nur raporti ilin.

La pruvoj estas ĉe la alia flanko. Petu de la enireja operatoro la provon ĉe tiu tempostampo kaj la politikon, kiun ĝi kongruis; demandu la kataloga posedanto, ĉu la konto havas alvokan permeson kaj ĉu ĝi estas en la grupo, kiun la politiko postulas. Ŝanĝi la tunelan tipon aŭ reinstali la klienton ne povas ŝanĝi decidon faritan pri identeco.

Utila kutimo ĉe ĉi tiu stadio estas skribi la precizan kontan ĉenon en la bileton, inkluzive ajnan domajnan prefikson. Surprize multaj kazoj 691 estas konservita legitimilo por la malĝusta domajno, kaj tio videblas en la konta ĉeno, ne en la protokolaj agordoj.

Stadio kvar: konektita, kaj nenio funkcias

Konekto povas finiĝi kaj tamen esti senutila. Ĝi tenas adreson, la kliento raportas sukceson, kaj ĉiu peto de la aplikaĵo tempolimiĝas. Nenio en la dialogo reflektas tion, kaj ne ekzistas kodo por serĉi. Je tiu punkto la dialogo finiĝis kaj la utilaj pruvoj estas aliloke.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Se la vojo mankas, la servilo ne ŝovis ĝin aŭ la kliento faligis ĝin. Se la vojo ekzistas kaj la nomo malsukcesas, la solvado estas la problemo. Se ambaŭ funkcias kaj la aplikaĵo ankoraŭ malsukcesas, vi pasis la tunelon kaj estas en la propra agordo de la aplikaĵo.

Tenu la ŝanĝojn je unu tavolo por testo. Ĉiu redakto antaŭ la sekva provo iĝas parto de la kunteksto de la sekva kodo, kaj kodo, kiu priskribas vian lastan redakton, estas pli malbona ol neniu kodo.

Unu provo, unu ŝanĝo, unu rikordo

Kiu ajn estas la stadio, la rikordo devus enhavi la kodon, la mesaĝon, la profilan nomon, la tempostampon kaj la reton, en kiu vi estis. Kvin kampoj, kaj ĉiu el ili jam estas antaŭ vi en la dialogo aŭ la klienta protokolo. Tiu aro estas sufiĉe malgranda por alglui en bileton kaj sufiĉe specifa por ke iu alia reproduktu ĝin.

Poste metu tiun tempostampon apud la rikordo ĉe la alia flanko. La tabelo proksime de la supro de ĉi tiu paĝo diras, kiu stadio posedas ĉiun malkongruon. Sen la dua rikordo la kodo nur mallarĝigas la serĉon; kun ĝi, la stadio estas decidita. La komparo estas tio, kio igas numeron diagnozo anstataŭ konjekto.

Tiu kutimo kovras preskaŭ ĉiun denaskan Windows-VPN-misfunkcion, kaj neniu el la branĉoj postulas reinstalon de io ajn. La dialogo ĉiam diris al vi, kiun vi havas; la laboro estas rifuzi trakti ilin ĉiujn kiel la saman problemon.