Dva VPN skoky za sebou: kdo skutečně vidí váš provoz?

Každý klientský profil jmenuje jeden server, takže z místa uživatele existuje jeden tunel a jedno místo, kde ochrana končí. Co se děje za tou první bránou, je rozhodnutí o návrhu, které klient nikdy nevidí, a oba běžné návrhy se při zkoumání chovají velmi odlišně. V sériovém řetězu první brána dešifruje a znovu šifruje. Ve vnořeném řetězu odstraňuje vnější vrstvu a předává vnitřní tunel, který nedokáže otevřít. Počet skoků je v obou případech stejný, a proto se rozdíl musí nakreslit, ne spočítat.

Začněte u klienta a pojmenujte oba konce

Začněte tam, kde začíná uživatel, v profilu připojení. Obsahuje jednu vzdálenou adresu, jednu metodu ověřování a, když to návrh podporuje, seznam tras. Označte ten vnější tunel od klienta k bráně A a dejte mu ukázkové adresy: adresa tunelu klienta 10.77.0.2, adresa A 10.77.0.1 a veřejný koncový bod A 198.51.100.10, převzaté z dokumentačního rozsahu TEST-NET-2, aby nic v ukázce nemohlo kolidovat s reálným hostitelem.

Nic v tom profilu nezmiňuje bránu B, a to není vada. Druhý skok patří A a jedinou povinností klienta je doručit provoz do A a přijmout, co se vrátí. Zda A tunel ukončuje, předává, nebo otevírá nový, je otázka, na kterou odpovídá zbytek tohoto průchodu, a rozhoduje o tom, co A může číst.

Sériově: A dešifruje, pak znovu šifruje

V sériovém návrhu A ukončuje provoz dvakrát. Odstraní ochranu od klienta, získá IP paket aplikace a poté tento paket odešle druhým tunelem, který A vytváří směrem k B. Mezi těmito dvěma operacemi paket leží v přeposílací cestě A jako běžný IP paket adresovaný na soukromé cílové místo.

To má dva důsledky, které je vhodné říct přímo. A může na vnitřní paket uplatnit politiku v podobě tras, filtrovacích pravidel a logování zdroje a cíle a A musí držet dvě sady přihlašovacích údajů: jednu jako server pro klienta a jednu jako klient B. Ochrana existuje v každém okamžiku, ale chráněný objekt na A mění identitu.

Z toho nevyplývá, že A čte otevřený text aplikace. Když klient a služba používají TLS a ověřují si navzájem certifikáty, A vidí proud záznamů TLS, nikoli čitelný požadavek. Potvrdit, kde tato ochrana končí, vyžaduje pohled na řetěz certifikátů služby, ne na schéma tunelu.

Vnořeně: A odstraňuje jen vnější vrstvu

Ve vnořeném návrhu klient nejprve vytvoří vnitřní tunel k B a poté tento tunel nese uvnitř vnějšího k A. A strhne vnější hlavičku, najde vnitřní tunel a předá jej, aniž by držel jeho klíče, takže vnitřní ochrana stále končí u B.

Klientův vzestupný kanál pak nese dvě vrstvy, zatímco cesta mezi A a B nese jednu. A vidí vnější adresy vnitřního tunelu, což stačí k tomu, aby vědělo, že provoz existuje a přibližně kam směřuje, a nestačí to k přečtení užitečného obsahu. To je celý rozdíl oproti sériovému případu a žádný počítač skoků to neukáže. Co A ještě může, je odmítnout předat to, co nedokáže přečíst, a to má operátor té brány vždy k dispozici.

Vnoření si tuto vlastnost nechává zaplatit. Každá vrstva přidává režii hlavičky, takže plánování MTU a MSS se stává povinným, ne jen uklizeným, a cesta, která funguje s jednou vrstvou, může s dvěma tiše zahazovat velké pakety. Každá vrstva také potřebuje vlastní chování při opětovném připojení a udržování spojení a porucha v jedné vrstvě vypadá jako částečný výpadek přes druhou.

Nakreslete pozorovatele, ne jen tunely

Tunely jsou ta snadná část kresby. Pozorovatelé jsou to, o co v návrhu jde, takže napište jeden řádek na každé stanoviště a vyplňte, co každé skutečně může přečíst.

Dva řádky se neustále pletou: operátor A a poskytovatel klientova tunelu. Mohou být jedna entita a oddělená jména bran z nich nečiní nezávislé. Nezávislé vlastnictví vyžaduje oddělenou administrativní kontrolu, oddělené přihlašovací údaje a oddělené logování.

Metadata přežívají oba návrhy. Časování, velikosti paketů a počty spojení zůstávají na každém skoku pozorovatelné, takže dva skoky zvyšují cenu korelace, místo aby signál odstranily. Návrh, který slibuje neviditelnost, je třeba před spoléháním ověřit proti tomuto seznamu.

Projděte cesty selhání, než si vyberete

Rozbíjejte věci záměrně z klienta, v pořadí, v jakém by je uživatel potkal. Začněte rozhraním a jeho MTU, protože vnoření selhává na velikosti paketu mnohem dřív než na autentizaci.

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 ověřte koncové body ochrany, místo abyste je předpokládali. Požádejte službu o její certifikát zevnitř kteréhokoli aktivního tunelu a porovnejte řetěz, který vidí klient, s řetězem, který služba skutečně předkládá. Brána, která přepodepisuje nebo odposlouchává, ten certifikát mění a kontrola se stane viditelnou jediným příkazem.

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

Skončete maticí opětovného připojení: tunel klienta spadne, tunel B spadne, cesta mezi A a B se změní. Poznamenejte, co se vrátí a co ne, a zda vnitřní spojení někdy nespadne na trasu mimo zamýšleného nositele. Zapište adresy, které každý test použil, protože opakování v jiné přístupové síti odpovídá na jinou otázku. Po každém opětovném připojení zopakujte i sondu MTU, protože změněná cesta může snížit použitelnou velikost, aniž by se pohnul jediný řádek konfigurace.

Zvolte sériové zapojení, když A musí na vnitřní paket uplatnit politiku, nebo když klient nedokáže provozovat dva vrstvené tunely. Zvolte vnoření, když vnitřní obsah musí zůstat na A nečitelný. Zapište volbu s jejími pozorovateli a čísly MTU a příští člověk nebude muset překreslovat celý obrázek, aby odpověděl na jednu otázku.