Ako rozdelený tunel rozhoduje, ktorá prevádzka používa VPN
Rozdelený tunel je súbor rozhodnutí o trasách a väzbách, nie režim, ktorý zapnete. Pozrite sa, ako pravidlá pre jednotlivé aplikácie, prefixy, DNS a bezpečnostné vypínače pôsobia spoločne.
Rozdelený tunel je smerovacia politika vyjadrená ako súbor pravidiel, a klient je len to, čo ich nainštaluje. Rozdelenie sa deje na dvoch miestach: pravidlá zhody, ktoré vyberajú cestu pre každý paket, a väzby, ktoré držia aplikáciu na jednom rozhraní, čokoľvek hovorí tabuľka. Na ktorom mechanizme váš klient závisí, vysvetľuje väčšinu prekvapení, o ktorých ľudia hlásia.
Politiku, ktorú dokážete vyjadriť v jednom riadku, možno otestovať. Politika opísaná ako rýchlejšie prehliadanie to nie je a nepovie vám, ktoré pravidlo zmeniť, keď požiadavka ide nesprávnym smerom.
Klient inštaluje pravidlá, jadro robí výber
Keď tunel vstane, klient pridá trasy a často pravidlá politiky do tej istej tabuľky, ktorú používajú vaše ďalšie rozhrania. Každý paket sa potom dostane do vyhľadávania, ktoré porovnáva jeho cieľ s každým kandidátskym prefixom a ponechá najšpecifickejšiu zhodu, zatiaľ čo priorita rieši zhody medzi pravidlami ukazujúcimi na rôzne tabuľky. Nič v tom vyhľadávaní nevie, že paket prišiel z karty prehliadača a nie zo zálohovacej úlohy. Vyhráva pravidlo, ktoré určuje cestu, a môžete ho prečítať pred zmenou aj po nej.
Preto môže rozdelený tunel pôsobiť svojvoľne. Dve ciele v jednej aplikácii môžu ísť rôznymi cestami len preto, že jeden prefix je užší ako druhý.
Rovnaká voľba existuje na každej platforme, hoci názvy sa menia. Windows tlačí rozhodnutie do svojej filtračnej platformy, Android zverejňuje zoznam povolených aplikácií cez svoju službu VPN a macOS pripája tunel k zariadeniu, ktoré stále poslúcha smerovaciu tabuľku. Poznámky Microsoftu k smerovaniu stoja za prečítanie pre prípad Windows a príručka napísaná pre jednu platformu sa málokedy prenesie bez zmien na inú.
Väzba na aplikáciu a cieľové prefixy sú rôzne nástroje
Politika cieľa sa pýta, kam paket ide, a radí sa so smerovacou tabuľkou alebo pravidlom politiky. Politika pre aplikáciu sa pýta, ktorý program otvoril soket, a platforma drží ten program na rozhraní tunela, aj keď konkrétnejšia trasa ukazuje inam. Druhá je silnejšia, pretože prežíva zmeny tabuľky, ale pokrýva len procesy, ktoré platforma dokáže pripísať. Pomocný proces, vstavaný prehliadač alebo služba, ktorá otvára vlastné spojenie, nemusí zdediť väzbu, ktorú ste predpokladali.
Ani jeden z prístupov neprežije politiku založenú na menách bez pomoci. Adresy veľkých stránok rotujú medzi obsahovými sieťami, takže pripnutie názvu hostiteľa k niekoľkým prefixom vytvorí pravidlo, ktoré potichu prestane zodpovedať. Politika, ktorá musí nasledovať mená, potrebuje komponent znajúci resolver namiesto statickej trasy.
DNS a bezpečnostný vypínač nasledujú vlastné pravidlá
Preklad názvov je samostatné rozhodnutie od smerovania paketov a rozdelený tunel zvyčajne chce dva resolvere: firemný pre interné mená, miestny pre všetko ostatné. Klient môže nainštalovať nastavenia DNS pre jednotlivé rozhrania, odovzdať dopyty sprostredkujúcemu resolveru alebo nechať systémové predvolené nastavenie nedotknuté. Prehliadač s vlastným šifrovaným resolverom obchádza všetky tri usporiadania. Otestujte dopyt namiesto toho, aby ste predpokladali, že resolver nasledoval trasu.
Bezpečnostný vypínač pridáva filter navrch a ten filter nie vždy rozlíši zamýšľané vylúčenie od náhodného úniku. Niektorí klienti blokujú všetko mimo tunela, iní povoľujú výnimky, ktoré politika deklaruje, preto si prečítajte, aké správanie implementuje ten váš, kým sa spoľahnete na ktorýkoľvek.
Skontrolujte rozdelenie z oboch strán
Otestujte zahrnutú cestu a vylúčenú cestu oddelene a výsledok posudzujte podľa názvu rozhrania, nie podľa verejnej adresy. Tieto príkazy predpokladajú hostiteľa Linux s už zdvihnutým tunelovým zariadením. Nahraďte 203.0.113.10 cieľom, ktorý vaša politika smeruje dovnútra, a 198.51.100.25 cieľom, ktorý posiela von.
ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'
Čítajte prvé dve odpovede spolu, pretože rozhranie uvedené v každej z nich ukazuje, či rozdelenie umiestnilo ten cieľ do tunela. Dopyt na resolver ukazuje, ktorý server odpovedal na interné meno, a posledný príkaz dokazuje, že tunelové zariadenie vôbec unesie požiadavku. Zlyhanie na druhom riadku, kým prvý uspeje, znamená, že politika robí presne to, čo jej bolo povedané.
Súbor zopakujte po opätovnom pripojení a po zmene siete. Obnova lízingu a pohyb rozhraní sú miesta, kde rozdelenie prestáva zodpovedať zámeru, pre ktorý bolo postavené, a uložený výstup z každého spustenia robí odchýlku zjavnou.