Két VPN egy telefonon: a felállást válassza, ne az alkalmazások számát

Két VPN használata nem egyetlen kérés. Jelentheti két szervezet egymás utáni elérését, a munkahelyi és személyes alkalmazások külön tartását, vagy az egyik alagút futtatását a másikban. Az Android ezt a három esetet teljesen eltérő módon kezeli, és a telefonra telepített VPN-alkalmazások száma nem az architektúra. Az őket elválasztó kérdés egyszerű: kell-e két útvonalnak ugyanabban a pillanatban léteznie ugyanahhoz az alkalmazáshoz?

Három felállás, egy kérdés

Ha a válasz nem, mert a két hálózatot különböző időpontokban használják, szándékos váltásra van szüksége. Ha a válasz nem, mert maguk az alkalmazások különülnek el, profilok szétválasztására van szüksége, ahol minden alkalmazás abban a kontextusban ül, amely az alagútja tulajdonosa. Ha a válasz igen, és az egyik útvonalnak fizikailag kell hordoznia a másikat, láncra van szüksége, és ez az egyetlen a három közül, ahol a sorrend a felépítés része.

Minden más ebből a választásból következik. A váltásnak átmeneti ablaka van, a szétválasztásnak szabályzati határa, a láncnak pedig többletköltsége és függőségi költsége. A rossz választása nem hibázik tisztán; olyan telefont eredményez, amely csatlakozottnak látszik, és egy alkalmazást, amely semmit sem ér el.

Váltás egyetlen felhasználói kontextuson belül

Az Android felhasználónként egy aktív VPN-szolgáltatást engedélyez. Egy második VPN-alkalmazás indítása ugyanabban a kontextusban lecseréli az elsőt, vagy egyenesen elutasítják; soha nem fűzi össze a két útvonalkészletet, és biztosan nem rétegzi egymásra a titkosításukat. Egy felhasználón belül két alagút sorrend, nem összeg.

Ez akkor működik, ha a hozzáférés valóban egymás utáni. Nevezze el a profilokat, hogy az aktív nyilvánvaló legyen, fejezzen be minden érzékenyet a váltás előtt, és számítson egy rövid ablakra, amelyben egyik útvonal sincs teljesen kiépítve. Egy böngészőlap bezárása nem ugyanaz, mint egy munkamenet befejezése: a lap megtarthatja a fiókja állapotát, és egyszerűen elküldheti a következő kérést az újonnan választott hálózaton, és pontosan ez az a szivárgás, amelyet az emberek utólag észrevesznek.

Amit a váltás nem adhat meg, az egy olyan gép, amely egyszerre mindkét hálózaton van. Ha egy alkalmazásnak mindkét oldalról magáncím kell, azt semmilyen ügyfélfegyelem nem állítja elő.

Szétválasztás profil szerint

Egy kezelt munkahelyi profil külön felhasználó a saját alkalmazásaival, kulcstárával és hálózati szabályzatával. Egy munkahelyi levelezőprogram használhatja a szervezet alagútját, miközben egy személyes böngésző személyeset használ, és mindkettő csatlakozhat egyszerre, mert nem ugyanabban a kontextusban versengenek a helyért.

A szétválasztás egyben a határ is. A személyes böngésző nem kölcsönzi a munkahelyi alagutat, nem látja a munkahelyi DNS-utótagokat, és nem éri el a munkahelyi hálózatot csak azért, mert mindkét szolgáltatás csatlakozottként jelenik meg. Amikor valaki jelzi, hogy egy hivatkozás nem nyílik meg, ellenőrizze, az alkalmazás melyik példánya kezelte, és melyik profil birtokolja azt a fiókot, mielőtt bármelyik VPN-hez nyúlna.

Tekintse a határt rögzítettnek. Egy második profil létrehozása vagy egy munkahelyi profil eltávolítása, hogy megkerülje a munkáltató útvonalválasztási döntését, éppen azt a szétválasztást rombolja le, amely a felállást működőképessé tette, és kezelt eszközön ez általában szabályzatsértés, nem konfigurációs módosítás.

Lánc, ahol a sorrend a felépítés

A lánc az a felállás, amelyre az emberek általában gondolnak, amikor azt mondják, mindkettő egyszerre: a telefon alagútja a router alagútjában halad. Működhet, és a korlátok konkrétak. A külső szolgáltatónak engedélyeznie kell egy működő útvonalat a telefon VPN-végpontjához, ami az UDP-alapú protokolloknál azt jelenti, hogy a külső szolgáltatás nem blokkolhatja és nem korlátozhatja ezt a forgalmat.

Értse meg, ki mit lát. A külső szolgáltató a belső végpont felé irányuló kapcsolatot lát. A belső szolgáltató a telefon forgalmát a külső kijárattól kapja, és továbbítja. A végső cél általában a belső szolgáltatás kijáratát látja, és a lánc egyetlen szolgáltatója sem vak; az alkalmazásfiókok az útvonaltól függetlenül azonosítják a felhasználót.

Számítson gyakorlati költségekre. Minden réteg beágyazást ad hozzá, ezért az effektív MTU csökken, és egy korábban egy alagútnál megfelelő érték most töredezik vagy elakad, amíg a belső alagút MTU-ját óvatosan be nem állítják. Két réteg két hiba-függőséget és két életben tartó üzenetkészletet is jelent, és egy TCP-alapú belső alagút veszteséges külső kapcsolat felett úgy akadhat el, ahogy egy halott szerver szokott.

A legfontosabb: a lánc nem olvaszt össze két magánhálózatot. Az útvonalak, az átfedő előtagok, a DNS-feloldás és a hozzáférési szabályok továbbra is külön döntések, és egy router, amely egy VPN-t hordoz, miközben a telefon egy másikat, nem adja meg a telefonnak mindkét címteret.

Ellenőrizze a felépítést, mielőtt hibakeresést végezne rajta

Írja le a felállást egy mondatban, és tesztelje azon az alkalmazáson, amely elbukott. Az egymás utáni hozzáférésnek egyszerre egy alagutat kell mutatnia; a profilok szétválasztásának minden alkalmazást a saját felhasználójában kell mutatnia; egy láncnak azt kell mutatnia, hogy a belső alagút külső interfész felett épül fel, nem a fizikai felett.

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

Ha az útvonalkeresés a fizikai interfészt nevezi meg, miközben egy alkalmazás az alagutat várja, a felépítés és az alkalmazás kontextusa nem ért egyet, és egyetlen további VPN-alkalmazás sem békíti össze őket. A kezelt profilok dokumentációja lefedi a szétválasztási szabályokat, ha a szabályzat részletére van szüksége, nem az útvonalválasztáséra.