Nakalulusot ba ang kill switch ng VPN sa muling pag-boot? Paano ito i-verify

Ang muling pag-boot ang pinakakaraniwang paraan ng pagsubok ng mga tao sa kill switch, at ito ang pagsubok na pinakamadalas magsinungaling. Ang checkbox sa client ay isang kagustuhan lamang; ang mahalaga ay kung may nagpapatupad ng pagharang sa pagitan ng sandaling tumaas ang stack ng network at ng sandaling aktwal na naitatag ang tunnel. Sa Windows ang bagay na iyon ay karaniwang isang filter sa Windows Filtering Platform, sa Linux isang set ng mga patakaran na ina-load ng unit, sa macOS isang angkla ng pf, sa Android ang sariling mga flag ng system para sa lagi-naka-on at pag-lock. Iba-iba ang pag-uugali ng mga kaayusang ito sa isang muling pag-boot, at tanging ang nasa antas ng platform ang nasa lugar bago makapag-sign in ang sinuman.

Tatlong magkakahiwalay na tanong ang itinatanong ng muling pag-boot

Hatiin ang tanong. Una, umiiral ba ang patakaran sa disk sa anyong may nagbabasa nito sa boot? Ikalawa, tumatakbo ba ang mambabasa na iyon bago makalabas ang anumang trapiko? Ikatlo, sinasaklaw ba ng patakaran ang trapikong pinapahalagahan mo, ibig sabihin bawat proseso, parehong pamilya ng address at DNS. Ang oo sa una at hindi sa ikalawa ay lumilikha ng eksaktong kabiguan na iniuulat ng mga tao bilang kill switch na hindi nakalulusot sa muling pag-boot: tumatakas ang trapiko ng ilang segundo sa pagsisimula, at walang nakakapansin hanggang may pumunta at tumingin.

Panatilihing hiwalay ang mga layer. Ang naka-save na set ng mga patakaran ng firewall, serbisyong nagsisimula sa boot at kagustuhan ng client ay tatlong magkaibang bagay na may tatlong magkaibang habang-buhay. Nakalulusot ang kagustuhan sa mga muling pag-boot dahil halaga ito sa isang config file. Ang mga patakaran ang tanging bagay na humaharang sa mga packet, at nawawala sila kasama ng kernel na humawak sa kanila.

Hanapin ang bagay na nagbabalik ng pagharang

Sa Linux, ang mga patakaran ng netfilter ay naninirahan sa kernel. Walang nagsusulat sa kanila pabalik sa boot maliban kung inayos mo ito: iptables-save kasama ang netfilter-persistent, nftables.service naglo-load ng /etc/nftables.conf, o isang unit ng systemd na nagpapatakbo ng sarili mong script. Tingnan kung ano ang naka-enable, hindi kung ano ang natatandaan mong na-configure mo.

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

Ang walang laman na set ng mga patakaran ilang segundo pagkatapos ng boot ang sagot sa tanong sa pamagat. Sa Windows tanungin ang serbisyo ng client kung paano ito nagsisimula, pagkatapos i-dump ang estado ng filter ng platform habang nakababa ang tunnel.

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

Ang ikalawang utos ay nagsusulat ng wfpstate.xml sa kasalukuyang direktoryo. Maghanap ng mga filter na may aksyong pagharang na umiiral na bago kumonekta ang client. Ang Base Filtering Engine ay nagsisimula nang maaga sa boot at nagbabalik ng mga filter na idinagdag gamit ang persistent na flag, kaya't ang ilang kill switch ay humaharang sa trapiko bago pa umiral ang anumang window ng client at ang iba ay hindi. Sa macOS sudo pfctl -s info ay nag-uulat kung naka-enable ang pf, sudo pfctl -s rules ay nagpapakita kung ano ang naka-load, at ang mga client ng VPN ay karaniwang nagkakabit ng kanilang mga patakaran sa isang angkla sa halip na sa pangunahing set. Ang isang patakarang nagbabanggit ng utun3 ay maaaring tumuro sa ibang interface pagkatapos ng susunod na boot, dahil ang numerong iyon ay ibinibigay sa runtime.

Panoorin ang agwat sa pagitan ng pagtaas ng network at pagtaas ng tunnel

Ang mapanganib na agwat ay hindi ang buong muling pag-boot, ito ang agwat. Ang interface ay tumatanggap ng lease at default na ruta sa isang sandali, ang serbisyo ng VPN ay nagsisimula sa iba, at ang tunnel ay nagpapatotoo pa nang mas huli, kung minsan pagkatapos lamang mag-sign in ng user at tumakbo ang ahente ng kredensyal. Kung ang pagharang ay ilalapat sa huli, lahat ng nasa agwat ay lumalabas nang lantad.

