Kill switch en la aplikaĵo kontraŭ kill switch en la fajroŝirmilo: kion ĉiu blokas

Kill switch en lista de funkcioj preskaŭ nenion diras pri tio, kio okazas kiam la tunelo falas. Unu efektivigo fermas elektitajn procezojn, alia instalas pakaĵfiltrilojn ĉe la limo de la operaciumo, kaj tria simple provas rekonekti. La diferenco montriĝas en la sekundoj post fiasko, ne sur la agorda ekrano. Trapasu ĉi tiujn kontrolojn laŭ ordo kaj haltu ĉe la unua, kiun vi ne povas honeste respondi, ĉar tie finiĝas via reala kovrado.

Unue nomu la devigan mekanismon

Proceza finado estas funkcio de la vivociklo de aplikaĵo. Ĝi trovas elektitajn programojn post detektita tunela fiasko kaj fermas ilin. Ĉio, kio ne estas la ĉefa procezo, pluvivas: helpaj servoj, fona sinkronigo kaj ajna aplikaĵo lanĉita sekundon poste havas sian propran vivociklon kaj sian propran tempoĝustigon.

Pakaĵa filtrado estas funkcio de la operaciumo. Ĝi rifuzas trafikon, kiu ne sekvas la permesitan vojon, kio estas pli forta promeso, sed nur en tio, al kio la regulo vere aplikiĝas. Adresfamilio, interfaco, ekskluditaj aplikaĵoj kaj esceptoj decidas tion, ne la etikedo en la kliento.

Ĉu la blokado pluvivas la klienton?

Demandu kvar demandojn en ĉi tiu ordo: kio okazas ĉe kraŝo, ĉe permana eliro, ĉe elsaluto kaj ĉe restartigo. Regulo konservata de la kliento mem kutime foriĝas dum milda malŝalto kaj ofte restas post kraŝo. Regulo instalita en la platforman deponejon povas kondutiĝi inverse: pluvivi kaj la klienton kaj, foje, la malinstalon.

Fermu la klienton meze de longa elŝuto kaj observu, ĉu la transigo haltas aŭ daŭras.

Serĉu la kutimajn truojn

IPv6 estas la unua. Regulo skribita por IPv4-adresoj lasas IPv6-trafikon netuŝita, kaj multaj klientoj skribas nur la duonon v4. La dua estas la interfaco: USB-tethering, dua Wi-Fi-adaptilo kaj poŝtelefona modemo eble ne estas inkluditaj en regulo limigita al la ĉefa konekto. Ekskluditaj aplikaĵoj kaj lokretaj esceptoj estas la tria.

En Windows vi povas legi la instalitajn regulojn anstataŭ fidi la ŝaltilon: Get-NetFirewallRule -DisplayName '*VPN*' kaj netsh wfp show filters ambaŭ montras, kio ekzistas. En Linux iptables -S, ip6tables -S kaj nft list ruleset kovras la kutimajn kazojn, kaj kompari ĉiujn tri estas la senco.

DNS estas la kutima liko

Bloki TCP dum UDP 53 restas malfermita donas al vi tre konvinkan kill switch, kiu ankoraŭ respondas ĉiun gastigantnoman demandon. La samo validas kiam DNS estas transdonita al solvilo sur alia interfaco, aŭ kiam la kliento blokas nur v4 kaj la solvilo atingeblas per v6.

Kun la tunelo malsupre, solvu unu konatan nomon kaj vidu, ĉu respondo revenas. Se ĝi revenas, la trafiko ne estas plene blokita, kion ajn la statussimbolo diras.

Testu la transiron, ne la ŝaltilon

Malŝalti la VPN-on el ĝia propra menuo estas milda malŝalto, kaj la mildan kazon ĉiu efektivigo bone traktas. La transiro, kiu gravas, estas la kruda: mortigu la tunelan procezon, eltiru la reton, lasu la servilon ĉesi respondi. Poste lanĉu peton kaj observu, ĉu ĝi malsukcesas aŭ kviete uzas la fizikan ligon.

Rezulto de unu tekkomputilo ne transiĝas al telefono aŭ enkursigilo. Malsamaj platformaj API-oj, malsamaj defaŭltoj, kaj en Android la diferenco estas kruda: always-on kun blokado estas devigata de la sistemo anstataŭ de la kliento, do ĝi daŭre funkcias kiam la kliento ne faras. La Android-VPN-gvidilo priskribas tiun dividon.

Konservu vojon reen

Blokado je sistema nivelo havas la kontraŭan fiaskmanieron. Filtriloj, kiuj pluvivas la klienton, povas lasi maŝinon tute sen reto post malinstalo, kio estas subtena voko sen evidenta kaŭzo. Antaŭ ol ŝalti ajnan kill switch, kiu skribas platformajn regulojn, notu kiel ĝi foriĝas, kaj tenu la riparvojon de la vendanto tie, kie vi povas trovi ĝin.

Se vi ne povas respondi la kontrolojn pri kraŝo, IPv6, DNS kaj transiro por via kliento, traktu ĝin kiel ŝaltilon je aplikaĵa nivelo kun konataj truoj kaj planu laŭe.