Útmutatók
A kill switch abban a pillanatban blokkolja a teljes internetforgalmat, amint a VPN-alagút megszakad, így az alkalmazások nem válthatnak észrevétlenül vissza a normál kapcsolatodra. Nélküle már egy kétmásodperces kapcsolatvesztés is felfedi a valódi IP-címedet. A DNS-kérések, a böngésző WebRTC-je és az IPv6-forgalom pedig akkor is kiszivároghat az alagút mellett, amíg az fennáll. Minden szivárgásra van egy egyszerű teszt és egy megoldás.
Amikor a VPN-kapcsolat megszakad, az operációs rendszer csendben a normál hálózati interfészen át irányítja a forgalmat. Az alkalmazások tovább működnek, és semmi sem figyelmeztet. A kill switch a nyitott hibaállapotból zárt hibaállapotot csinál: ha nincs alagút, nincs forgalom.
A DNS-lekérdezések az alagúton kívül, az internetszolgáltatód feloldójához mehetnek, a WebRTC kiadhatja a címeidet a weboldalaknak, az IPv6 pedig megkerülheti a csak IPv4-es alagutat — mindez úgy, hogy a VPN ikonja közben azt mutatja: csatlakozva.
Nem kell a beállítási képernyőkben bíznod. A szivárgásteszt megmutatja, milyen címeket és feloldókat látnak valójában a weboldalak, az alagút szándékos megszakításával pedig kiderül, hogy a kill switch tényleg tart-e.
A kapcsolat nyitva marad. A VPN olyan útvonalakat ad hozzá, amelyek a forgalmat egy virtuális hálózati interfészbe terelik. Amikor az alagút folyamata leáll vagy időtúllépés miatt megszakad, ezek az útvonalak eltűnnek, a Wi-Fi-n vagy Etherneten át vezető alapértelmezett útvonal viszont megmarad — így a rendszer tovább kézbesíti a csomagokat, immár közvetlenül az internetszolgáltatódon keresztül. Az alkalmazások másodperceken belül újra felépítik a kapcsolataikat, és a valódi IP-címedről küldenek forgalmat, mindenféle hibaüzenet nélkül.
A megszakadás mindennapos dolog. A Wi-Fi-ről mobiladatra váltás, az alvásból ébredő laptop, egy megbízhatatlan szállodai hálózat vagy a VPN-szerver újraindulása mind egy pillanatra megszakítja az alagutat. Hogy ez a pillanat mibe kerül, azon múlik, elhagyhat-e bármi az eszközödet, amíg az alagút nem működik.
A kill switch nem varázslat, hanem tűzfalszabályok halmaza. A szigorú változat csak kétféle kimenő forgalmat enged át: az alagút interfészébe belépő csomagokat, valamint a VPN-kliens saját, titkosított csomagjait a szerver felé. Ha az alagút leáll, az alkalmazások forgalmának egyszerűen nincs hová mennie, amíg az vissza nem tér.
Ez nem a hibákat előzi meg, hanem a hibamódot változtatja meg. Kill switch-csel a megszakadás egy szünetelő kapcsolat, amit észreveszel; nélküle pedig a valódi címedről menő forgalom, amit nem veszel észre. A hálózatok tökéletlenek, az alagút így is meg fog szakadni — a zárt hibaállapot ezeket a pillanatokat teszi ártalmatlanná.
A különbség az, hogy mi történik, ha maga az alkalmazás leáll. Az alkalmazáson belüli kill switch a VPN-kliens kódjának része: figyeli az alagutat, és blokkolja a forgalmat, ha az megszakad. Csak addig működik, amíg a kliens fut: ha a kliens összeomlik, vagy egy akkumulátor-optimalizáló leállítja, a védelem is vele együtt szűnik meg — pontosan abban a pillanatban, amikor az alagút eltűnik.
A rendszerszintű kill switch az operációs rendszer saját tűzfalába telepít szabályokat, amely minden kimenő csomagot megvizsgál, függetlenül attól, hogy mely alkalmazások futnak. Az Androidban ez be van építve: a Mindig bekapcsolt VPN és a VPN nélküli kapcsolatok blokkolása együtt azt eredményezi, hogy maga az operációs rendszer utasítja el az alagúton kívüli forgalmat, még újraindítás után, az alkalmazás elindulása előtt is. A legegyszerűbb módja annak, hogy a kettőt megkülönböztesd: böngészés közben kényszerítve zárd be a VPN-alkalmazást — ha az oldalak továbbra is betöltenek, a kapcsoló az alkalmazásban él.
A DNS-szivárgás azt jelenti, hogy a névfeloldási kéréseid a helyi hálózat által kiosztott feloldóhoz — általában az internetszolgáltatódéhoz — mennek, miközben maga a forgalom az alagúton halad. A weboldalak a VPN címét látják, a feloldó viszont minden megnyitott oldal nevét megkapja, ami gyakorlatilag egy böngészési napló. A Windows a klasszikus elkövető: több aktív interfész esetén mindet párhuzamosan lekérdezheti, és azt használja, amelyik előbb válaszol.
A megoldás két részből áll, és egy jó kliens mindkettőt elvégzi: a rendszert az alagúton belüli feloldóra irányítja, és minden más interfészen blokkolja a DNS-t, hogy az elkóborló kéréseknek ne legyen hová menniük. Aztán ellenőrizd: futtass szivárgástesztet, és nézd meg a felsorolt feloldókat — ha bármelyik az internetszolgáltatódé, a lekérdezések szivárognak.
A WebRTC a videohívások mögött álló böngészőtechnológia, és bármely weboldal meghívhatja néhány sornyi JavaScripttel. A közvetlen kapcsolatok felépítéséhez összegyűjt minden címet, amelyen a géped elérhető lehet: a helyi címeket és — egy STUN-szerver megkérdezésével — a nyilvánosat is. Egy oldal a közreműködésed nélkül kiolvashatja ezeket a jelölteket.
Teljes eszközre kiterjedő alagút esetén a STUN-kérés az alagúton belül halad, így a VPN címét találja meg. A részleges beállítások a veszélyesek: egy csak böngészőre szóló proxy vagy az olyan osztott alagutazás, amely a böngészőt kívül hagyja — ilyenkor a WebRTC UDP-csomagjai közvetlenül mennek ki, és felfedik a valódi IP-címedet.
Ne találgass, inkább teszteld: az ingyenes ellenőrzőnk a /webrtc-leak-test/ címen megmutatja, milyen címeket ad ki most a böngésződ. Ha a valódi is megjelenik, válts teljes eszközre kiterjedő alagútra, vagy tiltsd le a WebRTC-t a böngésző beállításaiban.
Sok VPN-konfiguráció csak IPv4-forgalmat visz át. Ha a szolgáltatód IPv6-ot is ad — a legtöbb mobilhálózat igen —, a rendszer az alagúton kívül is fenntart egy működő IPv6-útvonalat, és a modern rendszerek az IPv6-ot részesítik előnyben, ha egy oldal mindkettőt kínálja. Az eredmény részleges kitettség: az IPv6 nélküli oldalak a VPN címét látják, az IPv6-ot támogatók a valódi címedet, egy csak IPv4-es teszt pedig azt jelenti, hogy minden rendben.
Két tiszta megoldás létezik. A jobbik egy olyan VPN, amely megfelelően kezeli az IPv6-ot — az IPv4 mellett azt is az alagútba tereli, vagy egy blokkoló útvonalat állít be, hogy az IPv6-csomagok eldobódjanak, ne pedig közvetlenül kimenjenek. A durvább tartalék megoldás az IPv6 kikapcsolása az eszközön vagy a routeren. Bármelyiket is választod, ellenőrizd: a szivárgásteszt nem mutathat olyan IPv6-címet, amely nem a VPN-é.
Az ellenőrzéseket ott végezd el, ahol ténylegesen használod a VPN-t — otthoni Wi-Fi-n, mobilneten a telefonon, egy kávézó hálózatán —, mert a szivárgás az adott hálózat DNS-beállításaitól és az IPv6 elérhetőségétől függ. A rutin nagyjából öt percet vesz igénybe:
Ha a VPN-alagutat a routerre teszed, egyszerre védi a hálózat összes eszközét — a tévéket, konzolokat és okoshangszórókat is, amelyekre nem lehet appot telepíteni. A kompromisszumok viszont valósak: a sávszélességet a router processzora korlátozza, az egész háztartás egyetlen országon keresztül lép ki az internetre, a hibakeresés pedig nehezebbé válik. Ez az útmutató bemutatja a lehetséges beállításokat, és segít eldönteni, melyik való neked.
Úton a VPN titkosítja a forgalmadat a szállodai és reptéri Wi-Fi-n, a fiókjaid számára úgy tűnik, mintha egy megszokott országból csatlakoznál, és eléred azokat a szolgáltatásokat is, amelyek külföldön másképp viselkednek. Nem csodaszer: a streamingplatformok felismerik a szerverek címeit, és a helyi szabályok országonként eltérnek. Az egyetlen igazán fontos szabály — állíts be és tesztelj mindent, mielőtt elindulsz.
A VPN (virtuális magánhálózat) titkosított alagutat épít az eszközöd és egy távoli szerver között, a forgalmad pedig erről a szerverről lép ki az internetre. Az internetszolgáltatód nem látja többé, milyen oldalakat látogatsz, a weboldalak pedig a sajátod helyett a szerver IP-címét látják. Ez egy adatvédelmi eszköz, nem láthatatlanná tévő köpeny.
14 napos pénzvisszafizetési garancia. Akár 7 eszköz egy előfizetéssel.
Védem az eszközeimet