Приложението VPN се срина: предпазният прекъсвач още ли е включен?

Започнете оттам, откъдето започва потребителят: прозорецът на клиента го няма, иконата в системния трей изчезна, а браузърът или зарежда, или не. Само това наблюдение не може да ви каже дали блокировката е оцеляла. Отговорът зависи от това кой компонент държи правилата, дали този компонент е умрял заедно с прозореца и дали платформата държи налагането извън приложението. Вървете от прозореца към процеса, после към защитната стена, после към действителния път.

Не рестартирайте първо; рестартът обикновено унищожава доказателствата.

Започнете от това, което още работи

Отворете списъка с процеси, преди да пипате каквото и да е. Настолният клиент обикновено се дели на процес за потребителски интерфейс и услуга или демон, а срив в първия не спира непременно втория. В Windows услугата може още да е в списъка, в Linux unit-ът може още да е активен, а в Android тунелът се притежава от системата, след като бъде дадено съгласие. Прочетете тези три факта в този ред.

Ако демонът е жив, тунелът вероятно също е жив, а липсващият прозорец е само козметика.

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

Четете блокировката от налагащия, а не от приложението

Ако клиентът прилага предпазния си прекъсвач чрез вмъкване на правила в защитната стена, тези правила принадлежат на операционната система и преживяват процеса, който ги е създал. Тогава сривът ви оставя блокирани без интерфейс да го изключите, което прилича на счупена мрежа, а не на защита. Ако вместо това блокировката живее в собствения път на пакетите на клиента, убиването на процеса премахва блокировката в същия момент.

Android подхожда още по друг начин: always-on VPN с lockdown е настройка на платформата, така че блокировката остава независимо от процеса на приложението и системата може да рестартира услугата. Вижте документацията на платформата за точното поведение, вместо да предполагате, че съвпада с настолен клиент.

Различавайте чист изход от срив

Нормалното Quit обикновено изпълнява пътя за изключване на клиента, който нарочно премахва правила и затваря тунела. Сривът пропуска този път и оставя каквото налагащият вече е инсталирал. Разликата се вижда във времевите марки на правилата спрямо изхода на процеса и в това дали още съществува остарял интерфейс на тунела без собственик.

Това разграничение решава възстановяването ви: чистият изход може да се нуждае от ново свързване, докато при срив може да е нужно останалите правила да бъдат премахнати чрез поддържаното действие за ремонт в клиента.

Възстановете, без да чупите други контроли

Рестартирайте клиента през документирания му работен процес, после проверете двете половини на изискването: тунелът пренася трафик и блокировката още се прилага, когато трябва. Изчистването на цялата защитна стена за възстановяване на свързаността премахва и несвързани контроли, а тази сделка рядко си заслужава.

При повторен срив съберете версията на клиента, билда на платформата и ограничените логове, които доставчикът иска. Профил на клиента, частен ключ или пълен лог на връзката за друг акаунт не са нужни за доклад за срив и включването им превръща поддръжката в проблем с обработката на данни.

Един срив не е доказателство за изтичане. Доказателството е наблюдаван пакет, който излиза по път, който политиката е трябвало да предотврати, уловен в момента, когато клиентът не е работел. Тествайте това нарочно, с безобидна дестинация, и запишете кой слой на налагане е удържал.