L2TP/IPsec feiler når tjenesten IKEEXT er deaktivert

Én laptop når en IKEv2-gateway, men feiler mot en L2TP/IPsec-gateway, og feilen kommer før noe brukernavn sendes. Profilen er vanligvis den første mistenkte og vanligvis den feilaktige. Windows kjører IPsec-nøkkelutvekslingen i en tjeneste, og mens den tjenesten er deaktivert, har den innebygde klienten ingen stakk å forhandle med. Bekreft tjenesten før du rører et eneste profilfelt, og finn deretter ut hva som deaktiverte den.

Tjenesten bak feilen

IKE and AuthIP IPsec Keying Modules, vist som IKEEXT i tjenestelisten, utfører nøkkelutvekslingen og holder UDP 500- og 4500-socketene på Windows. Deaktiver den, og både L2TP/IPsec og IKEv2 mister forhandleren sin, mens PPTP og SSTP kan fortsette å virke fordi de ikke er avhengige av den. Den delingen er grunnen til at en bruker kan rapportere at én VPN-type virker og en annen er død på samme maskin. Tjenesten er en del av operativsystemet, så ingen profilinnstilling kan erstatte den.

Å frigjøre de to portene er bivirkningen som gir dårlige råd. Et verktøy eller et foruminnlegg merker at 500 og 4500 er opptatt, stopper tjenesten for å frigjøre dem og fjerner dermed lydløst IPsec fra verten. De to virkningene er én handling, så enhver veiledning som anbefaler å rydde portene, beskriver en byttehandel og ikke en reparasjon.

Sett tjenesten tilbake uten å gjette

Still tjenestestyringen to spørsmål: hva er starttypen, og hva er den gjeldende tilstanden. Det første forteller om tjenesten kommer tilbake etter en omstart; det andre om den kjører nå. Kjør begge spørringene fra en forhøyet kommandoprompt, slik at samme skall kan endre innstillingen etterpå.

sc qc ikeext
sc query ikeext

En starttype Disabled forklarer hele symptomet, og løsningen er å sette den tilbake til Automatic og starte den. I Tjenester-konsollen vises oppføringen under visningsnavnet, IKE and AuthIP IPsec Keying Modules, så et søk etter IKEEXT i den listen finner ingenting. Start på nytt hvis tjenesten ble startet først etter at en mislykket tilkobling allerede hadde kjørt, fordi en stakk som initialiseres i den rekkefølgen, kan feile på måter som virker urelaterte.

sc config ikeext start= auto
net start ikeext

Hva som slår den av igjen

Noen VPN-suite fra tredjepart leverer sin egen IPsec-implementasjon og deaktiverer IKEEXT under installasjonen, hvoretter Windows-klienten slutter å virke. Å fjerne det andre produktet har gjenopprettet L2TP/IPsec på maskiner der profilendringer ikke oppnådde noe, og det samme har en reinstallasjon uten den motstridende komponenten. Tjenesten ble deaktivert ved installasjonen, ikke slått av og på av brukeren.

Gruppepolicy kan også låse starttypen; i så fall tilbakestilles en lokal endring ved neste oppdatering, og administratoren som eier policyen, må endre den. Noter starttypen før en omstart, etter en omstart og etter det andre produktets oppdateringer, hver gang med dato. En verdi som stadig går tilbake til Disabled, avslører eieren sin gjennom mønsteret, ikke gjennom gjetting.

Les fasen, deretter loggen

Når tjenesten kjører, avgjør feilens fase hvor du skal se neste gang. En stans under IKE betyr vanligvis at UDP 500 eller 4500 aldri nådde serveren, eller at serveren sitter bak NAT uten den samsvarende innkapslingsinnstillingen. Å nå påloggingsforespørselen og feile der er et PPP-autentiseringsproblem, ikke et IPsec-problem. En tunnel som kommer opp og ikke når noe, er en ruting- eller delt tunnel-feil, og bare den første av de tre ligger i VPN-profilen.

Sertifikatprofiler legger til en egen fase. Klienten må stole på den utstedende myndigheten, og sertifikatet må navngi serveren som valideres; når en av de to betingelsene svikter, rapporterer dialogen fortsatt en feil i den innledende forhandlingen, så hendelsesloggen er stedet der den virkelige årsaken dukker opp. Les loggoppføringen før du redigerer profilen, fordi dialogen presser flere ulike feil sammen i én setning. Et utløpt sertifikat gir samme dialog som en deaktivert tjeneste, og derfor betyr loggoppføringen noe.

Ta vare på den mislykkede fasen, feilteksten og tidsstempelet for hvert forsøk. De tre feltene skiller et tilgjengelighetsproblem fra et autentiseringsproblem og fra et rutingproblem, og de gjør den neste endringen til en beslutning i stedet for en gjetning.

Hva en lokal reparasjon ikke kan bevise

Å gjenopprette tjenesten fikser den halvdelen av veien som ligger på laptopen. En fungerende tjeneste beviser bare den lokale halvdelen: den andre enden må fortsatt godta forslaget som er valgt, påloggingsinformasjonen som er oppgitt, og kildeadressen pakken kommer fra. Ingenting som gjøres på laptopen, kompenserer for en brannmur som forkaster UDP 500 før det når peeren. En vellykket tjenestetilstand er en forutsetning, ikke bevis for at tunnelen kommer opp.

Å deaktivere IKEEXT for å frigjøre portene er bare forsvarlig hvis du godtar at Windows-IPsec-VPN-er slutter å virke. Det løser en portkonflikt ved å fjerne funksjonen som trengte porten, og det er sjelden byttehandelen brukeren hadde tenkt seg. Før du endrer noe, bekreft at tjenesten finnes, er satt til Automatic og kjører, at ingen andre IPsec-stakker er installert, og at den forhåndsdelte nøkkelen eller sertifikatkjeden passer til gatewayen.

• IKEEXT finnes, er satt til Automatic og kjører før klienten kobler til.
• Ingenting annet holder UDP 500 eller 4500.
• Det er ikke noen andre IPsec-stakker igjen fra en gammel klient.
• Nøkkelen eller sertifikatkjeden passer til gateway-konfigurasjonen.
• Den mislykkede fasen ble notert før profilen ble redigert.