VPN-ul de pe Mac se conectează o dată, apoi expiră: curățați demonul IKE

Prima conexiune după o repornire funcționează. Fiecare încercare ulterioară se blochează în faza de conectare și în final expiră, iar singurul remediu de încredere este încă o repornire. Acest tipar nu este o problemă de profil și nu este o problemă de acreditări. Ceva din fundal încă păstrează starea de la încercarea anterioară, iar următoarea încercare se ciocnește de ea.

Pe macOS, acel ceva este de obicei demonul IKE.

Tiparul: o conexiune, apoi expirare

O conexiune care funcționează exact o dată pe pornire indică o stare care supraviețuiește unei deconectări, dar nu unei reporniri. Profilurile supraviețuiesc ambelor, deci profilul nu este variabila. Acreditările supraviețuiesc și ele ambelor, dacă serverul nu blochează contul. Ce se schimbă la repornire este setul de demoni care rulează și socketurile pe care le țin.

Asta restrânge investigația înainte de a deschide măcar un singur jurnal. Întrebarea devine care proces deține portul IKE și ce crede că face.

Doi demoni, un port

Sistemul rulează racoon când o conexiune vorbește IKE versiunea 1. Versiunile actuale aduc și iked pentru IKEv2 și stiva IPsec mai nouă. Ambele pot ocupa UDP 500 și UDP 4500, și ambele pot păstra o asociere de securitate pe jumătate deschisă după ce o încercare de conectare este anulată la promptul de parolă sau întreruptă de o schimbare de rețea.

Când se întâmplă asta, următoarea încercare nu începe curat. Încearcă să negocieze în timp ce asocierea veche încă ocupă starea partenerului, iar schimbul se blochează în loc să eșueze cu o eroare clară. Utilizatorul vede un indicator care se rotește, apoi o expirare.

Găsiți proprietarul înainte de a ucide ceva, pentru că răspunsul determină ce serviciu reporniți și ce jurnal citiți în continuare.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Citiți ieșirea ca două fapte: ce proces ține portul și dacă există mai mult de unul. Doi demoni IKE care concurează pentru același socket explică mult comportament intermitent care arată ca un server instabil.

Reporniți sarcina, nu procesul

Pe sistemele mai vechi este suficient să ucideți procesul și să lăsați următoarea conexiune să îl pornească din nou. În versiunile actuale demonul este gestionat de launchd, iar semnalizarea doar a procesului poate lăsa sarcina într-o stare în care nici nu rulează, nici nu este programată să pornească. Opriți și porniți sarcina.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Dacă launchd nu are o înregistrare a sarcinii, uciderea procesului după nume forțează totuși o negociere nouă la următoarea încercare. Testul este același în ambele cazuri: niciun proces nu ar trebui să țină portul când încercați să vă conectați din nou. Confirmați asta cu aceeași comandă lsof în loc să presupuneți că repornirea a funcționat.

Apoi conectați-vă o dată și citiți jurnalul clientului de la început. O negociere care trece de faza 1 și apoi raportează o eroare de transmisie repetă problema locală a socketului; o negociere respinsă de partener este un bilet complet diferit.

Când serverul este cel care refuză

Nu fiecare a doua conexiune eșuează local. Un server poate refuza o autentificare nouă pentru o fereastră fixă după o deconectare, iar expirarea la client arată identic cu un demon blocat. Distincția este ieftină: dacă repornirea demonului nu ajută, dar alt cont se conectează imediat, fereastra este pe partea serverului și Mac-ul nu a fost niciodată problema.

Politica de tunel divizat produce aceeași formă din cealaltă direcție. Un server care cere tot traficul în tunel va elimina un client configurat pentru tunel divizat în timpul negocierii, iar clientul raportează o expirare în loc de o respingere de politică. Schimbarea profilului pentru a trimite totul prin tunel poate face conexiunea să funcționeze, dar aceea este o decizie de politică de luat cu proprietarul rețelei, nu o reparație de aplicat în tăcere.

Citiți jurnalul partenerului înainte de a schimba din nou clientul. O respingere, o nepotrivire de politică și o eliminare silențioasă sunt trei cauze diferite care pe ecranul Mac-ului arată toate ca „se conectează”.

Clienți mai vechi și nucleul pe 64 de biți

Clientul vechi Cisco IPSec încarcă o extensie de nucleu construită pentru sisteme pe 32 de biți și PowerPC. Pe un Mac pornit în nucleul pe 64 de biți, acea extensie nu poate fi încărcată, iar clientul eșuează devreme cu eroarea 51 pentru că nu ajunge deloc la subsistemul VPN. Niciun număr de reporniri ale demonului nu repară o extensie de nucleu cu arhitectura greșită.

Reîncărcarea extensiei poate funcționa o vreme și apoi poate eșua din nou la următoarea pornire. Răspunsurile durabile sunt să rulați nucleul mai vechi acolo unde este încă acceptat, sau să treceți la clientul încorporat care vine cu sistemul. Verificați arhitectura înainte de a petrece o seară cu un client terț care nu se poate încărca.

• Reproduceți o dată, apoi verificați ce demon deține UDP 500 înainte de a atinge profilul.
• Citiți primul eșec după faza 1: o eroare de transmisie indică socketul local.
• Reporniți sarcina launchd, nu doar procesul, și confirmați că portul este liber.
• Încercați un al doilea cont pentru a separa o fereastră de reautentificare de pe partea serverului de o defecțiune a clientului.
• Notați arhitectura nucleului înainte de a da vina pe client.

Un VPN care funcționează exact o dată este o problemă de stare până la proba contrarie. Curățarea demonului este mai rapidă decât o repornire și păstrează dovezile din jurnal pe care o repornire le-ar fi aruncat.