L2TP/IPsec eșuează când serviciul IKEEXT este dezactivat

Un laptop ajunge la un gateway IKEv2, dar eșuează la unul L2TP/IPsec, și eroarea apare înainte de a fi trimis vreun nume de utilizator. Profilul este de obicei primul suspect și de obicei cel greșit. Windows rulează schimbul de chei IPsec într-un serviciu, iar cât timp acel serviciu este dezactivat, clientul integrat nu are niciun stack cu care să negocieze. Verificați serviciul înainte de a atinge măcar un câmp al profilului și apoi aflați ce l-a dezactivat.

Serviciul din spatele eșecului

IKE and AuthIP IPsec Keying Modules, afișat ca IKEEXT în lista de servicii, efectuează schimbul de chei și deține socketurile UDP 500 și 4500 pe Windows. Dezactivați-l și atât L2TP/IPsec, cât și IKEv2 își pierd negociatorul, în timp ce PPTP și SSTP pot continua să funcționeze pentru că nu depind de el. Această separare explică de ce un utilizator poate raporta că un tip de VPN funcționează și altul este mort pe aceeași mașină. Serviciul face parte din sistemul de operare, așa că nicio setare de profil nu îl poate înlocui.

Eliberarea acestor două porturi este efectul secundar care produce sfaturi proaste. Un instrument sau o postare pe forum observă că 500 și 4500 sunt ocupate, oprește serviciul pentru a le elibera și astfel elimină în tăcere IPsec de pe gazdă. Cele două efecte sunt o singură acțiune, așa că orice ghid care recomandă curățarea porturilor descrie un schimb, nu o reparație.

Puneți serviciul la loc fără să ghiciți

Puneți managerului de servicii două întrebări: care este tipul de pornire și care este starea actuală. Prima vă spune dacă serviciul va reveni după o repornire; a doua dacă rulează acum. Rulați ambele interogări dintr-un prompt ridicat, astfel încât același shell să poată modifica setarea după aceea.

sc qc ikeext
sc query ikeext

Un tip de pornire Disabled explică întregul simptom, iar soluția este să îl readuceți la Automatic și să îl porniți. În consola Services intrarea apare sub numele de afișare, IKE and AuthIP IPsec Keying Modules, așa că o căutare după IKEEXT în acea listă nu găsește nimic. Reporniți dacă serviciul a fost pornit după ce o conexiune eșuată rulase deja, pentru că un stack inițializat în acea ordine poate eșua în moduri care par fără legătură.

sc config ikeext start= auto
net start ikeext

Ce îl oprește din nou

Unele suite VPN terțe includ propria implementare IPsec și dezactivează IKEEXT în timpul instalării, după care clientul Windows nu mai funcționează. Eliminarea celuilalt produs a restaurat L2TP/IPsec pe mașini unde modificările profilului nu obțineau nimic, la fel și reinstalarea fără componenta conflictuală. Serviciul a fost dezactivat la instalare, nu comutat de utilizator.

Și criteriile de grup pot fixa tipul de pornire; în acest caz, o modificare locală este anulată la următoarea reîmprospătare, iar administratorul care deține criteriul trebuie să o schimbe. Notați tipul de pornire înainte de o repornire, după o repornire și după actualizările celuilalt produs, cu data de fiecare dată. O valoare care revine mereu la Disabled își trădează proprietarul prin tipar, nu prin presupuneri.

Citiți etapa, apoi jurnalul

Cu serviciul pornit, etapa eșecului decide unde să priviți în continuare. Un blocaj în timpul IKE înseamnă de obicei că UDP 500 sau 4500 nu a ajuns niciodată la server, sau că serverul se află în spatele NAT fără setarea de încapsulare corespunzătoare. A ajunge la promptul de acreditări și a eșua acolo este o problemă de autentificare PPP, nu de IPsec. Un tunel care se ridică și nu ajunge nicăieri este o defecțiune de rutare sau de tunel divizat, și doar prima dintre aceste trei se află în profilul VPN.

Profilele cu certificat adaugă o etapă proprie. Clientul trebuie să aibă încredere în autoritatea emitentă, iar certificatul trebuie să numească serverul validat; când oricare dintre cele două condiții eșuează, dialogul raportează în continuare o eroare de negociere inițială, așa că jurnalul de evenimente este locul unde apare motivul real. Citiți intrarea din jurnal înainte de a edita profilul, pentru că dialogul comprimă mai multe defecțiuni distincte într-o singură frază. Un certificat expirat produce același dialog ca un serviciu dezactivat, și de aceea contează intrarea din jurnal.

Notați etapa care eșuează, textul erorii și marca temporală pentru fiecare încercare. Aceste trei câmpuri separă o problemă de accesibilitate de una de autentificare și de una de rutare, și transformă următoarea modificare într-o decizie în loc de o presupunere.

Ce nu poate dovedi o reparație locală

Restaurarea serviciului repară jumătatea drumului care se află pe laptop. Un serviciu funcțional dovedește doar jumătatea locală: capătul îndepărtat trebuie să accepte în continuare propunerea aleasă, acreditările furnizate și adresa sursă de la care sosește pachetul. Nimic din ce se face pe laptop nu compensează un firewall care aruncă UDP 500 înainte de a ajunge la peer. O stare de serviciu reușită este o condiție prealabilă, nu o dovadă că tunelul se va ridica.

Dezactivarea IKEEXT pentru a elibera porturile este justificabilă doar dacă acceptați că VPN-urile IPsec din Windows nu mai funcționează. Rezolvă un conflict de porturi eliminând funcția care avea nevoie de port, ceea ce este rareori schimbul dorit de utilizator. Înainte de a schimba ceva, confirmați că serviciul există, este setat pe Automatic și rulează, că nu este instalat un al doilea stack IPsec și că cheia prepartajată sau lanțul de certificate corespunde gateway-ului.

• IKEEXT există, este setat pe Automatic și rulează înainte ca clientul să se conecteze.
• Nimic altceva nu ține ocupat UDP 500 sau 4500.
• Nu rămâne un al doilea stack IPsec de la un client vechi.
• Cheia sau lanțul de certificate corespunde configurației gateway-ului.
• Etapa care a eșuat a fost notată înainte de editarea profilului.