Kill switch у апликацији насупрот kill switch-у на фајерволу: шта који блокира

Kill switch на листи функција не говори готово ништа о томе шта се дешава када тунел падне. Једна имплементација затвара одабране процесе, друга инсталира филтере пакета на граници оперативног система, а трећа само покушава поново да се повеже. Разлика се види у секундама после квара, не на екрану подешавања. Прођите ове провере редом и зауставите се на првој на коју не можете искрено да одговорите, јер ту ваша стварна покривеност престаје.

Прво именујте механизам спровођења

Прекид процеса је функција животног циклуса апликације. Проналази одабране програме после откривеног квара тунела и затвара их. Све што није главни процес преживљава: помоћне услуге, позадинска синхронизација и свака апликација покренута секунду касније имају сопствени животни циклус и сопствено време.

Филтрирање пакета је функција оперативног система. Одбија саобраћај који не следи дозвољену путању, што је јаче обећање, али само у оквиру онога што правило заиста покрива. Породица адреса, интерфејс, искључене апликације и изузеци одлучују о томе, а не ознака у клијенту.

Да ли блокада надживљава клијента?

Поставите четири питања овим редом: шта се дешава при паду, при ручном изласку, при одјави и при поновном покретању. Правило које одржава сам клијент обично се уклања током уредног затварања и често остане после пада. Правило инсталирано у складиште платформе може да се понаша обрнуто: да преживи и клијента и, повремено, деинсталацију.

Затворите клијент усред дугог преузимања и гледајте да ли се пренос зауставља или наставља.

Потражите стандардне рупе

IPv6 је прва. Правило написано за IPv4 адресе оставља IPv6 саобраћај нетакнутим, а многи клијенти пишу само v4 половину. Друга је интерфејс: USB tethering, други Wi-Fi адаптер и мобилни модем можда нису укључени у правило ограничено на примарну везу. Искључене апликације и изузеци за локалну мрежу су трећи.

На Windows-у можете читати инсталирана правила уместо да верујете прекидачу: Get-NetFirewallRule -DisplayName '*VPN*' и netsh wfp show filters показују шта постоји. На Linux-у iptables -S, ip6tables -S и nft list ruleset покривају уобичајене случајеве, а поређење сва три је поента.

DNS је уобичајено цурење

Блокирање TCP-а док UDP 53 остаје отворен даје вам веома убедљив kill switch који још увек одговара на сваки упит за име хоста. Исто важи када се DNS преда резолверу на другом интерфејсу или када клијент блокира само v4, а резолвер је доступан преко v6.

Са спуштеним тунелом, разрешите једно познато име и погледајте да ли се одговор враћа. Ако се враћа, саобраћај није потпуно блокиран, шта год икона статуса говорила.

Тестирајте прелаз, не прекидач

Искључивање VPN-а из његовог менија је уредно затварање, а уредан случај свака имплементација добро решава. Прелаз који је важан је груб: убијте процес тунела, извуците мрежу, пустите сервер да престане да одговара. Затим покрените захтев и гледајте да ли не успева или тихо користи физичку везу.

Резултат са једног лаптопа не преноси се на телефон или рутер. Различити API-ји платформе, различите подразумеване вредности, а на Android-у је разлика оштра: always-on са блокирањем спроводи систем, а не клијент, па ради и када клијент не ради. Android VPN смернице описују ту поделу.

Сачувајте пут назад

Блокирање на нивоу система има супротан начин квара. Филтери који преживе клијента могу оставити машину потпуно без мреже после деинсталације, што је позив подршци без очигледног узрока. Пре него што укључите било који kill switch који пише правила платформе, забележите како се уклања, и држите пут поправке од добављача тамо где га можете наћи.

Ако не можете да одговорите на провере пада, IPv6, DNS-а и прелаза за свој клијент, третирајте га као прекидач на нивоу апликације са познатим рупама и планирајте у складу с тим.