L2TP/IPsec misslyckas när tjänsten IKEEXT är inaktiverad

Ingen IKEEXT, ingen IPsec: L2TP och IKEv2 misslyckas medan andra typer fortfarande ansluter. Kontrollera tjänsten och ta sedan reda på vad som inaktiverade den innan du redigerar profilen.

En laptop når en IKEv2-gateway men misslyckas mot en L2TP/IPsec-gateway, och felet kommer innan något användarnamn skickas. Profilen är oftast den första misstänkta och oftast den felaktiga. Windows kör IPsec-nyckelutbytet i en tjänst, och så länge den tjänsten är inaktiverad har den inbyggda klienten ingen stack att förhandla med. Bekräfta tjänsten innan du rör ett enda profilfält och ta sedan reda på vad som inaktiverade den.

Tjänsten bakom felet

IKE and AuthIP IPsec Keying Modules, som visas som IKEEXT i tjänstelistan, utför nyckelutbytet och håller UDP 500- och 4500-uttagen på Windows. Inaktivera den och både L2TP/IPsec och IKEv2 förlorar sin förhandlare, medan PPTP och SSTP kan fortsätta fungera eftersom de inte är beroende av den. Den uppdelningen är anledningen till att en användare kan rapportera att en VPN-typ fungerar och en annan är död på samma maskin. Tjänsten är en del av operativsystemet, så ingen profilinställning kan ersätta den.

Att frigöra de två portarna är den bieffekt som ger dåliga råd. Ett verktyg eller ett foruminlägg märker att 500 och 4500 är upptagna, stoppar tjänsten för att frigöra dem och tar därmed tyst bort IPsec från värden. De två effekterna är en enda handling, så varje guide som rekommenderar att portarna rensas beskriver ett byte och inte en reparation.

Sätt tillbaka tjänsten utan att gissa

Ställ två frågor till tjänsthanteraren: vilken starttyp gäller, och vilket är det aktuella tillståndet. Den första säger om tjänsten återkommer efter en omstart; den andra om den körs nu. Kör båda frågorna från en förhöjd kommandotolk så att samma skal kan ändra inställningen efteråt.

sc qc ikeext
sc query ikeext

En starttyp Disabled förklarar hela symptomet, och lösningen är att ställa tillbaka den på Automatic och starta den. I tjänstekonsolen visas posten under sitt visningsnamn, IKE and AuthIP IPsec Keying Modules, så en sökning efter IKEEXT i den listan hittar inget. Starta om ifall tjänsten startades först efter att en misslyckad anslutning redan hade kört, eftersom en stack som initierats i den ordningen kan misslyckas på sätt som verkar orelaterade.

sc config ikeext start= auto
net start ikeext

Vad som slår av den igen

Vissa VPN-sviter från tredje part levererar sin egen IPsec-implementering och inaktiverar IKEEXT under installationen, varefter Windows-klienten slutar fungera. Att ta bort den andra produkten har återställt L2TP/IPsec på maskiner där profiländringar inte åstadkom något, och detsamma har en ominstallation utan den konfliktande komponenten. Tjänsten inaktiverades vid installationen, inte växlades av användaren.

Grupprincip kan också låsa starttypen; i så fall återställs en lokal ändring vid nästa uppdatering och administratören som äger principen måste ändra den. Anteckna starttypen före en omstart, efter en omstart och efter den andra produktens uppdateringar, med datum varje gång. Ett värde som ständigt återgår till Disabled avslöjar sin ägare genom mönstret, inte genom gissningar.

Läs fasen, sedan loggen

När tjänsten körs avgör felets fas var du ska titta härnäst. Ett stopp under IKE betyder oftast att UDP 500 eller 4500 aldrig nådde servern, eller att servern sitter bakom NAT utan den matchande inkapslingsinställningen. Att nå inloggningsprompten och misslyckas där är ett PPP-autentiseringsproblem, inte ett IPsec-problem. En tunnel som kommer upp och inte når något är ett routing- eller delad tunnel-fel, och bara det första av de tre ligger i VPN-profilen.

Certifikatprofiler lägger till en egen fas. Klienten måste lita på den utfärdande myndigheten och certifikatet måste namnge den server som valideras; när något av de två villkoren fallerar rapporterar dialogrutan fortfarande ett fel i den inledande förhandlingen, så händelseloggen är platsen där det verkliga skälet dyker upp. Läs loggposten innan du redigerar profilen, eftersom dialogrutan pressar ihop flera olika fel till en mening. Ett utgånget certifikat ger samma dialogruta som en inaktiverad tjänst, och därför spelar loggposten roll.

Fånga den misslyckade fasen, feltexten och tidsstämpeln för varje försök. De tre fälten skiljer ett nåbarhetsproblem från ett autentiseringsproblem och från ett routingproblem, och de gör nästa ändring till ett beslut i stället för en gissning.

Vad en lokal reparation inte kan bevisa

Att återställa tjänsten fixar den halva av vägen som ligger på laptopens. En fungerande tjänst bevisar bara den lokala halvan: fjärrsidan måste fortfarande acceptera det valda förslaget, de angivna uppgifterna och den källadress paketet kommer från. Inget som görs på laptopens kompenserar för en brandvägg som kastar UDP 500 innan det når peeren. Ett lyckat tjänstetillstånd är ett förkrav, inte ett bevis på att tunneln kommer upp.

Att inaktivera IKEEXT för att frigöra portarna är bara försvarbart om du accepterar att Windows IPsec-VPN slutar fungera. Det löser en portkonflikt genom att ta bort funktionen som behövde porten, och det är sällan det byte användaren avsåg. Innan du ändrar något, bekräfta att tjänsten finns, är inställd på Automatic och körs, att ingen andra IPsec-stack är installerad och att den fördelade nyckeln eller certifikatkedjan matchar gatewayen.

  • IKEEXT finns, är inställd på Automatic och körs innan klienten ansluter.
  • Inget annat håller UDP 500 eller 4500.
  • Ingen andra IPsec-stack finns kvar från en gammal klient.
  • Nyckeln eller certifikatkedjan matchar gatewaykonfigurationen.
  • Den misslyckade fasen antecknades innan profilen redigerades.

Relaterade artiklar