Hogyan teszteljünk VPN-kill switch-et valódi fiókok nélkül

Nem kell valódi fiók ahhoz, hogy kiderítse, tart-e a kill switch; pont ezt teszi kockára egy teszt. Az ellenőrzés rövid ablakot teremt, amelyben a forgalom kijuthat vagy nem juthat ki az alagúton, ezért a hasznos teher olyasmi legyen, amit elveszíthet. Most csalipagesszel és tartalék böngészőprofillal csinálom, és tisztább választ ad, mint a korábban használt böngésző-plusz-webmail rutin. A következők ugyanabban a sorrendben haladnak, ahogy az ügyfél bemutatja: a beállítás, a cél, az átmenet, majd a bizonyítékok.

A teszt egyetlen szűk kérdésre válaszol: ebben az átmenetben elérheti-e ez az alkalmazás az alagúton kívüli hálózatot? Semmit sem mond arról, hogy a politika többi része ésszerű-e. Tartsa ilyen szűken a hatókört, és az eredmény megér egy feljegyzést.

Keresse meg a kapcsolót és hatókörét az ügyfélben

Nyissa meg az ügyfelet, és találja meg a blokkolási beállítást, mielőtt bármilyen hálózati állapotot megváltoztat. A szállítók különbözőképpen nevezik: kill switch, zárolási mód, hálózati zár, forgalom blokkolása az alagúton kívül. A címke kevesebbet mond a benne lévő lehetőségeknél. Az számít, hogy a blokkolás mindig érvényes-e, vagy csak amikor az alkalmazás úgy dönt, hogy egy alagút épp most hiúsult meg, és hogy minden alkalmazást vagy egy kiválasztott listát fed-e le.

Ezután listázza azokat az átmeneteket, amelyeket az ügyfél valóban végre tud hajtani. A felhasználó által kezdeményezett bontás, az alkalmazásból való kilépés és a kiszolgálóval való kapcsolat elvesztése három különböző kódútvonal a legtöbb ügyfélben, és nem osztoznak egyetlen blokkolási szabályon sem. Egyesek kilépéskor elengedik a blokkolást. Mások telepítve hagyják a szűrőszabályokat, amíg valami el nem távolítja őket. Olvassa el a szállító beállítási referenciáját az Ön által futtatott buildhez a feltételezés helyett, majd írja le, melyiket teszteli a háromból.

A profilt is jegyezze fel: protokoll, címcsaládok, és hogy engedélyezett-e az osztott alagút. Az egész eszközre vonatkozó állítás értelmetlen, ha a profil szándékosan kizár néhány alkalmazást, és az Ön által beállított kizárás nem szivárgás. Az OpenVPN Connect beállítási referenciája olyan oldal, amely megnevezi, melyik kapcsoló melyik viselkedést változtatja meg, bár a feliratok ügyfelenként eltérnek.

Válasszon csalicélt, amely alagút nélkül is működik

A csalinak két tulajdonsága kell legyen, és bármelyik kihagyása olvashatatlan eredményt ad. Közvetlenül elérhetőnek kell lennie, amikor az alagút le van állítva és a blokkolás ki van kapcsolva, különben „abbahagyta a válaszadást” egyszerűen azt is jelentheti, hogy a gazdagép eltűnt. És nem igényelhet bejelentkezést, sütit vagy fizetést, hogy egy szivárgás egy naplósorba, ne egy munkamenetbe kerüljön.

Az Ön által vezérelt gazdagépen lévő statikus oldal a tiszta választás. Egy tartalék virtuális gép egyszerű HTTP-kiszolgálóval majdnem ugyanolyan jó, és egy nyilvános kapcsolatellenőrző oldal is működik, ha elfogadja, hogy elérhetősége az Ön ellenőrzésén kívül esik. Jegyezze fel a címet, a portot, a címcsaládot és azt, hogy a kérés igényel-e névfeloldást, mert ezek mindegyike olyan változóvá válik, amelyet később esetleg elkülönítenie kell.

