Rozdělený tunel: proč se odkaz otevírá mimo VPN, kterou jste nastavili
Směrování sleduje proces, který otevírá socket, ne aplikaci, která vám odkaz ukázala. Dokažte, který program se připojuje, než rozšíříte výjimky.
Provedení aplikace tunelem nepřenáší její směrování na vše, co tato aplikace spustí, i když rozhraní naznačuje opak. Odkaz předá požadavek jinému programu, ten otevře vlastní socket a platforma aplikuje pravidla na nový proces, nikoli na ten, který text zobrazil. Právě ten druhý proces vidí politika tunelu, a to není ten, který jste nakonfigurovali.
Zahrnutá aplikace tedy může otevřít prohlížeč, který stojí mimo tunel. Vyloučený prohlížeč může vrátit práci aplikaci, která stojí uvnitř něj. Oba směry tohoto překvapení jsou běžné chování.
Část pracovního postupu, kterou nikdo nenastavil
Politika pro jednotlivé aplikace se píše proti identitě spustitelného souboru nebo balíčku a každé připojení se vyhodnocuje v okamžiku svého vzniku. Prohlížeč, prohlížeč dokumentů, přehrávač médií i systémový list pro sdílení nesou každý svou identitu a každý dostává svůj verdikt. Hluboký odkaz nese data, ne politiku.
Proto se pozorování zdá nahodilé: stejné kliknutí se směruje dvěma způsoby podle toho, který obslužný program odpoví. Poštovní klient v tunelu otevře odkaz v prohlížeči, který žije mimo tunel, a stránka se načte z vaší domácí adresy. Prohlížeč mimo tunel otevře dokument v prohlížeči, který žije uvnitř, a soubor dorazí přes výstup. Ani jeden z výsledků není závada klienta.
Již běžící obslužný program situaci zhoršuje. Je-li prohlížeč už otevřený, stane se odkaz zprávou existujícímu procesu a ten si ponechá směrování, které měl při spuštění. Zavření a znovuotevření obsluhy výsledek změní, a proto se problém nikdy nereprodukuje na požádání.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
Který proces spojení skutečně navázal
Měřte přijímající stranu, místo abyste o ní uvažovali. Nechte tunel běžet, klikněte na neškodný odkaz a podívejte se na sockety, které nový program drží.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
První příkaz pojmenuje proces za každým navázaným socketem v Linuxu, druhý dělá totéž ve Windows rozlišením identifikátoru vlastnícího procesu. Porovnejte název procesu s názvy ve své politice. Je-li název prohlížeč a prohlížeč je vyloučen, kliknutí opustilo tunel záměrně, ne vinou závady. Spárování pravidla politiky se živým socketem je celá metoda.
Kontrolu zopakujte s již běžící obsluhou a potom se zavřenou. Oba výsledky se mohou lišit a tento rozdíl vysvětluje většinu občasných hlášení o odkazech unikajících z tunelu.
Pokrytí je vlastnost pracovního postupu
Má-li úkol zůstat v tunelu od začátku do konce, každá komponenta, na kterou může dosáhnout, musí být uvnitř politiky: spouštěč, obsluha, prohlížeč a jakýkoli prostředník, který platforma vloží mezi ně. Širší pokrytí je často poctivá odpověď a je levnější než audit každého cíle sdílení.
Vyloučit systémového prostředníka, abyste opravili jednu aplikaci, je častá chyba. Prostředníci jsou sdílení, takže vyloučení následuje každou další aplikaci, která používá stejnou cestu, obvykle aniž si toho kdokoli všimne, dokud o týdny později nepřijde hlášení. Přečtěte si, co dalšího na komponentě závisí, než ji vyloučíte.
Držte identitu odděleně od směrování. Odkaz může nést token relace nebo identifikátor účtu bez ohledu na to, který výstup požadavek přijme. Správně směrované kliknutí může cíli stále přesně říct, kdo ho následoval.
Dokumentujte pracovní postup, ne první zaškrtávací políčko. Když úkol zahrnuje čtyři programy, diagram se čtyřmi programy je ten, který předpovídá, kam provoz půjde, a nastavení jedné aplikace je jen jeden jeho řádek.