Dva VPN skoky za sebou: kto skutočne vidí váš provoz?

Každý klientsky profil uvádza jeden server, takže z miesta používateľa existuje jeden tunel a jedno miesto, kde sa ochrana končí. Čo sa deje za tou prvou bránou, je rozhodnutie o návrhu, ktoré klient nikdy nevidí, a oba bežné návrhy sa pri kontrole správajú veľmi odlišne. V sériovej reťazi prvá brána dešifruje a znova šifruje. Vo vnorenej reťazi odstraňuje vonkajšiu vrstvu a posiela ďalej vnútorný tunel, ktorý nedokáže otvoriť. Počet skokov je v oboch rovnaký, preto sa rozdiel musí nakresliť, nie spočítať.

Začnite pri klientovi a pomenujte oba konce

Začnite tam, kde začína používateľ, v profile pripojenia. Obsahuje jednu vzdialenú adresu, jednu metódu overovania a, keď to návrh podporuje, zoznam trás. Označte ten vonkajší tunel od klienta k bráne A a dajte mu ukážkové adresy: adresa tunela klienta 10.77.0.2, adresa A 10.77.0.1 a verejný koncový bod A 198.51.100.10, prevzaté z dokumentačného rozsahu TEST-NET-2, aby nič v ukážke nemohlo kolidovať so skutočným hostiteľom.

Nič v tom profile nespomína bránu B, a to nie je chyba. Druhý skok patrí A a jedinou povinnosťou klienta je doručiť provoz do A a prijať, čo sa vráti. Či A tunel ukončuje, posiela ďalej alebo otvára nový, je otázka, na ktorú odpovedá zvyšok tohto prehľadu, a rozhoduje o tom, čo A môže čítať.

Sériovo: A dešifruje, potom znova šifruje

V sériovom návrhu A ukončuje provoz dvakrát. Odstráni ochranu od klienta, získa IP paket aplikácie a potom tento paket odošle druhým tunelom, ktorý A vytvára smerom k B. Medzi týmito dvoma operáciami paket leží v preposielacej ceste A ako bežný IP paket adresovaný na súkromné cieľové miesto.

To má dva dôsledky, ktoré sa hodí povedať priamo. A môže na vnútorný paket uplatniť politiku v podobe trás, filtrovacích pravidiel a logovania zdroja a cieľa a A musí držať dve sady prihlasovacích údajov: jednu ako server pre klienta a jednu ako klient B. Ochrana existuje v každom okamihu, ale chránený objekt na A mení identitu.

Z toho nevyplýva, že A číta otvorený text aplikácie. Keď klient a služba používajú TLS a overujú si navzájom certifikáty, A vidí tok záznamov TLS, nie čitateľnú požiadavku. Potvrdiť, kde sa táto ochrana končí, si vyžaduje pohľad na reťaz certifikátov služby, nie na schému tunela.

Vnorene: A odstraňuje len vonkajšiu vrstvu

Vo vnorenom návrhu klient najprv vytvorí vnútorný tunel k B a potom tento tunel nesie vo vnútornom až k A. A strhne vonkajšiu hlavičku, nájde vnútorný tunel a pošle ho ďalej bez toho, aby držal jeho kľúče, takže vnútorná ochrana stále končí pri B.

Vzostupné spojenie klienta potom nesie dve vrstvy, kým cesta medzi A a B nesie jednu. A vidí vonkajšie adresy vnútorného tunela, čo stačí na to, aby vedelo, že provoz existuje a približne kam smeruje, a nestačí na prečítanie užitočného obsahu. To je celý rozdiel oproti sériovému prípadu a žiadny počítač skokov to neukáže. Čo A ešte môže, je odmietnuť poslať ďalej to, čo nedokáže prečítať, a to má operátor tej brány vždy k dispozícii.

Vnorenie si túto vlastnosť nechá zaplatiť. Každá vrstva pridáva réžiu hlavičky, takže plánovanie MTU a MSS sa stáva povinným, nie len uprataným, a cesta, ktorá funguje s jednou vrstvou, môže s dvoma ticho zahadzovať veľké pakety. Každá vrstva tiež potrebuje vlastné správanie pri opätovnom pripojení a udržiavaní spojenia a porucha v jednej vrstve vyzerá cez druhú ako čiastočný výpadok.

Nakreslite pozorovateľov, nie len tunely

Tunely sú tá ľahká časť kresby. Pozorovatelia sú to, o čo v návrhu ide, takže napíšte jeden riadok na každé stanovisko a vyplňte, čo každé skutočne dokáže prečítať.

Dva riadky sa neustále zamieňajú: operátor A a poskytovateľ tunela klienta. Môžu byť jedna entita a oddelené názvy brán z nich nerobia nezávislé. Nezávislé vlastníctvo vyžaduje oddelenú administratívnu kontrolu, oddelené prihlasovacie údaje a oddelené logovanie.

Metadáta prežívajú oba návrhy. Časovanie, veľkosti paketov a počty spojení zostávajú na každom skoku pozorovateľné, takže dva skoky zvyšujú cenu korelácie namiesto odstránenia signálu. Návrh, ktorý sľubuje neviditeľnosť, treba pred spoliehaním sa naň overiť proti tomuto zoznamu.

Prejdite cesty zlyhania, kým si vyberiete

Rozbíjajte veci zámerne z klienta, v poradí, v akom by ich používateľ stretol. Začnite rozhraním a jeho MTU, pretože vnorenie zlyháva na veľkosti paketu oveľa skôr než na overovaní.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Potom overte koncové body ochrany namiesto toho, aby ste ich predpokladali. Požiadajte službu o jej certifikát zvnútra ktoréhokoľvek aktívneho tunela a porovnajte reťaz, ktorú vidí klient, s reťazou, ktorú služba skutočne predkladá. Brána, ktorá podpisuje znova alebo odpočúva, ten certifikát mení a kontrola sa stane viditeľnou jediným príkazom.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Skončite maticou opätovného pripojenia: tunel klienta spadne, tunel B spadne, cesta medzi A a B sa zmení. Poznamenajte, čo sa vráti a čo nie, a či vnútorné spojenie niekedy nespadne na trasu mimo svojho zamýšľaného nosiča. Zaznamenajte adresy, ktoré použil každý test, pretože opakovanie v inej prístupovej sieti odpovedá na inú otázku. Po každom opätovnom pripojení zopakujte aj skúšku MTU, pretože zmenená cesta môže znížiť použiteľnú veľkosť bez toho, aby sa pohol jediný riadok konfigurácie.

Vyberte sériové zapojenie, keď A musí na vnútorný paket uplatniť politiku, alebo keď klient nedokáže spustiť dva vrstvené tunely. Vyberte vnorenie, keď vnútorný obsah musí zostať na A nečitateľný. Zapíšte voľbu s jej pozorovateľmi a jej číslami MTU a nasledujúci človek nebude musieť prekresľovať celý obrázok, aby odpovedal na jednu otázku.