Ĉu VPN-haltigilo postvivas restartigon? Kiel kontroli tion

Restartigo estas la plej ofta maniero per kiu homoj testas haltigilon, kaj ĝi estas la testo, kiu plej ofte mensogas. La markobutono en la kliento estas prefero; gravas ĉu io devigas blokadon inter la momento, kiam la reta stako leviĝas, kaj la momento, kiam la tunelo estas fakte starigita. En Windows tiu io kutime estas filtrilo en Windows Filtering Platform, en Linux regularo ŝarĝita de unuo, en macOS pf-ankro, en Android la propraj flagoj de la sistemo por ĉiam-ŝaltita kaj ŝlosado. Tiuj aranĝoj kondutas tre malsame tra restartigo, kaj nur tiuj ĉe la platforma nivelo estas en loko antaŭ ol iu ajn povas ensaluti.

Restartigo starigas tri apartajn demandojn

Dividu la demandon. Unue, ĉu la politiko ekzistas sur la disko en formo, kiun io legas ĉeŝtarte? Due, ĉu tiu leganto ruliĝas antaŭ ol iu ajn trafiko povas eliri? Trie, ĉu la politiko kovras la trafikon, pri kiu vi zorgas, nome ĉiun procezon, ambaŭ adresajn familiojn kaj DNS. Jes al la unua kaj ne al la dua produktas ĝuste tiun fiaskon, kiun homoj raportas kiel haltigilon, kiu ne postvivas restartigon: trafiko eskapas dum kelkaj sekundoj ĉe lanĉo, kaj neniu rimarkas ĝis iu iras serĉi.

Tenu la tavolojn aparte. Konservita fajroŝirmila regularo, servo, kiu startas ĉeŝtarte, kaj klienta prefero estas tri malsamaj objektoj kun tri malsamaj vivoj. La prefero postvivas restartigojn, ĉar ĝi estas valoro en agorda dosiero. La reguloj estas la sola afero, kiu blokas pakaĵojn, kaj ili malaperas kune kun la kerno, kiu tenis ilin.

Trovu la objekton, kiu restarigas la blokadon

En Linux netfilter-reguloj vivas en la kerno. Nenio reskribas ilin ĉeŝtarte, se vi ne aranĝis tion: iptables-save plus netfilter-persistent, nftables.service ŝarĝas /etc/nftables.conf, aŭ systemd-unuo, kiu rulas vian propran skripton. Kontrolu, kio estas ŝaltita, anstataŭ kion vi memoras esti agordinta.

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

Malplena regularo kelkajn sekundojn post ŝtarto estas la respondo al la demando en la titolo. En Windows demandu la klientan servon, kiel ĝi startas, poste eligu la staton de la platforma filtrilo dum la tunelo estas malsupre.

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

La dua komando skribas wfpstate.xml en la aktualan dosierujon. Serĉu filtrilojn kun blokada ago, kiuj jam ekzistas antaŭ ol la kliento konektiĝas. Base Filtering Engine startas frue ĉeŝtarte kaj restarigas filtrilojn aldonitajn kun la daŭra flago, tial iuj haltigiloj blokas trafikon antaŭ ol ekzistas iu klienta fenestro kaj aliaj ne. En macOS sudo pfctl -s info raportas, ĉu pf estas ŝaltita, sudo pfctl -s rules montras, kio estas ŝarĝita, kaj VPN-klientoj kutime alligas siajn regulojn al ankro anstataŭ al la ĉefa regularo. Regulo, kiu nomas utun3 povas montri al alia interfaco post la sekva ŝtarto, ĉar tiu numero estas atribuata dumrunte.

Observu la breĉon inter reto-leviĝo kaj tunelo-leviĝo

La danĝera intervalo ne estas la tuta restartigo, ĝi estas la breĉo. La interfaco ricevas luon kaj defaŭltan itineron je unu momento, la VPN-servo startas je alia, kaj la tunelo aŭtentikigas eĉ pli malfrue, foje nur post kiam uzanto ensalutas kaj akreditaĵ-agento ruliĝas. Se la blokado aplikiĝas laste, ĉio en la breĉo eliras malkaŝe.