Sa mga host ng systemd, basahin ang pagkakasunod-sunod sa halip na hulaan ito. Patakbuhin ang systemctl cat sa mga unit ng VPN at firewall at hanapin ang After= o Before= laban sa network-pre.target at network-online.target. Ang unit ng firewall na inayos pagkatapos ng network-online.target ay natatalo sa interface; ang hinihingi ng at inayos bago ang network-pre.target ay nananalo. Sa Windows ang katumbas na tanong ay ang uri ng pagsisimula ng serbisyo at ang mga dependency nito, dahil ang serbisyong nakatakda sa Manual ay hindi makakaharang ng proseso sa oras ng boot. Kung ang pangangailangan mo ay may kasamang trapiko bago mag-sign in, tanging kaayusan sa antas ng device ang tumutugon dito: ang tunnel ng device na Always On VPN ay nagpapatotoo gamit ang certificate ng machine at kumokonekta bago mag-log in ang user, at idokumento ng Microsoft ang configuration ng tunnel ng device nang hiwalay sa tunnel ng user. Ibang landas ang tinatahak ng Android, ipinapatupad ang VPN na lagi-naka-on at hinaharang ang mga koneksyong wala nito mula sa system at hindi mula sa proseso ng app.

Patakbuhin ang pagsubok, pagkatapos ihambing ang dalawang timeline

Mag-muling pag-boot gamit ang destinasyong walang gastos kung tumagas, at kunin ang estado habang nasa agwat sa halip na pagkatapos. Ang pinakamalinis na paraan ay isang probe sa oras ng boot: isang unit na oneshot o naka-iskedyul na gawain na nagsisimula nang mas maaga hangga't pinapayagan ng platform, nagtatala ng default na ruta at estado ng firewall, sumusubok ng isang kahilingan na may maikling timeout at nagdaragdag ng isang linya sa lokal na file. Ihambing ang talang iyon sa oras ng pagsisimula ng serbisyo ng VPN mula sa journalctl -b -u o sa log ng System.

Pagkatapos patakbuhin ang karaniwang pagsubok: tunnel pataas, putulin ang koneksyon, tingnan kung nahaharang ang direktang trapiko, ibalik. Ang pumasa sa ikalawa at mabigo sa una ang normal na resulta, at nangangahulugan itong ang pagpapatupad ay nasa panig ng client, inilalapat kapag kumokonekta ang client at hindi sa boot. Sa huling machine na na-audit ko, ang pagharang ay nagmula sa isang dispatcher script ng NetworkManager: naroroon at tama at walang silbi para sa mga segundong bago tumaas ang interface. Isulat ang parehong resulta, dahil ang makalulusot sa muling pag-boot ay may kahulugan lamang kapag sinabi mo kung aling layer ang nakalulusot at mula kailan.

Isara ang agwat nang hindi pinputol ang daan pabalik

Kung wala ang pagharang sa boot, ibaba ang pagpapatupad ng isang layer sa halip na magdagdag ng ikalawang patakaran ng client. I-save ang set ng mga patakaran at i-load ito mula sa isang unit na inayos bago maging magagamit ang network, at tiyakin na ang unit na iyon ay hindi nangangailangan ng DNS lookup o network mount na dapat nitong protektahan. Ang saklaw ay kasinghalaga ng oras: ang mga patakarang tumutugma sa user ID o cgroup ay nag-iiwan sa bawat system daemon sa labas ng pagharang, at ang set na humahawak lamang ng IPv4 ay nag-iiwan sa IPv6 at DNS na maabot.

Mag-iwan ng daan pabalik para sa iyong sarili. Ang machine na humaharang sa lahat sa boot at pagkatapos ay hindi makapagpatotoo ay walang network talaga, at ang pagwawasto ay hindi ang pagbura ng pagharang kundi ang pagkumpuni ng kredensyal o ng pagkakasunod-sunod. Panatilihin ang dokumentadong pamamaraan para sa lokal na console at isang makitid, sinadyang pagbubukod para sa tunay na kailangan ng tunnel, tulad ng address ng server at ang resolver na ginagamit bago pa umiral ang tunnel.

Bago ka magtiwala sa kaayusang ito, kumpirmahin ang apat na bagay sa ayos. Ang patakaran ay naka-imbak kung saan ito binabasa ng boot. Tumatakbo ang mambabasang iyon bago maging magagamit ang interface. Sinasaklaw ng pagharang ang parehong pamilya ng address at DNS. Nakakapagpatotoo pa rin ang VPN habang aktibo ang pagharang. Kapag natutugunan ang apat, wala nang binabago ang muling pag-boot.