L2TP/IPsec malsukcesas kiam la servo IKEEXT estas malŝaltita

Unu tekkomputilo atingas IKEv2-pordegon sed malsukcesas ĉe L2TP/IPsec-pordego, kaj la eraro aperas antaŭ ol iu ajn uzantnomo estas sendita. La profilo kutime estas la unua suspektato kaj kutime la malĝusta. Windows plenumas la IPsec-ŝlosilinterŝanĝon en servo, kaj dum tiu servo estas malŝaltita, la enkonstruita kliento havas neniun stakon por trakti. Kontrolu la servon antaŭ ol tuŝi eĉ unu profilkampon, kaj poste eltrovu, kio malŝaltis ĝin.

La servo malantaŭ la fiasko

IKE and AuthIP IPsec Keying Modules, montrata kiel IKEEXT en la servolisto, plenumas la ŝlosilinterŝanĝon kaj tenas la UDP 500 kaj 4500 ingojn en Windows. Malŝaltu ĝin kaj kaj L2TP/IPsec kaj IKEv2 perdas sian traktanton, dum PPTP kaj SSTP povas daŭre funkcii ĉar ili ne dependas de ĝi. Tiu divido klarigas, kial uzanto povas raporti, ke unu VPN-tipo funkcias kaj alia estas morta en la sama maŝino. La servo estas parto de la operaciumo, do neniu profila agordo povas anstataŭi ĝin.

Liberigi tiujn du pordojn estas la kromefiko, kiu produktas malbonajn konsilojn. Ilo aŭ forumafiŝo rimarkas, ke 500 kaj 4500 estas okupitaj, haltigas la servon por liberigi ilin, kaj tiel silente forigas IPsec de la gastiganto. La du efikoj estas unu ago, do ĉiu gvidilo, kiu rekomendas liberigi la pordojn, priskribas interŝanĝon, ne riparon.

Restarigu la servon sen diveni

Demandu la servoadministranton du demandojn: kio estas la starttipo, kaj kio estas la nuna stato. La unua diras, ĉu la servo revenos post restarto; la dua, ĉu ĝi nun funkcias. Rulu ambaŭ demandojn el altigita komandprompto, por ke la sama ŝelo povu poste ŝanĝi la agordon.

sc qc ikeext
sc query ikeext

Starttipo Disabled klarigas la tutan simptomon, kaj la solvo estas restarigi ĝin al Automatic kaj starti ĝin. En la konzolo Servoj la ero aperas sub sia montra nomo, IKE and AuthIP IPsec Keying Modules, do serĉado de IKEEXT en tiu listo trovas nenion. Restartu, se la servo estis startita nur post kiam malsukcesa konekto jam funkciis, ĉar stako pravigita en tiu ordo povas fiaski laŭ manieroj, kiuj ŝajnas ne rilataj.

sc config ikeext start= auto
net start ikeext

Kio denove malŝaltas ĝin

Kelkaj triapartaj VPN-programaroj alportas sian propran IPsec-realigon kaj malŝaltas IKEEXT dum instalado, post kio la Windows-kliento ĉesas funkcii. Forigi la alian produkton restarigis L2TP/IPsec en maŝinoj, kie profilŝanĝoj atingis nenion, kaj same faris reinstali ĝin sen la konflikta komponanto. La servo estis malŝaltita dum instalado, ne ŝaltita de la uzanto.

Gruppolitiko ankaŭ povas fiksi la starttipo; en tiu kazo loka ŝanĝo estas nuligita ĉe la sekva refreŝigo, kaj la administranto, kiu posedas la politikon, devas ŝanĝi ĝin. Notu la starttipo antaŭ restarto, post restarto kaj post ĝisdatigoj de la alia produkto, kun la dato ĉiufoje. Valoro, kiu rifuĝe revenas al Disabled, malkaŝas sian posedanton per la ŝablono, ne per konjektoj.

Legu la etapon, poste la protokolon

Kiam la servo funkcias, la etapo de la fiasko decidas, kien rigardi poste. Haltiĝo dum IKE kutime signifas, ke UDP 500 aŭ 4500 neniam atingis la servilon, aŭ ke la servilo sidas malantaŭ NAT sen la kongrua enkapsuliga agordo. Atingi la legitimadan antaŭsignalon kaj fiaski tie estas PPP-aŭtentiga problemo, ne IPsec-problemo. Tunelo, kiu leviĝas kaj atingas nenion, estas enkursiga aŭ dividita tunela misfunkcio, kaj nur la unua el tiuj tri loĝas en la VPN-profilo.

Atestilaj profilo aldonas propran etapon. La kliento devas fidi la eldonantan aŭtoritaton, kaj la atestilo devas nomi la servilon, kiun oni validigas; kiam unu el la du kondiĉoj malsukcesas, la dialogo ankoraŭ raportas komencan intertraktan eraron, do la eventa protokolo estas la loko, kie aperas la vera kaŭzo. Legu la protokoleron antaŭ ol redakti la profilon, ĉar la dialogo kunpremas plurajn distingajn malsukcesojn en unu frazon. Eksvalidiĝinta atestilo produktas la saman dialogon kiel malŝaltita servo, kaj tial la protokolero gravas.

Notu la malsukcesan etapon, la erartekston kaj la tempostampon por ĉiu provo. Tiuj tri kampoj apartigas atingeblan problemon de aŭtentiga problemo kaj de enkursiga problemo, kaj ili igas la sekvan ŝanĝon decido anstataŭ konjekto.

Kion loka riparo ne povas pruvi

Restarigi la servon riparas la duonon de la vojo, kiu estas sur la tekkomputilo. Funkcianta servo pruvas nur la lokan duonon: la fora fino ankoraŭ devas akcepti la elektitan proponon, la donitajn legitimilojn kaj la fontadreson, de kiu la paketo alvenas. Nenio farita sur la tekkomputilo kompensas fajroŝirmilon, kiu forĵetas UDP 500 antaŭ ol ĝi atingas la kunulon. Sukcesa servostato estas antaŭkondiĉo, ne pruvo, ke la tunelo leviĝos.

Malŝalti IKEEXT por liberigi la pordojn estas defendebla nur se vi akceptas, ke Windows-IPsec-VPN-oj ĉesas funkcii. Ĝi solvas pordan konflikton forigante la funkcion, kiu bezonis la pordon, kaj tio malofte estas la interŝanĝo, kiun la uzanto intencis. Antaŭ ol ŝanĝi ion, konfirmu, ke la servo ekzistas, estas agordita al Automatic kaj funkcias, ke neniu dua IPsec-stako estas instalita, kaj ke la antaŭdividita ŝlosilo aŭ atestila ĉeno kongruas kun la pordego.

• IKEEXT ekzistas, estas agordita al Automatic kaj funkcias antaŭ ol la kliento konektiĝas.
• Nenio alia tenas UDP 500 aŭ 4500.
• Neniu dua IPsec-stako restas de malnova kliento.
• La ŝlosilo aŭ atestila ĉeno kongruas kun la pordega agordo.
• La malsukcesa etapo estis notita antaŭ ol la profilo estis redaktita.