A kapcsoló megérintése előtt állítsa fel az alapvonalat. Ha az alagút fel van, a csalinak az alagúton keresztül kell válaszolnia, ami bizonyítja, hogy a házirend útvonala működik. Ha az alagút le van és a blokkolás ki van kapcsolva, közvetlenül kell válaszolnia, ami bizonyítja, hogy a cél él. Csak ezután mond valamit a blokkolt állapotban bekövetkező hiba.

Hajtsa végre az átmeneteket rögzített sorrendben

Vegye egyenként az átmeneteket, és adjon mindegyiknek néhány másodpercet a beállásra, mert az ügyfelek gyakran lebontják és újraépítik a szabályokat ebben a résben. Ugyanazon rövid ellenőrzés minden alkalommal történő futtatása összehasonlíthatóvá teszi a megfigyeléseket:

curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"

Az alkalmazásból való kilépés sora saját futtatást érdemel, akkor is, ha normál használatban soha nem zárja be az ügyfelet. Ha a blokkolás kilépéskor felszabadul, egy összeomlás vagy kényszerített frissítés ugyanazt a kitettséget adja, és ez a telepítésről szóló tény, nem a türelméről. Windows alatt a megfelelő próbák: Resolve-DnsName decoy.example és curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Különítse el a blokkolást a hibás feloldótól

A be nem töltődő oldalnak több oka lehet, és csak az egyik a működő kapcsoló. Ha a név nem oldódik fel, megtanulta, hogy a DNS blokkolt vagy hibás, nem azt, hogy az adatút blokkolt. Próbáljon ki egy szó szerinti címet is, hogy a válasz egyáltalán ne függjön a feloldástól.

A curl kilépési kódjai elválasztják ezeket az eseteket: a 6 névfeloldási hiba, a 7 azt jelenti, hogy a kapcsolatot elutasították, a 28 időtúllépés. A blokkolt útvonal általában időtúllépésként vagy elutasításként jelenik meg egy szó szerinti címmel szemben. A csak DNS-t érintő blokkolás 6-ot hagy és minden mást elrejt. A gyorsítótárazott oldal vagy egy elfogó portál megtéveszti a szemet, ezért a bizonyíték a kilépési kód, nem a képernyő.

Ismételje meg a próbát IPv6 felett szó szerinti címmel. Az IPv4-et lefedő és az IPv6-ot figyelmen kívül hagyó blokkolás elég gyakori ahhoz, hogy saját sort érdemeljen a jegyzeteiben, és az az ügyfél, amely az alagúton kívül letiltja az IPv6-ot, mindkét családon tisztán hibázik.

Jegyezze fel a hatókört, amelyet az eredmény lefed

Amikor az alagút visszatér, erősítse meg a helyreállást: a csali az alagúton keresztül válaszol, a feloldó válaszokat ad, és a házirend ott marad, ahol hagyta. Ezután vonja vissza a kísérleteket. A helyben hagyott ideiglenes tűzfalszabály, hibakereső útvonal vagy tesztprofil összezavarja a következő futást, és túlélheti az alkalmazást.

Egyetlen menet lefed egy ügyfél-buildet, egy profilt, egy átmenetet és egy címcsaládot. Jegyezze fel ezt a négyet az eredménnyel együtt:

• Az ügyfél buildje és a platform, valamint hogy a beállítás profilonkénti vagy globális.
• Profil, protokoll és az osztott alagút bármilyen kizárása.
• A tesztelt átmenet, és hogyan indította el.
• Címcsaládok és DNS, a curl kilépési kódjaival a blokkolt és a nem blokkolt állapotra.

Ha bármelyik sor üres, a teszt nem fejeződött be. A barangolás a hálózatváltás sorának megismétlését jelenti. A felügyelet nélküli újraindítás azt jelenti, hogy ellenőrizze, visszatérnek-e a szabályok, ami a helyreállítás sorrendjéről szóló kérdés, nem a kapcsolóról. Ismételje meg a sorozatot egy ügyfélfrissítés után, mert a kapcsolók ritkán változnak, miközben a mögöttük lévő viselkedés igen. Tartsa kéznél a csalit: nincs mit forgatni, és a következő ellenőrzés öt percig tart.