Dva VPN skoka zaredom: ko zapravo vidi vaš saobraćaj?

Svaki klijentski profil navodi jedan server, pa sa korisničkog mjesta postoji jedan tunel i jedno mjesto gdje zaštita prestaje. Šta se dešava poslije tog prvog gejta je dizajnerska odluka koju klijent nikada ne vidi, a dva uobičajena dizajna ponašaju se vrlo različito pod provjerom. U serijskom lancu prvi gejt dešifruje i ponovo šifruje. U ugniježđenom lancu on uklanja vanjski sloj i prosljeđuje unutrašnji tunel koji ne može otvoriti. Broj skokova je u oba slučaja isti, zato se razlika mora nacrtati, a ne prebrojati.

Pođite od klijenta i imenujte oba kraja

Pođite od mjesta gdje korisnik počinje, u profilu veze. On sadrži jednu udaljenu adresu, jedan metod autentifikacije i, kada dizajn to podržava, listu ruta. Označite taj vanjski tunel od klijenta do gejta A i dajte mu primjer adresa: adresa tunela klijenta 10.77.0.2, adresa A 10.77.0.1 i javna krajnja tačka A 198.51.100.10, uzete iz dokumentacionog opsega TEST-NET-2 da ništa u primjeru ne bi moglo kolidirati sa stvarnim hostom.

Ništa u tom profilu ne spominje gejt B i to nije nedostatak. Drugi skok pripada A, a jedina obaveza klijenta je da dostavi saobraćaj do A i prihvati ono što se vrati. Da li A prekida tunel, prosljeđuje ga ili otvara novi, pitanje je na koje odgovara ostatak ovog pregleda, i ono odlučuje šta A može čitati.

Serijski: A dešifruje, pa ponovo šifruje

U serijskom dizajnu A prekida saobraćaj dvaput. Uklanja zaštitu sa klijenta, dobija IP paket aplikacije i zatim taj paket šalje kroz drugi tunel koji A uspostavlja prema B. Između te dvije operacije paket stoji u A-ovoj putanji prosljeđivanja kao običan IP paket adresiran na privatno odredište.

To daje dvije posljedice koje valja reći otvoreno. A može primijeniti politiku na unutrašnji paket, kroz rute, filter pravila i evidentiranje izvora i odredišta, i A mora držati dva skupa akreditiva: jedan kao server za klijenta i jedan kao klijent B-a. Zaštita postoji u svakom trenutku, ali objekat koji se štiti mijenja identitet kod A.

Iz toga ne slijedi da A čita otvoreni tekst aplikacije. Kada klijent i servis koriste TLS i provjeravaju jedan drugom certifikate, A vidi tok TLS zapisa, a ne čitljiv zahtjev. Potvrđivanje gdje ta zaštita prestaje zahtijeva pogled na lanac certifikata servisa, a ne na dijagram tunela.

Ugniježđeno: A uklanja samo vanjski sloj

U ugniježđenom dizajnu klijent prvo gradi unutrašnji tunel prema B, a zatim taj tunel nosi unutar vanjskog do A. A skida vanjski zaglavlje, nalazi unutrašnji tunel i prosljeđuje ga bez držanja njegovih ključeva, pa unutrašnja zaštita i dalje prestaje kod B.

Tada klijentov uzlazni kanal nosi dva sloja, dok putanja između A i B nosi jedan. A vidi vanjske adrese unutrašnjeg tunela, što je dovoljno da se zna da saobraćaj postoji i otprilike kuda ide, a nedovoljno da se pročita korisni teret. To je cijela razlika od serijskog slučaja i nijedan brojač skokova je ne pokazuje. Ono što A još može jest da odbije proslijediti ono što ne može pročitati, a to je operateru tog gejta uvijek dostupno.

Ugnježđivanje naplaćuje tu osobinu. Svaki sloj dodaje zaglavlje, pa planiranje MTU i MSS postaje obavezno, a ne samo uredno, i putanja koja radi s jednim slojem može tiho odbacivati velike pakete s dva. Svaki sloj treba i svoje ponašanje ponovnog povezivanja i održavanja veze, a kvar u jednom sloju izgleda kao djelimičan prekid kroz drugi.

Nacrtajte posmatrače, ne samo tunele

Tuneli su lakši dio crteža. Posmatrači su ono o čemu dizajn jeste, zato napišite jedan red po tački gledišta i popunite šta svaki zaista može pročitati.

Dva reda se stalno miješaju: operater A i provajder klijentovog tunela. Oni mogu biti jedan entitet, a odvojena imena gejtova ih ne čine nezavisnim. Nezavisno vlasništvo traži odvojenu administrativnu kontrolu, odvojene akreditive i odvojeno evidentiranje.

Metapodaci preživljavaju oba dizajna. Vrijeme, veličine paketa i broj veza ostaju vidljivi na svakom skoku, pa dva skoka podižu cijenu korelacije, a ne uklanjaju signal. Dizajn koji obećava nevidljivost treba provjeriti prema tom spisku prije nego se iko na njega osloni.

Prođite kroz puteve kvara prije nego što izaberete

Lomite stvari namjerno sa klijenta, redom kojim bi ih korisnik susreo. Počnite s interfejsom i njegovim MTU-om, jer ugnježđivanje pada na veličini paketa mnogo prije nego što padne na autentifikaciji.

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

Zatim potvrdite krajnje tačke zaštite umjesto da ih pretpostavljate. Tražite od servisa njegov certifikat iznutra kojeg god tunela je aktivan i uporedite lanac koji klijent vidi s lancem koji servis zapravo predstavlja. Gejt koji ponovo potpisuje ili presreće mijenja taj certifikat, i provjera postaje vidljiva jednom komandom.

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

Završite matricom ponovnog povezivanja: klijentov tunel padne, B-ov tunel padne, putanja između A i B se promijeni. Zabilježite šta se vraća, a šta ne, i da li unutrašnja veza ikada padne na rutu izvan svog predviđenog nosioca. Zapišite adrese koje je svaki test koristio, jer ponavljanje na drugoj pristupnoj mreži odgovara na drugo pitanje. Ponovite i MTU probu nakon svakog ponovnog povezivanja, jer promijenjena putanja može sniziti upotrebljivu veličinu bez ijedne pomjerene linije konfiguracije.

Izaberite serijski kada A mora primijeniti politiku na unutrašnji paket ili kada klijent ne može pokrenuti dva naslagana tunela. Izaberite ugnježđivanje kada unutrašnji teret mora ostati nečitljiv kod A. Zapišite izbor s njegovim posmatračima i njegovim MTU brojevima, i sljedeća osoba neće morati ponovo crtati cijelu sliku da bi odgovorila na jedno pitanje.