Kill switch v aplikaciji proti kill switchu v požarnem zidu: kaj blokira vsak

Kill switch na seznamu funkcij ne pove skoraj ničesar o tem, kaj se zgodi, ko tunel pade. Ena izvedba zapre izbrane procese, druga namesti paketne filtre na meji operacijskega sistema, tretja pa preprosto poskuša znova vzpostaviti povezavo. Razlika se pokaže v sekundah po napaki, ne na zaslonu nastavitev. Pojdite skozi te preglede po vrsti in ustavite se pri prvem, na katerega ne morete pošteno odgovoriti, ker tam se konča vaša resnična pokritost.

Najprej poimenujte mehanizem uveljavljanja

Ustavljanje procesov je funkcija življenjskega cikla aplikacije. Po zaznani napaki tunela poišče izbrane programe in jih zapre. Vse, kar ni glavni proces, preživi: pomožne storitve, sinhronizacija v ozadju in vsaka aplikacija, zagnana sekundo pozneje, imajo svoj življenjski cikel in svoj čas.

Filtriranje paketov je funkcija operacijskega sistema. Zavrača promet, ki ne sledi dovoljeni poti, kar je močnejša obljuba, a le toliko, kolikor se pravilo res ujema. Družina naslovov, vmesnik, izključene aplikacije in izjeme odločajo o tem, ne oznaka v odjemalcu.

Ali blokada preživi odjemalca?

Postavite štiri vprašanja v tem vrstnem redu: kaj se zgodi ob sesutju, ob ročnem izhodu, ob odjavi in ob ponovnem zagonu. Pravilo, ki ga vzdržuje odjemalec sam, se ob urejenem zaustavljanju običajno odstrani in pogosto ostane po sesutju. Pravilo, nameščeno v shrambo platforme, se lahko obnaša obratno: preživi odjemalca in včasih tudi odstranitev.

Zaprite odjemalca sredi dolgega prenosa in opazujte, ali se prenos ustavi ali nadaljuje.

Poiščite običajne luknje

IPv6 je prva. Pravilo, napisano za naslove IPv4, pusti promet IPv6 nedotaknjen, in veliko odjemalcev zapiše le polovico v4. Druga je vmesnik: USB tethering, drugi Wi-Fi adapter in mobilni modem morda niso vključeni v pravilo, omejeno na primarno povezavo. Izključene aplikacije in izjeme za lokalno omrežje so tretje.

V sistemu Windows lahko preberete nameščena pravila, namesto da zaupate stikalu: Get-NetFirewallRule -DisplayName '*VPN*' in netsh wfp show filters oba pokažeta, kaj obstaja. V sistemu Linux iptables -S, ip6tables -S in nft list ruleset pokrivajo običajne primere, in primerjava vseh treh je bistvo.

DNS je običajno uhajanje

Blokiranje TCP, medtem ko UDP 53 ostane odprt, vam da zelo prepričljiv kill switch, ki še vedno odgovori na vsako poizvedbo imena gostitelja. Enako velja, ko se DNS preda razreševalniku na drugem vmesniku ali ko odjemalec blokira le v4 in je razreševalnik dosegljiv prek v6.

S spuščenim tunelom razrešite eno znano ime in poglejte, ali se odgovor vrne. Če se vrne, promet ni popolnoma blokiran, kar koli pravi ikona stanja.

Preizkusite prehod, ne stikala

Izklop VPN-a iz njegovega lastnega menija je urejeno zaustavljanje, in urejen primer vsaka izvedba obvlada dobro. Prehod, ki šteje, je grob: ubijte proces tunela, izvlecite omrežje, pustite strežniku, da preneha odgovarjati. Nato začnite zahtevo in opazujte, ali spodleti ali tiho uporabi fizično povezavo.

Rezultat z enega prenosnika se ne prenese na telefon ali usmerjevalnik. Različni API-ji platforme, različne privzete vrednosti, na Androidu pa je razlika očitna: always-on z blokiranjem uveljavlja sistem, ne odjemalec, zato deluje naprej, ko odjemalec ne.Vodnik za VPN v Androidu opisuje to delitev.

Ohranite pot nazaj

Blokiranje na sistemski ravni ima nasproten način odpovedi. Filtri, ki preživijo odjemalca, lahko po odstranitvi pustijo stroj popolnoma brez omrežja, kar je klic v podporo brez očitnega vzroka. Preden omogočite kateri koli kill switch, ki zapisuje pravila platforme, zapišite, kako se odstrani, in imejte pot popravila ponudnika tam, kjer jo lahko najdete.

Če za svojega odjemalca ne morete odgovoriti na preglede sesutja, IPv6, DNS in prehoda, ga obravnavajte kot stikalo na ravni aplikacije z znanimi luknjami in načrtujte v skladu s tem.