VPN pe Mac blocat la „Se deconectează”: ce rulează de fapt

Deconectarea este o tranziție, nu un tunel oprit. Verificați ce componentă deține demontarea, citiți rutele și DNS-ul și evitați uciderea proceselor în bloc.

„Se deconectează” este o stare pe care clientul o raportează în timp ce demontează un tunel, nu o sentință că traficul s-a oprit. Pe un Mac acea demontare se desfășoară ca o secvență scurtă, iar eticheta se schimbă doar după ce componenta care deține conexiunea răspunde. Când un pas așteaptă un helper, un plugin sau o decizie de politică, eticheta poate rămâne acolo după ce interfața a dispărut, sau tunelul poate continua să transmită în timp ce meniul îl arată încă. Tratați textul ca „demontare în curs, rezultat necunoscut” și stabiliți care jumătate este adevărată.

Două defecțiuni arată identic din bara de meniu și cer reacții opuse. Într-una tunelul încă poartă pachete și doar afișarea este învechită. În cealaltă tunelul a dispărut, dar o politică separată ține traficul blocat, ceea ce este adesea intenționat. Rutele și starea DNS le separă mai repede decât orice acțiune în meniu.

Ce urmărește eticheta

Un client VPN ține o mică mașină de stări, iar bara de meniu este o proiecție a acesteia. Pentru o conexiune gestionată de macOS însuși, mașina se află în cadrul VPN al sistemului. Pentru un tunel gestionat de o aplicație, se află în aplicație și în helperul ei privilegiat. Ultimul pas al unei opriri nu este închiderea unui socket. Este eliberarea a ceea ce făcea tunelul funcțional: interfața utun, rutele care indicau spre ea, intrările de resolver injectate de client și orice regulă de firewall sau politică ce bloca traficul cât timp conexiunea era activă.

Acești pași sunt separați, așa că o oprire poate rămâne blocată la oricare dintre ei. Un helper care nu mai răspunde, o rută revendicată și de o a doua interfață sau o intrare de resolver deținută de alt profil pot lăsa clientul în așteptare. Eticheta este un raport despre progresul clientului însuși, ceea ce o face autoritară în privința intenției și nesigură în privința rețelei.

Găsiți componenta care deține conexiunea

În configurațiile native, scutil --nc list afișează serviciile cunoscute de sistem și starea lor, iar scutil --nc status "Work VPN" oferă detalii pentru un serviciu. Un tunel ținut de o aplicație terță poate să nu apară deloc în acea listă, deci un rezultat gol nu este dovada că nimic nu este conectat.

Când profilul aparține unei aplicații, bazați-vă pe vizualizarea stării acesteia și pe controlul documentat „Deconectează”. Închiderea ferestrei nu este o cerere de oprire dacă un helper din fundal deține tunelul; pictograma dispare, iar helperul ține interfața vie. referința pentru setările VPN a Apple acoperă controalele native și de unde vin setările gestionate.

Citiți interfețele, rutele și DNS-ul

Trei verificări răspund la cea mai mare parte a întrebării fără a atinge conexiunea. Interpretarea lor împreună este ce contează, fiindcă fiecare singură înșală.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • interfața utun există, o rută implicită sau divizată trece prin ea, resolverul indică furnizorul: tunelul este încă sus și eticheta este învechită.
  • fără utun, rută implicită obișnuită, DNS din DHCP, fără internet: o politică ce blochează la deconectare își face treaba.
  • fără utun, fără rută, resolverul indică încă furnizorul: demontarea s-a oprit la jumătatea drumului, iar DNS este restul de curățat.

Apoi trimiteți o cerere către un host intern care ar trebui să răspundă doar prin tunel și una către un host public. Accesibilitatea separă politica de starea reziduală fără a transforma verificarea într-un exercițiu de măsurare. Salvați mai întâi munca de la distanță dacă traseul încă răspunde și pregătiți o a doua cale de intrare înainte de a schimba rețeaua pe un aparat administrat de la distanță.

De ce induc în eroare uciderea în bloc și ștergerea profilului

Nume de procese precum pppd, racoon și configd aparțin unor implementări anume. Uciderea lor poate afecta alte conexiuni, lasă rute și interfețe utun în urmă și nu vă oferă nicio evidență a pasului care s-a blocat. Nici un nume vechi de proces nu este dovada că deține profilul actual.

Ștergerea și recrearea profilului este o schimbare mai mare decât curățarea unei tranziții blocate. Poate arunca setări gestionate și material de identitate local fără a explica ce a eșuat, iar pe un Mac supravegheat poate fi pur și simplu restaurat. Păstrați ștergerea pentru o configurație cu adevărat învechită și diagnosticați în schimb tranziția.

O secvență de oprire care lasă urmă

Ordinea de mai jos lasă controalele conexiunii însăși responsabile și produce o evidență dacă blocajul revine. Vă împiedică și să transformați o problemă de afișare într-o schimbare de rețea.

  1. Salvați munca de la distanță și confirmați că puteți ajunge la Mac altfel dacă este la distanță.
  2. Notați numele clientului, versiunea și profilul. Capturați o fereastră scurtă cu log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; versiunile mai vechi păstrează mai puțin istoric, așa că rulați-o imediat după blocaj.
  3. Folosiți controlul documentat „Deconectează”, așteptați, apoi repetați verificările de interfață și rute.
  4. Dacă eticheta este învechită dar tunelul este jos, lăsați-o și lăsați clientul să se reîmprospăteze în loc să forțați procese.
  5. Dacă demontarea s-a blocat cu adevărat, reporniți clientul, apoi planificați o repornire a Mac-ului după ce munca este salvată. Aparatele gestionate necesită procedura administratorului.

După recuperare, confirmați că ruta implicită obișnuită și resolverul DHCP au revenit și că traficul blocat fie a fost restabilit, fie este încă blocat intenționat. Notați profilul și versiunea clientului împreună cu simptomul, ca următoarea apariție să pornească de la dovezi și nu de la o presupunere din bara de meniu.

Articole similare