Két VPN-ugrás egymás után: ki látja valójában a forgalmadat?
A soros ugrások az első átjárónál visszafejtik és újra titkosítják; a beágyazott ugrások csak a külső réteget távolítják el. Járja végig mindkét tervet, és lássa, melyik üzemeltető mit olvas.
Minden kliensprofil egyetlen szervert nevez meg, így a felhasználó helyéről nézve egy alagút és egy hely van, ahol a védelem véget ér. Az, hogy mi történik az első átjáró után, olyan tervezési döntés, amelyet a kliens soha nem lát, és a két gyakori terv vizsgálat alatt nagyon eltérően viselkedik. Soros láncban az első átjáró visszafejt, majd újra titkosít. Beágyazott láncban eltávolít egy külső réteget, és továbbít egy belső alagutat, amelyet nem tud megnyitni. Az ugrások száma mindkettőben azonos, ezért a különbséget rajzolni kell, nem számolni.
Kezdje a kliensnél, és nevezze meg mindkét végpontot
Ott kezdje, ahol a felhasználó kezdi, a kapcsolati profilban. Egy távoli címet, egy hitelesítési módszert és, ha a terv támogatja, útvonallistát tartalmaz. Jelölje meg azt a külső alagutat a klienstől az A átjáróig, és adjon neki példacímeket: a kliens alagútcíme 10.77.0.2, az A-é 10.77.0.1 és az A nyilvános végpontja 198.51.100.10, a TEST-NET-2 dokumentációs tartományból véve, hogy semmi a példában ne ütközhessen valódi gazdagéppel.
A profilban semmi sem említi a B átjárót, és ez nem hiba. A második ugrás A-hoz tartozik, és a kliens egyetlen kötelezettsége, hogy eljuttassa a forgalmat A-hoz, és elfogadja, ami visszajön. Hogy A lezárja-e az alagutat, továbbítja-e vagy újat nyit, arra a kérdésre a bejárás többi része válaszol, és ez dönti el, mit olvashat A.
Soros: A visszafejt, majd újra titkosít
A soros tervben A kétszer zárja le a forgalmat. Eltávolítja a védelmet a kliensről, megkapja az alkalmazás IP-csomagját, majd ezt a csomagot egy második alagúton küldi tovább, amelyet A a B felé indít. A két művelet között a csomag A továbbítási útvonalán fekszik, mint egy magáncímre címzett közönséges IP-csomag.
Ennek két következménye van, amelyeket érdemes nyíltan kimondani. A szabályzatot alkalmazhat a belső csomagra útvonalak, szűrőszabályok, valamint a forrás és a cél naplózása formájában, és A-nak két hitelesítőadat-készletet kell tartania: egyet szerverként a klienshez, egyet pedig B klienseként. A védelem minden pillanatban létezik, mégis a védett objektum identitást vált A-nál.
Ebből nem következik, hogy A olvassa az alkalmazás nyílt szövegét. Amikor a kliens és a szolgáltatás TLS-t futtat, és kölcsönösen ellenőrzi egymás tanúsítványát, A TLS-rekordfolyamot lát, nem olvasható kérést. Annak igazolása, hogy hol ér véget ez a védelem, a szolgáltatás tanúsítványláncára pillantást igényel, nem az alagút ábrájára.
Beágyazott: A csak a külső réteget távolítja el
A beágyazott tervben a kliens először belső alagutat épít B-hez, majd ezt az alagutat a külsőn belül viszi A-hoz. A eltávolítja a külső fejlécet, belső alagutat talál, és továbbítja anélkül, hogy a kulcsait tartaná, így a belső védelem továbbra is B-nél ér véget.
Ekkor a kliens felfelé irányuló kapcsolata két réteget hordoz, míg az A és B közötti útvonal egyet. A látja a belső alagút külső címeit, ami elég ahhoz, hogy tudjuk, létezik forgalom, és nagyjából hova tart, és nem elég a hasznos teher olvasásához. Ez a teljes különbség a soros esethez képest, és egyetlen ugrásszámláló sem mutatja. Amit A még megtehet, az az, hogy megtagadja annak továbbítását, amit nem tud olvasni, és ez mindig elérhető az adott átjáró üzemeltetője számára.
A beágyazás fizet ezért a tulajdonságért. Minden réteg fejléc-többletet ad, így az MTU- és MSS-tervezés kötelezővé válik, nem csupán rendezetté, és egy réteggel működő útvonal kettővel csendben eldobhat nagy csomagokat. Minden rétegnek saját újracsatlakozási és életben tartási viselkedésre is szüksége van, és az egyik réteg hibája a másikon át részleges kiesésnek látszik.
A megfigyelőket rajzolja meg, ne csak az alagutakat
Az alagutak a rajz könnyű része. A megfigyelők azok, amiről a terv szól, ezért írjon egy sort nézőpontonként, és töltse ki, mit tud valójában olvasni mindegyik.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
Két sort állandóan összekevernek: A üzemeltetőjét és a kliens alagútjának szolgáltatóját. Ezek lehetnek egy szervezet, és a külön átjárónevek nem teszik őket függetlenné. A független tulajdonláshoz külön adminisztratív irányítás, külön hitelesítő adatok és külön naplózás kell.
A metaadatok mindkét tervet túlélik. Az időzítés, a csomagméretek és a kapcsolatszámok minden ugrásnál megfigyelhetők maradnak, így két ugrás inkább megemeli a korreláció költségét, mint eltávolítja a jelet. Az észlelhetetlenséget ígérő tervet ezzel a listával kell összevetni, mielőtt bárki támaszkodna rá.
Járja be a hibaútvonalakat, mielőtt választ
Törjön el dolgokat szándékosan a kliens felől, abban a sorrendben, ahogy egy felhasználó találkozna velük. Kezdje az interfésszel és annak MTU-jával, mert a beágyazás csomagméretnél sokkal korábban vall kudarcot, mint hitelesítésnél.
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1
Ezután igazolja a védelem végpontjait, ne feltételezze őket. Kérje el a szolgáltatás tanúsítványát a nyitva lévő alagút belsejéből, és hasonlítsa össze a kliens által látott láncot azzal, amelyet a szolgáltatás valóban bemutat. Az újra-aláíró vagy elfogó átjáró megváltoztatja azt a tanúsítványt, és az ellenőrzés egyetlen parancsban láthatóvá válik.
openssl s_client -connect intranet.example.com:443 -brief < /dev/null
Fejezze be az újracsatlakozási mátrixszal: a kliens alagútja elesik, B alagútja elesik, az A és B közötti útvonal megváltozik. Jegyezze fel, mi tér vissza és mi nem, és hogy egy belső kapcsolat valaha visszaesik-e a szándékolt hordozón kívüli útvonalra. Rögzítse az egyes tesztek által használt címeket, mert egy másik hozzáférési hálózaton megismételve más kérdésre válaszol. Minden újracsatlakozás után ismételje meg az MTU-vizsgálatot is, mert egy megváltozott útvonal csökkentheti a használható méretet anélkül, hogy egyetlen konfigurációs sor elmozdulna.
Válassza a sorost, amikor A-nak szabályzatot kell alkalmaznia a belső csomagra, vagy amikor a kliens nem tud két egymásra rakott alagutat futtatni. Válassza a beágyazást, amikor a belső hasznos tehernek A-nál olvashatatlannak kell maradnia. Írja le a választását a megfigyelőivel és az MTU-számaival, és a következő embernek nem kell újrarajzolnia az egész képet egyetlen kérdés megválaszolásához.