Kill switch van die app teenoor vuurmuur-kill switch: wat elkeen blokkeer

’n Kill switch op ’n kenmerke-lys sê byna niks oor wat gebeur wanneer die tonnel wegval nie. Een implementering sluit uitgesoekte prosesse, ’n ander installeer pakkietfilters by die bedryfstelsel-grens, en ’n derde probeer bloot weer koppel. Die verskil wys in die sekondes ná ’n fout, nie op die instellingskerm nie. Werk hierdie kontroles in volgorde deur en stop by die eerste een wat jy nie eerlik kan antwoord nie, want dit is waar jou werklike dekking eindig.

Noem eers die afdwingmeganisme

Prosesbeëindiging is ’n toepassing-lewensiklus-kenmerk. Dit vind uitgesoekte programme ná ’n bespeurde tonnelfout en sluit hulle. Enigiets wat nie die hoofproses is nie, oorleef: hulpdienste, agtergrondsinchronisering, en enige toepassing wat ’n sekonde later begin, het elkeen sy eie lewensiklus en tydsberekening.

Pakkietfiltering is ’n bedryfstelsel-kenmerk. Dit weier verkeer wat nie die toegelate pad volg nie, wat ’n sterker belofte is, maar net vir wat die reël werklik pas. Adresfamilie, koppelvlak, uitgeslote toepassings en uitsonderings bepaal dit, nie die etiket in die kliënt nie.

Oorleef die blokkade die kliënt?

Vra vier vrae in hierdie volgorde: wat gebeur by ’n ineenstorting, by ’n handmatige afsluit, by afmelding en by herstart. ’n Reël wat deur die kliënt self onderhou word, word gewoonlik tydens ’n ordentlike afsluit verwyder en dikwels agtergelaat ná ’n ineenstorting. ’n Reël wat in die platformstoor geïnstalleer is, kan omgekeerd optree en beide die kliënt en soms die deïnstallasie oorleef.

Sluit die kliënt in die middel van ’n lang aflaai en kyk of die oordrag vassteek of voortduur.

Soek die standaard gate

IPv6 is die eerste. ’n Reël wat vir IPv4-adresse geskryf is, laat IPv6-verkeer onaangeraak, en baie kliënte skryf net die v4-helfte. Die tweede is die koppelvlak: USB-tethering, ’n tweede Wi-Fi-adapter en ’n sellulêre modem is dalk nie in ’n reël ingesluit wat op die primêre verbinding gemik is nie. Uitgeslote toepassings en plaaslike-netwerk-uitsonderings is die derde.

Op Windows kan jy die geïnstalleerde reëls lees eerder as om die skakelaar te vertrou: Get-NetFirewallRule -DisplayName '*VPN*' en netsh wfp show filters wys albei wat bestaan. Op Linux dek iptables -S, ip6tables -S en nft list ruleset die algemene gevalle, en om al drie te vergelyk is die punt.

DNS is die gewone lek

Om TCP te blokkeer terwyl UDP 53 oopgelaat word, gee jou ’n baie oortuigende kill switch wat steeds elke gasheernaam-navraag beantwoord. Dieselfde geld wanneer DNS aan ’n oplosser op ’n ander koppelvlak gegee word, of wanneer die kliënt net v4 blokkeer en die oplosser oor v6 bereikbaar is.

Met die tonnel af, los een bekende naam op en kyk of ’n antwoord terugkom. As dit wel kom, is verkeer nie volledig geblokkeer nie, maak nie saak wat die statusikoon sê nie.

Toets die oorgang, nie die skakelaar nie

Om die VPN van sy eie kieslys af te skakel, is ’n ordentlike afsluit, en ordentlik is die geval wat elke implementering goed hanteer. Die oorgang wat saak maak, is die onbeskofte een: dood die tonnelproses, trek die netwerk, laat die bediener ophou antwoord. Begin dan ’n versoek en kyk of dit misluk of stilweg die fisiese skakel gebruik.

Die resultaat van een skootrekenaar dra nie oor na ’n foon of ’n roeteerder nie. Verskillende platform-API’s, verskillende verstekke, en op Android is die verskil skerp: always-on met blokkering word deur die stelsel afgedwing eerder as deur die kliënt, so dit hou aan werk wanneer die kliënt dit nie doen nie. Die Android VPN-riglyn beskryf daardie skeiding.

Hou ’n pad terug

Stelselvlak-blokkering het die teenoorgestelde foutmodus. Filters wat die kliënt oorleef, kan ’n masjien heeltemal sonder netwerk laat ná ’n deïnstallasie, wat ’n ondersteuningsoproep met geen duidelike oorsaak is nie. Voordat jy enige kill switch aktiveer wat platformreëls skryf, let op hoe dit verwyder word, en hou die verskaffer se herstelpad waar jy dit kan vind.

As jy nie die ineenstorting-, IPv6-, DNS- en oorgangskontroles vir jou kliënt kan antwoord nie, behandel dit as ’n toepassingvlak-skakelaar met bekende gapings en beplan daarvolgens.