Ці перажывае аварыйны выключальнік VPN перазагрузку? Як гэта праверыць

Перазагрузка — самы распаўсюджаны спосаб праверыць аварыйны выключальнік, і менавіта гэты тэст часта хлусіць. Сцяжок у кліенце — гэта ўстаноўка; важна тое, ці нешта прымяняе блакаванне паміж момантам, калі сеткавы стек падымаецца, і момантам, калі тунэль сапраўды ўсталяваны. У Windows гэтым нечым звычайна з’яўляецца фільтр у Windows Filtering Platform, у Linux — набор правілаў, які загружае юніт, у macOS — якар pf, у Android — уласныя сцяжкі заўсёды-ўключанага рэжыму і блакавання. Гэтыя канструкцыі паводзяць сябе вельмі па-рознаму пры перазагрузцы, і толькі ўзровень платформы прысутнічае да таго, як хтосьці зможа ўвайсці.

Перазагрузка ставіць тры асобныя пытанні

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

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

Знайдзіце аб’ект, які аднаўляе блакаванне

У Linux правілы netfilter жывуць у ядры. Нішто не запісвае іх назад пры загрузцы, калі вы гэтага не ўладкавалі: iptables-save плюс netfilter-persistent, nftables.service загружае /etc/nftables.conf, або юніт systemd, які запускае ваш уласны скрыпт. Праверце, што ўключана, а не тое, што вы памятаеце, як наладжвалі.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Другая каманда запісвае wfpstate.xml у бягучы каталог. Шукайце фільтры з дзеяннем блакавання, якія ўжо існуюць да таго, як кліент падключыцца. Base Filtering Engine запускаецца рана пры загрузцы і аднаўляе фільтры, дададзеныя з пастаянным сцяжком, таму адны аварыйныя выключальнікі блакуюць трафік да з’яўлення любога акна кліента, а іншыя — не. У macOS sudo pfctl -s info паведамляе, ці ўключаны pf, sudo pfctl -s rules паказвае, што загружана, і VPN-кліенты звычайна далучаюць свае правілы да якара, а не да асноўнага набору правілаў. Правіла, якое называе utun3 можа паказваць на іншы інтэрфейс пасля наступнай загрузкі, бо гэты нумар прызначаецца падчас працы.

Сачыце за прамежкам паміж узняццем сеткі і ўзняццем тунэля

Небяспечны інтэрвал — не ўся перазагрузка, а прамежак. Інтэрфейс атрымлівае лизу і маршрут па змаўчанні ў адзін момант, служба VPN стартуе ў іншы, а тунэль аўтэнтыфікуецца яшчэ пазней, часам толькі пасля ўваходу карыстальніка і запуску агента ўліковых даных. Калі блакаванне прымяняецца апошнім, усё ў прамежку выходзіць у адкрытым выглядзе.

На хастах з systemd чытайце парадак, а не здагадвайцеся. Запусціце systemctl cat на юнітах VPN і міжсеткавага экрана і шукайце After= або Before= адносна network-pre.target і network-online.target. Юніт міжсеткавага экрана, упарадкаваны пасля network-online.target прайграе інтэрфейсу; той, які патрабуе і ўпарадкаваны перад network-pre.target перамагае. У Windows эквівалентныя пытанні — гэта тып запуску службы і яе залежнасці, бо служба, усталяваная на Manual, не можа блакаваць працэс часу загрузкі. Калі ваша патрабаванне ўключае трафік да ўваходу, яго задавальняе толькі ўладкаванне на ўзроўні прылады: тунэль прылады Always On VPN аўтэнтыфікуецца машынным сертыфікатам і падключаецца да таго, як карыстальнік увойдзе, і Microsoft дакументуе канфігурацыю тунэля прылады асобна ад тунэля карыстальніка. Android ідзе іншым шляхам: прымяняе заўсёды-ўключаны VPN і блакуе злучэнні без яго з боку сістэмы, а не працэсу праграмы.

Правядзіце тэст, затым параўнайце два графікі часу

Перазагрузіцеся з прызначэннем, якое нічога не каштуе, калі ўцячэ, і здымайце стан падчас прамежку, а не пасля яго. Самы чысты метад — зонд часу загрузкі: юніт oneshot або запланаваная задача, якая запускаецца як мага раней, запісвае маршрут па змаўчанні і стан міжсеткавага экрана, робіць адзін запыт з кароткім тайм-аўтам і дадае радок у лакальны файл. Параўнайце гэты запіс з часам запуску службы VPN з journalctl -b -u або сістэмнага журнала.

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

Закрыйце прамежак, не адрэзаўшы сабе шлях назад

Калі блакавання няма пры загрузцы, перанясіце прымяненне на ўзровень ніжэй замест дадання другога правіла кліента. Захавайце набор правілаў і загружайце яго з юніта, упарадкаванага да таго, як сетка стане прыдатнай, і пераканайцеся, што гэты юніт не патрабуе DNS-запыту або сеткавага мантавання, якое ён павінен абараняць. Ахоп важны не менш за час: правілы, якія супастаўляюцца па ID карыстальніка або cgroup, пакідаюць кожнага сістэмнага дэмана па-за блакаваннем, а набор правілаў, які апрацоўвае толькі IPv4, пакідае IPv6 і DNS дасягальнымі.

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

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