Kaks VPN-hüpet järjest: kes tegelikult sinu liiklust näeb?

Iga kliendiprofiil nimetab ühte serverit, seega kasutaja vaatepunktist on üks tunnel ja üks koht, kus kaitse lõpeb. Mis juhtub pärast seda esimest väravat, on disainiotsus, mida klient kunagi ei näe, ja kaks levinud lahendust käituvad kontrolli all väga erinevalt. Jadaketis dekrüpteerib esimene värav ja krüpteerib uuesti. Pesastatud ketis eemaldab see väliskihi ja edastab sisemise tunneli, mida ta avada ei suuda. Hüpete arv on mõlemas sama, seepärast tuleb erinevus joonistada, mitte kokku lugeda.

Alustage kliendist ja nimetage mõlemad otsad

Alustage sealt, kust kasutaja alustab, ühenduse profiilist. See sisaldab ühte kaugadressi, ühte autentimismeetodit ja, kui disain seda toetab, marsruutide loendit. Märgistage see välimine tunnel kliendist väravani A ja andke sellele näidisadressid: kliendi tunneli aadress 10.77.0.2, A oma 10.77.0.1 ja A avalik lõpp-punkt 198.51.100.10, mis on võetud TEST-NET-2 dokumentatsioonialast, et miski näites ei saaks päris hostiga kokku põrgata.

Selles profiilis ei mainita väravat B ja see pole viga. Teine hüpe kuulub A-le ja kliendi ainus kohustus on toimetada liiklus A-ni ja võtta vastu see, mis tagasi tuleb. Kas A lõpetab tunneli, edastab selle või avab uue, on küsimus, millele ülejäänud ülevaade vastab, ja see otsustab, mida A lugeda saab.

Jadapõhine: A dekrüpteerib ja krüpteerib siis uuesti

Jadadisainis lõpetab A liikluse kaks korda. Ta eemaldab kliendilt kaitse, saab rakenduse IP-paketi ja saadab selle paketi seejärel teise tunneli kaudu, mille A loob B suunas. Nende kahe toimingu vahel seisab pakett A edastusteele tavalise IP-paketina, mis on adresseeritud privaatsele sihtkohale.

Sellest tuleneb kaks tagajärge, mida tasub otse öelda. A saab sisemisele paketile rakendada poliitikat marsruutide, filtrite reeglite ning allika ja sihtkoha logimise kujul, ja A peab hoidma kahte komplekti mandaate: ühte serverina kliendi jaoks ja teist B kliendina. Kaitse on olemas igal hetkel, kuid kaitstav objekt muudab A juures identiteeti.

Sellest ei järeldu, et A loeb rakenduse avateksti. Kui klient ja teenus kasutavad TLS-i ja kontrollivad teineteise sertifikaate, näeb A TLS-kirjete voogu, mitte loetavat päringut. Selle kinnitamine, kus kaitse lõpeb, nõuab pilku teenuse sertifikaadiahelale, mitte tunneli skeemile.

Pesastatud: A eemaldab ainult väliskihi

Pesastatud disainis ehitab klient esmalt sisemise tunneli B-sse ja kannab selle tunneli seejärel välimise sees A-ni. A eemaldab välimise päise, leiab sisemise tunneli ja edastab selle ilma selle võtmeid hoidmata, seega sisemine kaitse lõpeb endiselt B juures.

Siis kannab kliendi üleslink kaks kihti, samal ajal kui tee A ja B vahel kannab ühte. A näeb sisemise tunneli väliseid aadresse, millest piisab teadmiseks, et liiklus on olemas ja umbkaudu kuhu see läheb, ning ei piisa kasuliku koormuse lugemiseks. See on kogu erinevus jadajuhtumist ja ükski hüppeloendur ei näita seda. Mida A veel teha saab, on keelduda edastamast seda, mida ta lugeda ei suuda, ja see on selle värava operaatorile alati kättesaadav.

Pesastamine maksab selle omaduse eest. Iga kiht lisab päise ülekulu, seega MTU ja MSS planeerimine muutub kohustuslikuks, mitte lihtsalt korrapäraseks, ja tee, mis töötab ühe kihiga, võib kahega suuri pakette vaikselt kaotada. Iga kiht vajab ka oma taasühenduse ja keepalive'i käitumist ning tõrge ühes kihis näib läbi teise osalise katkestusena.

Joonistage vaatlejad, mitte ainult tunnelid

Tunnelid on joonise lihtne osa. Vaatlejad on see, millest disain on, seega kirjutage üks rida vaatepunkti kohta ja täitke, mida igaüks tegelikult lugeda saab.

Kaks rida aetakse pidevalt segi: A operaator ja kliendi tunneli pakkuja. Nad võivad olla üks üksus ja eraldi väravanimed ei tee neid sõltumatuks. Sõltumatu omandus nõuab eraldi halduskontrolli, eraldi mandaate ja eraldi logimist.

Metaandmed jäävad mõlemas disainis alles. Ajastus, paketi suurused ja ühenduste arvud jäävad igal hüppel jälgitavaks, seega kaks hüpet tõstavad korrelatsiooni hinda, mitte ei eemalda signaali. Nähtamatust lubav disain tuleks enne sellele toetumist selle nimekirja vastu kontrollida.

Käige läbi tõrketeed enne, kui valite

Lõhkuge asju meelega kliendi poolt, selles järjekorras, milles kasutaja neid kohtaks. Alustage liidesest ja selle MTU-st, sest pesastamine ebaõnnestub paketi suuruse juures palju varem kui autentimise juures.

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

Seejärel kinnitage kaitse lõpp-punktid, selle asemel et neid eeldada. Küsige teenuselt selle sertifikaati seestpoolt ükskõik millist avatud tunnelit, ja võrrelge ahelat, mida klient näeb, ahelaga, mida teenus tegelikult esitab. Värav, mis allkirjastab uuesti või püüab vahele, muudab seda sertifikaati, ja kontroll muutub nähtavaks ühe käsuga.

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

Lõpetage taasühenduse maatriksiga: kliendi tunnel kukub, B tunnel kukub, tee A ja B vahel muutub. Pange kirja, mis naaseb ja mis mitte, ning kas sisemine ühendus kunagi langeb marsruudile väljapoole oma kavandatud kandjat. Registreerige aadressid, mida iga test kasutas, sest kordamine teises juurdepääsuvõrgus vastab teisele küsimusele. Korrake ka MTU-proovi pärast iga taasühendust, sest muutunud tee võib vähendada kasutatavat suurust ilma, et ükski konfiguratsioonirida liiguks.

Valige jadapõhine, kui A peab sisemisele paketile poliitikat rakendama, või kui klient ei suuda käitada kahte kihistatud tunnelit. Valige pesastamine, kui sisemine koormus peab A juures loetamatuks jääma. Kirjutage valik koos selle vaatlejate ja MTU-numbritega üles, ja järgmine inimene ei pea kogu pilti uuesti joonistama, et ühele küsimusele vastata.