Aplicația VPN s-a prăbușit: comutatorul de siguranță mai este pornit?

Începeți de unde începe utilizatorul: fereastra clientului a dispărut, pictograma din zona de notificare a dispărut, iar browserul fie încarcă, fie nu. Doar această observație nu vă poate spune dacă blocarea a supraviețuit. Răspunsul depinde de ce componentă ține regulile, dacă acea componentă a murit odată cu fereastra și dacă platforma ține aplicarea în afara aplicației. Mergeți de la fereastră la proces, apoi la firewall, apoi la calea reală.

Nu reporniți mai întâi; o repornire distruge de obicei dovezile.

Începeți cu ce încă rulează

Deschideți lista de procese înainte de a atinge ceva. Un client desktop se împarte de obicei într-un proces de interfață cu utilizatorul și un serviciu sau demon, iar o prăbușire a primului nu îl oprește neapărat pe al doilea. Pe Windows serviciul poate fi încă listat, pe Linux unitatea poate fi încă activă, iar pe Android tunelul aparține sistemului odată ce consimțământul este dat. Citiți aceste trei fapte în această ordine.

Dacă demonul este viu, tunelul este probabil și el viu, iar fereastra lipsă este doar cosmetică.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Citiți blocarea la cel care o aplică, nu în aplicație

Dacă clientul își implementează comutatorul de siguranță inserând reguli de firewall, acele reguli aparțin sistemului de operare și supraviețuiesc procesului care le-a creat. O prăbușire vă lasă atunci blocat fără nicio interfață pentru a-l opri, ceea ce arată ca o rețea stricată, nu ca o protecție. Dacă în schimb blocarea trăiește în calea de pachete a clientului însuși, uciderea procesului elimină blocarea în același moment.

Android tratează asta din nou altfel: always-on VPN cu lockdown este o setare a platformei, așa că blocarea persistă independent de procesul aplicației, iar sistemul poate reporni serviciul. Consultați documentația platformei pentru comportamentul exact în loc să presupuneți că seamănă cu un client desktop.

Distingeți o ieșire curată de o prăbușire

Un Quit normal rulează de obicei calea de oprire a clientului, care elimină regulile și închide tunelul intenționat. O prăbușire sare peste acea cale și lasă tot ce a instalat deja aplicatorul. Diferența se vede în marcajele de timp ale regulilor față de ieșirea procesului și în existența unei interfețe de tunel vechi fără proprietar.

Acea distincție decide recuperarea: o ieșire curată poate avea nevoie de o conexiune nouă, în timp ce o prăbușire poate avea nevoie ca regulile rămase să fie eliminate prin acțiunea de reparare acceptată de client.

Recuperați fără a rupe alte controale

Reporniți clientul prin fluxul său de lucru documentat, apoi verificați ambele jumătăți ale cerinței: tunelul transportă trafic, iar blocarea se aplică în continuare când trebuie. Golirea întregului firewall pentru a recupera conectivitatea elimină și controale nelegate, iar acest schimb rareori merită.

Pentru o prăbușire repetată, colectați versiunea clientului, build-ul platformei și jurnalele limitate pe care le cere furnizorul. Un profil de client, o cheie privată sau un jurnal complet de conexiune al altui cont nu sunt necesare pentru un raport de prăbușire, iar includerea lor transformă un caz de suport într-o problemă de prelucrare a datelor.

O prăbușire nu este dovada unei scurgeri. Dovada este un pachet observat care pleacă pe o cale pe care politica trebuia să o împiedice, capturat în momentul în care clientul era oprit. Testați asta intenționat, cu o destinație inofensivă, și notați ce strat de aplicare a rezistat.