L2TP/IPsec fejler, når tjenesten IKEEXT er deaktiveret

Én laptop når en IKEv2-gateway, men fejler mod en L2TP/IPsec-gateway, og fejlen kommer, før der sendes noget brugernavn. Profilen er normalt den første mistænkte og normalt den forkerte. Windows kører IPsec-nøgleudvekslingen i en tjeneste, og mens den tjeneste er deaktiveret, har den indbyggede klient ingen stak at forhandle med. Bekræft tjenesten, før du rører ved et enkelt profilfelt, og find derefter ud af, hvad der deaktiverede den.

Tjenesten bag fejlen

IKE and AuthIP IPsec Keying Modules, vist som IKEEXT i tjenestelisten, udfører nøgleudvekslingen og holder UDP 500- og 4500-soklerne på Windows. Deaktiver den, og L2TP/IPsec og IKEv2 mister begge deres forhandler, mens PPTP og SSTP kan fortsætte med at virke, fordi de ikke afhænger af den. Den opdeling er grunden til, at en bruger kan rapportere, at én VPN-type virker og en anden er død på samme maskine. Tjenesten er en del af operativsystemet, så ingen profilindstilling kan erstatte den.

At frigøre de to porte er den bivirkning, der giver dårligt råd. Et værktøj eller et forumindlæg bemærker, at 500 og 4500 er optaget, stopper tjenesten for at frigøre dem og fjerner dermed lydløst IPsec fra værten. De to virkninger er én handling, så enhver guide, der anbefaler at rydde portene, beskriver en byttehandel og ikke en reparation.

Sæt tjenesten tilbage uden at gætte

Stil tjenestestyringen to spørgsmål: hvad er starttypen, og hvad er den aktuelle tilstand. Det første fortæller, om tjenesten vender tilbage efter en genstart; det andet, om den kører nu. Kør begge forespørgsler fra en forhøjet kommandoprompt, så den samme shell bagefter kan ændre indstillingen.

sc qc ikeext
sc query ikeext

En starttype Disabled forklarer hele symptomet, og løsningen er at sætte den tilbage til Automatic og starte den. I Services-konsollen vises posten under sit visningsnavn, IKE and AuthIP IPsec Keying Modules, så en søgning efter IKEEXT i den liste finder intet. Genstart, hvis tjenesten først blev startet, efter at en mislykket forbindelse allerede havde kørt, for en stak, der initialiseres i den rækkefølge, kan fejle på måder, der virker uden forbindelse.

sc config ikeext start= auto
net start ikeext

Hvad slår den fra igen

Nogle tredjeparts VPN-suiter leverer deres egen IPsec-implementering og deaktiverer IKEEXT under installationen, hvorefter Windows-klienten holder op med at virke. At fjerne det andet produkt har genskabt L2TP/IPsec på maskiner, hvor profilændringer ikke opnåede noget, og det samme har en geninstallation uden den konfliktende komponent. Tjenesten blev deaktiveret på installationstidspunktet, ikke slået til eller fra af brugeren.

Gruppepolitik kan også fastlåse starttypen; i så fald rulles en lokal ændring tilbage ved næste opdatering, og administratoren, der ejer politikken, skal ændre den. Noter starttypen før en genstart, efter en genstart og efter det andet produkts opdateringer, hver gang med datoen. En værdi, der bliver ved med at vende tilbage til Disabled, afslører sin ejer gennem mønstret og ikke gennem gætteri.

Læs fasen, og derefter loggen

Når tjenesten kører, afgør fejlens fase, hvor du skal kigge næste gang. Et stop under IKE betyder normalt, at UDP 500 eller 4500 aldrig nåede serveren, eller at serveren sidder bag NAT uden den matchende indkapslingsindstilling. At nå legitimationsprompten og fejle der er et PPP-autentificeringsproblem, ikke et IPsec-problem. En tunnel, der kommer op og ikke når noget, er en routing- eller split-tunnel-fejl, og kun den første af de tre ligger i VPN-profilen.

Certifikatprofiler tilføjer deres egen fase. Klienten skal stole på den udstedende myndighed, og certifikatet skal navngive den server, der valideres; når en af de to betingelser svigter, rapporterer dialogen stadig en fejl i den indledende forhandling, så hændelsesloggen er det sted, hvor den egentlige årsag vises. Læs logposten, før du redigerer profilen, fordi dialogen presser flere forskellige fejl sammen i én sætning. Et udløbet certifikat giver samme dialog som en deaktiveret tjeneste, og derfor er logposten vigtig.

Noter den mislykkede fase, fejlteksten og tidsstemplet for hvert forsøg. De tre felter adskiller et tilgængelighedsproblem fra et autentificeringsproblem og fra et routingproblem, og de gør den næste ændring til en beslutning i stedet for et gæt.

Hvad en lokal reparation ikke kan bevise

At genskabe tjenesten retter den halvdel af vejen, der ligger på laptop'en. En fungerende tjeneste beviser kun den lokale halvdel: den fjerne ende skal stadig acceptere det valgte forslag, de medsendte legitimationsoplysninger og den kildeadresse, pakken kommer fra. Intet, der gøres på laptop'en, opvejer en firewall, der kasserer UDP 500, før det når peer'en. En vellykket tjenestetilstand er en forudsætning, ikke et bevis for, at tunnelen kommer op.

At deaktivere IKEEXT for at frigøre portene er kun forsvarligt, hvis du accepterer, at Windows-IPsec-VPN'er holder op med at virke. Det løser en portkonflikt ved at fjerne den funktion, der havde brug for porten, og det er sjældent den byttehandel, brugeren havde tænkt sig. Før du ændrer noget, skal du bekræfte, at tjenesten findes, er sat til Automatic og kører, at der ikke er installeret en anden IPsec-stak, og at den foruddelte nøgle eller certifikatkæden passer til gatewayen.

• IKEEXT findes, er sat til Automatic og kører, før klienten opretter forbindelse.
• Intet andet holder UDP 500 eller 4500.
• Der er ikke en anden IPsec-stak tilbage fra en gammel klient.
• Nøglen eller certifikatkæden passer til gateway-konfigurationen.
• Den mislykkede fase blev noteret, før profilen blev redigeret.