L2TP/IPsec misluk wanneer die IKEEXT-diens gedeaktiveer is

Een skootrekenaar bereik 'n IKEv2-gateway maar misluk teen 'n L2TP/IPsec-een, en die fout kom voordat enige gebruikersnaam gestuur word. Die profiel is gewoonlik die eerste verdagte en gewoonlik die verkeerde een. Windows doen IPsec-sleuteluitruiling in 'n diens, en terwyl daardie diens gedeaktiveer is, het die ingeboude kliënt geen stapel om mee te onderhandel nie. Bevestig die diens voordat jy aan 'n enkele profielveld raak, en vind dan uit wat dit gedeaktiveer het.

Die diens agter die mislukking

IKE and AuthIP IPsec Keying Modules, in die dienslys as IKEEXT gewys, voer die sleuteluitruiling uit en hou die UDP 500- en 4500-sokke op Windows. Deaktiveer dit en L2TP/IPsec en IKEv2 verloor albei hul onderhandelaar, terwyl PPTP en SSTP kan aanhou werk omdat hulle nie daarvan afhanklik is nie. Daardie skeiding is hoekom 'n gebruiker kan rapporteer dat een VPN-tipe werk en 'n ander op dieselfde masjien dood is. Die diens is deel van die bedryfstelsel, so geen profielinstelling kan dit vervang nie.

Om daardie twee poorte vry te maak is die newe-effek wat slegte raad oplewer. 'n Instrument of 'n forumplasing merk dat 500 en 4500 beset is, stop die diens om hulle vry te maak, en verwyder stilweg IPsec van die gasheer. Die twee effekte is een handeling, so enige gids wat aanbeveel om die poorte skoon te maak, beskryf 'n ruil eerder as 'n herstel.

Sit die diens terug sonder om te raai

Vra die diensbestuurder twee vrae: wat is die begintipe, en wat is die huidige toestand. Die eerste sê of die diens ná 'n herbegin sal terugkeer; die tweede sê of dit nou loop. Voer albei navrae vanaf 'n verhoogde opdragprompt uit sodat dieselfde dop daarna die instelling kan verander.

sc qc ikeext
sc query ikeext

'n Begintipe van Disabled verklaar die hele simptoom, en die oplossing is om dit terug te stel na Automatic en dit te begin. In die Dienste-konsole verskyn die inskrywing onder sy vertoonnaam, IKE and AuthIP IPsec Keying Modules, so om in daardie lys na IKEEXT te soek vind niks. Herbegin as die diens begin is nadat 'n mislukte verbinding reeds geloop het, want 'n stapel wat in daardie orde geïnitialiseer is, kan op maniere misluk wat onverwant lyk.

sc config ikeext start= auto
net start ikeext

Wat dit weer afskakel

Sommige derdeparty-VPN-suite lewer hul eie IPsec-implementering en deaktiveer IKEEXT tydens installasie, waarna die Windows-kliënt ophou werk. Die verwydering van die ander produk het L2TP/IPsec herstel op masjiene waar profielwysigings niks bereik het nie, en so ook die herinstallering daarvan sonder die botsende komponent. Die diens is tydens installasie gedeaktiveer, nie deur die gebruiker omgeskakel nie.

Groepsbeleid kan ook die begintipe vaspen, in welke geval 'n plaaslike verandering by die volgende verversing teruggedraai word en die administrateur wat die beleid besit dit moet verander. Teken die begintipe aan voor 'n herbegin, ná 'n herbegin en ná die ander produk se opdaterings, elke keer met die datum. 'n Waarde wat aanhoudend na Disabled terugkeer, identifiseer sy eienaar deur die patroon, nie deur giswerk nie.

Lees eers die fase, dan die log

Met die diens aan die loop, besluit die fase van die mislukking waar om volgende te kyk. 'n Vasloop tydens IKE beteken gewoonlik dat UDP 500 of 4500 nooit die bediener bereik het nie, of dat die bediener agter NAT sit sonder die ooreenstemmende inkapselingsinstelling. Om die aanmeldingsprompt te bereik en daar te misluk, is 'n PPP-verifikasieprobleem, nie 'n IPsec-een nie. 'n Tonnel wat opkom en niks bereik nie, is 'n roeterings- of split-tonnelfout, en net die eerste van daardie drie woon in die VPN-profiel.

Sertifikaatprofiele voeg 'n fase van hul eie by. Die kliënt moet die uitreikende owerheid vertrou, en die sertifikaat moet die bediener noem wat gevalideer word; wanneer enige van die twee voorwaardes misluk, meld die dialoog steeds 'n aanvanklike onderhandelingsfout, so die gebeurtenislog is waar die werklike rede verskyn. Lees die loginskrywing voordat jy die profiel wysig, want die dialoog druk verskeie afsonderlike mislukkings in een sin saam. 'n Verstreke sertifikaat lewer dieselfde dialoog as 'n gedeaktiveerde diens, en daarom maak die loginskrywing saak.

Teken die mislukte fase, die foutteks en die tydstempel vir elke poging aan. Daardie drie velde skei 'n bereikbaarheidsprobleem van 'n verifikasieprobleem van 'n roeteringsprobleem, en hulle maak die volgende verandering 'n besluit eerder as 'n raaiskoot.

Wat 'n plaaslike herstel nie kan bewys nie

Die herstel van die diens regmaak die helfte van die pad wat op die skootrekenaar woon. 'n Werkende diens bewys net die plaaslike helfte: die verre kant moet steeds die gekose voorstel, die verskafde geloofsbriewe en die bronadres waarvan die pakket aankom, aanvaar. Niks wat op die skootrekenaar gedoen word, vergoed vir 'n brandmuur wat UDP 500 weggooi voordat dit die eweknie bereik nie. 'n Suksesvolle dienstoestand is 'n voorwaarde, nie bewyse dat die tonnel sal opkom nie.

Om IKEEXT te deaktiveer om die poorte vry te maak, is net verdedigbaar as jy aanvaar dat Windows-IPsec-VPN's ophou werk. Dit los 'n poortbotsing op deur die funksie te verwyder wat die poort nodig gehad het, en dit is selde die ruil wat die gebruiker bedoel het. Voordat jy iets verander, bevestig dat die diens teenwoordig is, op Automatic gestel en aan die loop is, dat geen tweede IPsec-stapel geïnstalleer is nie, en dat die vooraf gedeelde sleutel of sertifikaatketting by die gateway pas.

• IKEEXT is teenwoordig, op Automatic gestel en loop voordat die kliënt verbind.
• Niks anders hou UDP 500 of 4500 nie.
• Geen tweede IPsec-stapel bly van 'n ou kliënt oor nie.
• Die sleutel of sertifikaatketting pas by die gateway-konfigurasie.
• Die mislukte fase is aangeteken voordat die profiel gewysig is.