Праграма VPN завяршылася з памылкай: ці аварыйны выключальнік яшчэ ўключаны?

Збой можа пакінуць блакаванне на месцы або зняць яго разам з працэсам — залежыць ад таго, хто яго ўжывае. Праверце кліент, аперацыйную сістэму і міжсеткавы экран, перш чым рабіць выснову.

Пачніце з таго, з чаго пачынае карыстальнік: акно кліента знікла, значок у лотку знік, а браўзер або загружае старонку, або не. Адно гэтае назіранне не можа сказаць, ці перажыло блакаванне. Адказ залежыць ад таго, які кампанент трымае правілы, ці загінуў гэты кампанент разам з акном і ці трымае платформа ўжыванне па-за праграмай. Ідзіце ад акна да працэсу, затым да міжсеткавага экрана, затым да фактычнага шляху.

Не перазагружайце адразу; перазагрузка звычайна знішчае доказы.

Пачніце з таго, што яшчэ працуе

Адкрыйце спіс працэсаў, перш чым нешта чапаць. Кліент для працоўнага стала звычайна дзеліцца на працэс інтэрфейсу і службу або дэман, і збой першага не абавязкова спыняе другі. У Windows служба можа заставацца ў спісе, у Linux юніт можа быць яшчэ актыўным, а ў 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 запускае шлях завяршэння кліента, які наўмысна выдаляе правілы і зачыняе тунель. Збой прапускае гэты шлях і пакідае ўсё, што ўжо ўсталяваў выканаўца. Розніца бачная ў адзнаках часу правілаў адносна выхаду працэсу і ў тым, ці існуе яшчэ састарэлы інтэрфейс тунеля без уладальніка.

Гэтае адрозненне вызначае ваша аднаўленне: звычайны выхад можа патрабаваць новага падключэння, а збой — выдалення пакінутых правілаў праз падтрымоўванае дзеянне рамонту ў кліенце.

Аднавіцеся, не зламаўшы іншыя сродкі кантролю

Перазапусціце кліент праз яго дакументаваны працоўны працэс, затым праверце абедзве паловы патрабавання: тунель перадае трафік, і блакаванне ўсё яшчэ дзейнічае, калі павінна. Поўнае скідванне міжсеткавага экрана дзеля аднаўлення сувязі таксама выдаляе староннія сродкі кантролю, і такі абмен рэдка варты.

Пры паўторным збоі збярыце версію кліента, зборку платформы і абмежаваныя журналы, якія просіць пастаўшчык. Профіль кліента, прыватны ключ або поўны журнал падключэння іншага ўліковага запісу не патрэбныя для справаздачы пра збой, а іх уключэнне ператварае зварот у праблему апрацоўкі даных.

Адзін збой не доказ уцечкі. Доказ — гэта заўважаны пакет, які выходзіць шляхам, які палітыка павінна была прадухіліць, зафіксаваны ў момант, калі кліент не працаваў. Праверце гэта наўмысна, з бясшкоднай мэтай, і запішыце, які слой ужывання выстаяў.

Падобныя артыкулы