Lietotnes kill switch pret ugunsmūra kill switch: ko bloķē katrs
Viens kill switch aizver lietotnes, otrs uzstāda pakešu filtrus. Iziet šīs pārbaudes secīgi un apstājieties pie pirmās, uz kuru nevarat atbildēt godīgi.
Funkciju sarakstā esošais kill switch gandrīz neko nepasaka par to, kas notiek, kad tunelis nokrīt. Viena implementācija aizver atlasītus procesus, cita uzstāda pakešu filtrus operētājsistēmas robežā, bet trešā vienkārši mēģina atkārtoti savienoties. Atšķirība parādās sekundēs pēc kļūmes, nevis iestatījumu ekrānā. Iziet šīs pārbaudes secīgi un apstājieties pie pirmās, uz kuru nevarat atbildēt godīgi, jo tur beidzas jūsu reālā aptvere.
Vispirms nosauciet izpildes mehānismu
Procesu pārtraukšana ir lietotnes dzīves cikla funkcija. Tā pēc konstatētas tuneļa kļūmes atrod atlasītās programmas un aizver tās. Viss, kas nav galvenais process, izdzīvo: palīgpakalpojumi, fona sinhronizācija un jebkura lietotne, kas palaista sekundi vēlāk, visiem ir savs dzīves cikls un savs laiks.
Pakešu filtrēšana ir operētājsistēmas funkcija. Tā atsaka trafiku, kas neiet atļauto ceļu, kas ir spēcīgāks solījums, bet tikai tiktāl, ciktāl noteikums patiešām atbilst. Adrešu saime, saskarne, izslēgtās lietotnes un izņēmumi to izlemj, nevis klienta etiķete.
Vai bloķēšana pārdzīvo klientu?
Uzdodiet četrus jautājumus šādā secībā: kas notiek avārijas laikā, manuāli izejot, izrakstoties un restartējot. Noteikums, ko uztur pats klients, parasti tiek noņemts kārtīgas izslēgšanas laikā un bieži paliek pēc avārijas. Platformas krātuvē instalētais noteikums var uzvesties pretēji: pārdzīvot gan klientu, gan dažkārt arī atinstalēšanu.
Aizveriet klientu ilgas lejupielādes vidū un vērojiet, vai pārsūtīšana apstājas vai turpinās.
Meklējiet ierastās spraugas
IPv6 ir pirmā. Noteikums, kas rakstīts IPv4 adresēm, atstāj IPv6 trafiku neskartu, un daudzi klienti raksta tikai v4 pusi. Otrā ir saskarne: USB tethering, otrs Wi-Fi adapteris un mobilo sakaru modems var nebūt iekļauti noteikumā, kas ierobežots ar primāro savienojumu. Izslēgtās lietotnes un vietējā tīkla izņēmumi ir trešā.
Windows varat lasīt instalētos noteikumus, nevis uzticēties slēdžim: Get-NetFirewallRule -DisplayName '*VPN*' un netsh wfp show filters abi parāda, kas pastāv. Linux iptables -S, ip6tables -S un nft list ruleset aptver ierastos gadījumus, un visu trīs salīdzināšana ir būtība.
DNS ir ierastā noplūde
TCP bloķēšana, kamēr UDP 53 paliek atvērts, dod ļoti pārliecinošu kill switch, kas joprojām atbild uz katru resursdatora vārda vaicājumu. Tas pats attiecas, ja DNS tiek nodots citas saskarnes atrisinātājam vai ja klients bloķē tikai v4 un atrisinātājs ir sasniedzams caur v6.
Kad tunelis ir nolaists, atrisiniet vienu zināmu vārdu un skatiet, vai atbilde nāk atpakaļ. Ja nāk, trafiks nav pilnībā bloķēts, lai ko teiktu statusa ikona.
Pārbaudiet pāreju, nevis slēdzi
VPN izslēgšana no tās pašas izvēlnes ir kārtīga izslēgšanās, un kārtīgo gadījumu katra implementācija apstrādā labi. Svarīgā pāreja ir rupjā: nogaliniet tuneļa procesu, izraujiet tīklu, ļaujiet serverim pārstāt atbildēt. Tad sāciet pieprasījumu un vērojiet, vai tas neizdodas vai klusi izmanto fizisko saiti.
Viena portatīvā datora rezultāts neattiecas uz tālruni vai maršrutētāju. Dažādas platformas API, dažādas noklusējuma vērtības, un Android atšķirība ir krasa: always-on ar bloķēšanu īsteno sistēma, nevis klients, tāpēc tas turpina darboties, kad klients to nedara. Android VPN pamācība apraksta šo sadalījumu.
Paturiet atgriešanās ceļu
Sistēmas līmeņa bloķēšanai ir pretējs kļūmes režīms. Filtri, kas pārdzīvo klientu, pēc atinstalēšanas var atstāt datoru pilnīgi bez tīkla, un tas ir atbalsta zvans bez acīmredzama iemesla. Pirms iespējojat jebkuru kill switch, kas raksta platformas noteikumus, pierakstiet, kā tas tiek noņemts, un turiet piegādātāja labošanas ceļu tur, kur varat to atrast.
Ja nevarat atbildēt uz sava klienta avārijas, IPv6, DNS un pārejas pārbaudēm, uzskatiet to par lietotnes līmeņa slēdzi ar zināmām spraugām un plānojiet atbilstoši.