Éin laptop når ein IKEv2-gateway, men feilar mot ein L2TP/IPsec-gateway, og feilen kjem før noko brukarnamn vert sendt. Profilen er vanlegvis den første mistenkte og vanlegvis den feilaktige. Windows køyrer IPsec-nøkkelutvekslinga i ei teneste, og medan den tenesta er deaktivert, har den innebygde klienten ingen stakk å forhandle med. Stadfest tenesta før du rører eitt einaste profilfelt, og finn deretter ut kva som deaktiverte ho.

Tenesta bak feilen

IKE and AuthIP IPsec Keying Modules, vist som IKEEXT i tenestelista, utfører nøkkelutvekslinga og held UDP 500- og 4500-socketane på Windows. Deaktiver ho, og både L2TP/IPsec og IKEv2 mistar forhandlaren sin, medan PPTP og SSTP kan halde fram med å virke fordi dei ikkje er avhengige av ho. Den delinga er grunnen til at ein brukar kan rapportere at éin VPN-type virkar og ein annan er død på same maskin. Tenesta er ein del av operativsystemet, så inga profilinnstilling kan erstatte ho.

Å frigjere dei to portane er biverknaden som gir dårlege råd. Eit verktøy eller eit foruminnlegg merkar at 500 og 4500 er opptekne, stoppar tenesta for å frigjere dei og fjernar dermed lydlaust IPsec frå verten. Dei to verknadene er éi handling, så kvar rettleiar som tilrår å rydde portane, skildrar ein byttehandel og ikkje ein reparasjon.

Set tenesta tilbake utan å gjette

Still tenestestyringa to spørsmål: kva er starttypen, og kva er den gjeldande tilstanden. Det første fortel om tenesta kjem tilbake etter ein omstart; det andre om ho køyrer no. Køyr båe spørjingane frå ein forhøgd kommandoprompt, slik at same skal kan endre innstillinga etterpå.

sc qc ikeext
sc query ikeext

Ein starttype Disabled forklarer heile symptomet, og løysinga er å setje han tilbake til Automatic og starte tenesta. I Tenester-konsollen visest oppføringa under visingsnamnet, IKE and AuthIP IPsec Keying Modules, så eit søk etter IKEEXT i den lista finn ingenting. Start på nytt dersom tenesta vart starta først etter at ei mislukka tilkobling alt hadde køyrt, fordi ein stakk som vert initialisert i den rekkjefølgja, kan feile på måtar som verkar urelaterte.

sc config ikeext start= auto
net start ikeext

Kva som slår ho av igjen

Nokre VPN-suitar frå tredjepart leverer si eiga IPsec-implementering og deaktiverer IKEEXT under installasjonen, korkje Windows-klienten sluttar å virke. Å fjerne det andre produktet har gjenoppretta L2TP/IPsec på maskiner der profilendringar ikkje oppnådde noko, og det same har ein reinstallasjon utan den motstridande komponenten. Tenesta vart deaktivert ved installasjonen, ikkje slått av og på av brukaren.

Gruppepolicy kan også låse starttypen; i så fall vert ei lokal endring tilbakestilt ved neste oppdatering, og administratoren som eig policyen, må endre han. Noter starttypen før ein omstart, etter ein omstart og etter oppdateringane til det andre produktet, kvar gong med dato. Ein verdi som stadig går tilbake til Disabled, avslører eigaren sin gjennom mønsteret, ikkje gjennom gjetting.

Les fasen, deretter loggen

Når tenesta køyrer, avgjer fasen til feilen kvar du skal sjå neste gong. Ein stans under IKE tyder vanlegvis at UDP 500 eller 4500 aldri nådde serveren, eller at serveren sit bak NAT utan den samsvarande innkapslingsinnstillinga. Å nå påloggingsforespurnaden og feile der er eit PPP-autentiseringsproblem, ikkje eit IPsec-problem. Ein tunnel som kjem opp og ikkje når noko, er ein ruting- eller delt tunnel-feil, og berre den første av dei tre ligg i VPN-profilen.

Sertifikatprofilar legg til ein eigen fase. Klienten må stole på den utstedande myndigheita, og sertifikatet må namngi serveren som vert validert; når ein av dei to vilkåra sviktar, rapporterer dialogen framleis ein feil i den innleiande forhandlinga, så hendingsloggen er staden der den verkelege årsaka dukkar opp. Les loggoppføringa før du redigerer profilen, fordi dialogen pressar fleire ulike feil saman i éi setning. Eit utløpt sertifikat gir same dialog som ei deaktivert teneste, og derfor betyr loggoppføringa noko.

Ta vare på den mislukka fasen, feilteksten og tidsstempelet for kvart forsøk. Dei tre felta skil eit tilgjengeproblem frå eit autentiseringsproblem og frå eit rutingproblem, og dei gjer den neste endringa til ei avgjerd i staden for ei gjetting.

Kva ein lokal reparasjon ikkje kan bevise

Å gjenopprette tenesta rettar den halvdelen av vegen som ligg på laptopen. Ei fungerande teneste beviser berre den lokale halvdelen: den andre enden må framleis godta forslaget som er valt, påloggingsinformasjonen som er oppgitt, og kjeldeadressa pakken kjem frå. Ingenting som vert gjort på laptopen, kompenserer for ein brannmur som forkastar UDP 500 før det når peeren. Ein vellukka tenestetilstand er ei føresetnad, ikkje eit prov på at tunnelen kjem opp.

Å deaktivere IKEEXT for å frigjere portane er berre forsvarleg om du godtek at Windows-IPsec-VPN-ar sluttar å virke. Det løyser ein portkonflikt ved å fjerne funksjonen som trong porten, og det er sjeldan byttehandelen brukaren hadde tenkt seg. Før du endrar noko, stadfest at tenesta finst, er sett til Automatic og køyrer, at ingen andre IPsec-stakkar er installerte, og at den førehandsdelte nøkkelen eller sertifikatkjeda passar til gatewayen.

  • IKEEXT finst, er sett til Automatic og køyrer før klienten koplar til.
  • Ingenting anna held UDP 500 eller 4500.
  • Det er ikkje nokon andre IPsec-stakkar att frå ein gammal klient.
  • Nøkkelen eller sertifikatkjeda passar til gateway-konfigurasjonen.
  • Den mislukka fasen vart notert før profilen vart redigert.

Relaterte artiklar