En systemd-gastigantoj legu la ordon anstataŭ diveni ĝin. Rulu systemctl cat sur la VPN- kaj fajroŝirmilaj unuoj kaj serĉu After= aŭ Before= kontraŭ network-pre.target kaj network-online.target. Fajroŝirmila unuo ordigita post network-online.target malvenkas al la interfaco; tiu, kiun postulas kaj kiu estas ordigita antaŭ network-pre.target venkas. En Windows la ekvivalentaj demandoj estas la starta tipo de la servo kaj ĝiaj dependecoj, ĉar servo agordita al Manual ne povas bloki ĉeŝtartan procezon. Se via postulo inkluzivas trafikon antaŭ ensaluto, nur aranĝo ĉe aparata nivelo kontentigas ĝin: aparata tunelo Always On VPN aŭtentikigas per maŝina atestilo kaj konektiĝas antaŭ ol la uzanto ensalutas, kaj Microsoft dokumentas la agordon de la aparata tunelo aparte de la uzanta tunelo. Android prenas la alian vojon, devigante ĉiam-ŝaltitan VPN kaj blokante konektojn sen ĝi de la sistemo anstataŭ de aplikaja procezo.

Rulu la teston, poste komparu du templiniojn

Restartigu kun celo, kiu kostas nenion, se ĝi likas, kaj kaptu la staton dum la breĉo anstataŭ post ĝi. La plej pura metodo estas ĉeŝtarta sondilo: oneshot-unuo aŭ planita tasko, kiu startas kiel eble plej frue laŭ la platformo, registras la defaŭltan itineron kaj la fajroŝirmilan staton, provas unu peton kun mallonga tempolimo kaj aldonas linion al loka dosiero. Komparu tiun registron kun la starta tempo de la VPN-servo el journalctl -b -u aŭ la Sistema protokolo.

Poste rulu la ordinaran teston: tunelo supre, interrompu la konekton, observu, ĉu rekta trafiko estas blokata, restarigu. Trapasi la duan kaj malsukcesi la unuan estas la normala rezulto, kaj ĝi signifas, ke la devigo estas ĉe la klienta flanko, aplikata kiam la kliento konektiĝas anstataŭ ĉeŝtarte. Sur la lasta maŝino, kiun mi aŭditis, la blokado venis de dissendila skripto de NetworkManager: ĉeesta kaj ĝusta kaj senutila por la sekundoj antaŭ ol la interfaco leviĝis. Skribu ambaŭ rezultojn, ĉar postvivi restartigon signifas ion nur kiam vi diras, kiu tavolo postvivis kaj de kiu momento.

Fermu la breĉon sen tranĉi vian reiron

Se la blokado mankas ĉeŝtarte, movu la devigon unu tavolon malsupren anstataŭ aldoni duan klientan regulon. Konservu la regularon kaj ŝarĝu ĝin el unuo ordigita antaŭ ol la reto estas uzebla, kaj certiĝu, ke tiu unuo ne bezonas DNS-serĉon aŭ retan muntaĵon, kiun ĝi supoze protektas. La amplekso gravas same kiel la tempo: reguloj kongruantaj laŭ uzant-ID aŭ cgroup lasas ĉiun sistemdemandon ekster la blokado, kaj regularo, kiu traktas nur IPv4, lasas IPv6 kaj DNS atingeblaj.

Lasu al vi reiron. Maŝino, kiu ĉeŝtarte blokas ĉion kaj poste ne povas aŭtentikigi, tute ne havas reton, kaj la riparo ne estas forigi la blokadon sed ripari la akreditaĵon aŭ la ordon. Tenu dokumentitan proceduron por loka konzolo kaj mallarĝan, intencan escepton por tio, kion la tunelo vere bezonas, ekzemple la servilan adreson kaj la solvilon uzatan antaŭ ol la tunelo ekzistas.

Antaŭ ol fidi la aranĝon, konfirmu kvar aferojn laŭ ordo. La politiko estas konservita ie, kion la ŝtarto legas. Tiu leganto ruliĝas antaŭ ol la interfaco estas uzebla. La blokado kovras ambaŭ adresajn familiojn kaj DNS. La VPN ankoraŭ povas aŭtentikigi dum la blokado estas aktiva. Kiam ĉiuj kvar validas, restartigo ŝanĝas nenion.