Két VPN-alkalmazás egyszerre: melyik kill switch érvényes valójában?
Egy második VPN-kliens soha nem örökli az első kill switchét. Három feltétel dönti el, melyik szabály érvényes, és hogyan ellenőrizheti a sajátját.
Két VPN-kliens futhat egymás mellett, de a kill switch-eik nem olvadnak egyetlen szabályba. Mindegyik kliens a saját alagútjához telepít szabályokat, és egyik sem tud a másik létezéséről. Én egy munkaklienssel futottam bele, amely elsőként kapcsolódott: a második alkalmazás nem tudta befejezni a kézfogást, tíz percig „Connecting” állapotban ült, az első alagút pedig csendben mindent vitt. Hogy a második alkalmazás védelmet kap-e, három feltételen múlik, nem azon, hogy mindkét ikon azt írja: Csatlakozva.
Mihez van valójában kötve egy kill switch
Az operációs rendszerben nincs egyetlen kill switch-kapcsoló. Egy kliens, amely ilyet hirdet, szabálykészletet telepít: dobjon el mindent, ami nem az én alagutamon keresztül megy ki, és gyakran fail closed, amikor az alagút eltűnik. Linuxon ez általában nftables- vagy iptables-lánc, Windowson Windows Filtering Platform-szűrők sora, Androidon és iOS-en az alagútszolgáltatás saját útválasztása plusz a rendszerbeállítás, amely blokkolja a VPN nélküli kapcsolatokat. Az Android VPN-útmutató leírja ezt a szolgáltatásmodellt, ha a platform nézőpontjára kíváncsi.
A hatókör az a rész, amely számít. Egy olyan szabály, hogy „csak a wg0 kimeneti interfészen engedj csomagokat”, nem törődik azzal, létezik-e második alagút. Ha egy másik kliens felhozza a wg1-et, az első kliens szabályai ezeket a csomagokat közönséges forgalomként kezelik: többnyire eldobják, néha engedélyezik. Akárhogy is, az első kliens dönt, és fogalma sincs arról, hogy egy második alkalmazás vár.
Három feltétel, amely eldönti, kit fed le a védelem
Nem kell minden kombinációt felsorolnia. Három kérdés eldönti néhány perc alatt.
- Enged egyáltalán a platform második alagutat? A legtöbb Android-telefon és iPhone felhasználói profilonként csak egy aktív VPN-szolgáltatást fogad el, így a második alkalmazásnak soha nincs alagútja, és soha nem kényszerít ki semmit. Egyetlen szabályt kap – attól az alkalmazástól, amely megnyerte a helyet.
- Melyik folyamat birtokolja az alapértelmezett útvonalat? Windows, macOS és Linux gond nélkül elbír két alagutat. Az alapértelmezett útvonal azé a kliensé, amelyik utoljára vagy jobb metrikával állította be, a másik kliens pedig csatlakozva van, de tétlen. Linuxon a wg-quick alapértelmezett útvonal módja házirend-alapú útválasztást használ privát táblával és fwmark-szabállyal, így egy második wg-quick-alagút versengő szabályt ad hozzá, ahelyett hogy lecserélné az elsőt.
- Eléri a második kliens a saját szerverét? Ha az első kill switch alapértelmezés szerint tilt, a második alkalmazás külső végpontja csak egy újabb eldobott cél. Csendben újrapróbálkozik, és soha nem jelent hibát.
A rövid változat, támogatási szálakhoz:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Ezek közül két sor azonosnak látszik a tálcán lévő ikonról, és éppen ezért itt az ikon a legrosszabb rendelkezésre álló bizonyíték.
Mi hibázik először, és hogyan néz ki
Egy kliens, amely „Connecting” állapotban akad, miközben a másik egészséges, szinte mindig végpontéhség: a futó kill switch eldobja a második kliens kézfogását a saját szerveréhez. Olcsón megerősítheti, ha egy próbára szünetelteti az első kliens blokkoló szabályait. Ha a második azonnal csatlakozik, a kérdés megválaszolva.
A DNS a második hiba. A kliensek a saját interfészükhöz állítják be a feloldó konfigurációját, és néhányan egyszerűen felülírják a globális feloldólistát. Mindkét alagúttal a lekérdezések az egyik oldalon mehetnek ki, miközben a feloldó a másikhoz tartozik. Bontsa a kapcsolatot bármelyik alkalmazással, és a túlélő elérhetetlen névszervert tart meg: az oldalak egy percig akadnak, majd újra feloldódnak, miközben a VPN továbbra is csatlakozottnak látszik.
A harmadik az útvonal-flapping. Az újracsatlakozások átrendezik az alapértelmezett útvonalat, és az interfészhez kötött kill switch nem követi. A forgalom, amely egy pillanattal korábban az alagútban volt, most egy eldobási szabályra illeszkedik, ami a felhasználó oldalán úgy olvasható, hogy a VPN véletlenszerűen abbahagyja a működést.
Ellenőrizze, melyik szabály van ténylegesen érvényben
Ártalmatlan forgalommal tegye ezt, ne olyasmivel, amit hiányolna.
Linuxon kérdezze meg a kernelt, ki nyer, és mihez kötődik a tűzfal. ip -4 route show default megnevezi az alagutat, amely a kimenetet birtokolja. ip rule show megmutatja, játékban van-e a házirend-alapú útválasztás. sudo nft list ruleset | grep -n oifname megmutatja, hogy az eldobások interfésznévhez, jelöléshez vagy a teljes kimeneti lánchoz kötődnek-e.
Windowson ugyanez a történet az útvonalmetrikában és a szűrőlistában él: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric és Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS-en netstat -rn -f inet | head -5 és scutil --dns | head -20.
Aztán tegye meg a lépést, amelyet az emberek kihagynak: állítsa le szándékosan az alagutat, és erősítse meg, hogy a forgalom, amelynek hibáznia kell, valóban hibázik. A csatlakozott ikon felületi állapot, nem kikényszerítés.
Mikor rossz tervezés két kliens
Ha a második alkalmazás mögött az egyetlen követelmény a nagyobb védelem, távolítsa el. Két egymásra ható blokkoló szabály kevésbé kiszámítható, mint egy, és minden újracsatlakozás esély arra, hogy olyan állapotba kerüljön, amelyet egyetlen gyártó sem tesztel.
Ha valóban láncolásra van szüksége, például egy kereskedelmi ugráson át elért vállalati átjáróra, olyan tervezést válasszon, amelynek egyetlen kikényszerítési pontja van. Ez általában routert vagy egyetlen, a láncot támogató klienst jelent, nem két asztali alkalmazást, amely ugyanazért az alapértelmezett útvonalért verseng. Kezelt eszközön tartsa meg az engedélyezett klienst, és minden mást tekintsen hatókörön kívülinek, bármit is mutat a tálcán.
Ellenőrzőlista, mielőtt mindkettőt megtartja
Haladjon végig a listán sorrendben; az első hibázó pont az, amelyet javítani kell.
- Erősítse meg, hogy pontosan egy kliens birtokolja az alapértelmezett útvonalat és a feloldót.
- Ha a második kliens is fent legyen, engedélyezze kifejezetten a szerver végpontját, és minden kliensfrissítés után ellenőrizze újra.
- Írja le a várt eredményt, amikor valamelyik alagút leesik, és tesztelje pontosan azt az esetet.
- Ellenőrizze a hibaútvonalat újraindítás után, amikor az indítási sorrend más.
- Kezelt profilon álljon meg, és kérdezze meg a tulajdonost, mielőtt bármit hozzáad.
Ha a harmadik lépés hibázik, az őszinte válasz az, hogy csak egy kliens ad Önnek szabályt. Döntse el, melyikben bízik, és engedje el a másikat.