Аварыйны выключальнік працягвае блакаваць трафік пасля адключэння VPN

Тунэль знік, значок сеткі выглядае нармальна, і нічога не загружаецца. Вы адключылі VPN, або выдалілі яго, або перазагрузілі камп’ютар, а блакаванне, якое павінна было абараніць вас падчас разрыву, усё яшчэ стаіць. Акно кліента не можа гэтага патлумачыць, бо блакуе вас не кліент: рашэнне было запісана ў ядро ад вашага імя, і нічога не засталося, каб яго выдаліць. У Windows гэты стан знаходзіцца ў платформе фільтрацыі Windows; у Linux гэта набор правілаў у iptables або nftables, часта са здымкам, які прайграваецца пры загрузцы. Далей ідзе парадак, якім карыстаюся я: прачытаць стан, выдаліць самы вузкі аб’ект, які тлумачыць збой, затым знайсці ўсё, што вяртае яго назад.

Аварыйны выключальнік — гэта стан ядра, а не налада

Кліенты для працоўнага стала рэалізуюць блакаванне, дадаючы фільтры, якія забараняюць трафік па-за тунэлем. У Windows гэта фільтры WFP на ўзроўнях перанакіравання злучэння і транспарту, і некаторыя з іх пастаянныя: яны запісваюцца ў сховішча палітык базавага рухавіка фільтрацыі і аднаўляюцца пры загрузцы машыны, перш чым запусціцца любое VPN-праграмнае забеспячэнне. Кліенты адрозніваюцца тым, калі яны прыбіраюць. Некаторыя выдаляюць фільтры пры адключэнні, некаторыя толькі пры чыстым выхадзе, а некаторыя толькі калі спачатку выключаны аварыйны выключальнік. Выдаліце праграму, пакуль блакаванне актыўнае, або забіце працэс, і фільтры застануцца.

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

Прачытайце стан WFP, перш чым нешта выдаляць

Windows пастаўляе інструменты, якія вам патрэбныя. Запусціце камандны радок з павышанымі правамі і выгрузіце стан платформы; выгрузка трапіць як wfpstate.xml у працоўны каталог.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Шукайце ў XML імя папярэдняга пастаўшчыка, дзеянне Block і ўзровень. Фільтры на перанакіраванні злучэння і транспарце — гэта тыя, што ламаюць звычайны трафік; фільтр на ўзроўні прыёму-прыняцця звычайна не ваша прычына. Калі базавы рухавік фільтрацыі зусім не працуе, шукайце ў іншым месцы, бо нішто іншае не можа прымяніць гэтыя фільтры.

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

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

Чытайце правілы Linux у тым сінтаксісе, якім будзеце выдаляць

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

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Чытайце палітыкі ланцугоў, а не толькі правілы: -P OUTPUT DROP блакуе трафік, нават калі ні адно правіла не адпавядае. Праверце IPv6 асобна, бо кліент, які ўсталёўвае абодва сямействы, можа пакінуць блакаванне IPv6 на месцы пасля знікнення правілаў IPv4, і тады сімптом залежыць ад таго, якое сямейства пераважае праграма. Там, дзе выкарыстоўваецца nftables, запусціце таксама nft list ruleset; два інструменты суіснуюць праз пласт сумяшчальнасці, і адзін спіс не абавязкова паказвае кожнае правіла, якое можа скінуць пакет.

Выдаліце самы вузкі аб’ект, які тлумачыць збой

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Пастаянныя фільтры — апошні сродак. Яны жывуць пад HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, адно значэнне на фільтр з ключом GUID. Спачатку экспартуйце ключ, запішыце GUID, якія выдаляеце, выдаляйце толькі значэнні, што належаць сышоўшаму кліенту, затым перазагрузіцеся, каб рухавік перабудаваў свой стан. Не выдаляйце ўвесь ключ і не адключайце базавы рухавік фільтрацыі: брандмаўэр Windows і Defender залежаць ад яго, і вы абмянялі б адзін збой на горшы.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

У Linux вазьміце радок, які друкуе iptables -S, і заменіце -A на -D. Выдаленне аднаго правіла, якое вы вызначылі, лепш за ачыстку ланцуга, бо яно пакідае вашу ўласную палітыку цэлай.

sudo iptables -D OUTPUT -p udp -j REJECT

Калі скід жыве ў ланцугу, вызначаным карыстальнікам, спачатку выдаліце пераход у гэты ланцуг, а затым прыбярыце ланцуг з дапамогай -X. Усталяванне палітыкі ланцуга ў ACCEPT, пакуль правілы скіду яшчэ на месцы, дапамагае толькі пакетам, якія ўвогуле даходзяць да рашэння палітыкі. Ачыстка ўсіх табліц — апошні сродак: яна таксама выдаляе правілы, якія вы дадалі з іншых прычын, а пры ўключаным ufw пакідае службу ўпэўненай, што валодае ланцугамі, якіх ужо няма.

Знайдзіце ўласніка, які вяртае яго назад

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

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

Правярайце рэальным трафікам, а не адным пінгам

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

Захоўвайце доказы: экспартаваны ключ BFE або вывад iptables -S, зняты да змены. Перш чым назваць гэта выпраўленым, пацвердзіце ўзровень, з якога вы выдалілі аб’ект, уласніка, які мог бы пераўсталяваць яго, стан пасля адной чыстай перазагрузкі і што звычайны агляд працуе без запушчанага VPN-працэсу. Старонка даведкі iptables(8) змяшчае дакладны сінтаксіс выдалення і палітык, калі вы пішаце сцэнар ачысткі.