Divi VPN lēcieni pēc kārtas: kas patiešām redz tavu datu plūsmu?

Katrs klienta profils nosauc vienu serveri, tāpēc no lietotāja vietas ir viens tunelis un viena vieta, kur aizsardzība beidzas. Tas, kas notiek pēc šīs pirmās vārtejas, ir dizaina lēmums, ko klients nekad neredz, un abi izplatītie dizaini pārbaudē uzvedas ļoti atšķirīgi. Secīgā ķēdē pirmā vārteja atšifrē un atkārtoti šifrē. Ligzdotā ķēdē tā noņem ārējo slāni un pārsūta iekšējo tuneli, ko nevar atvērt. Lēcienu skaits abos ir vienāds, tāpēc atšķirība ir jāzīmē, nevis jāskaita.

Sāciet pie klienta un nosauciet abus galus

Sāciet tur, kur sāk lietotājs, savienojuma profilā. Tajā ir viena attālināta adrese, viena autentifikācijas metode un, ja dizains to atbalsta, maršrutu saraksts. Atzīmējiet to ārējo tuneli no klienta līdz vārtejai A un piešķiriet tam piemēra adreses: klienta tuneļa adrese 10.77.0.2, A adrese 10.77.0.1 un A publiskais galapunkts 198.51.100.10, ņemti no TEST-NET-2 dokumentācijas diapazona, lai nekas piemērā nesadurtos ar īstu resursdatoru.

Nekas šajā profilā nemin vārteju B, un tas nav defekts. Otrais lēciens pieder A, un vienīgais klienta pienākums ir piegādāt plūsmu A un pieņemt to, kas atgriežas. Vai A pārtrauc tuneli, pārsūta to vai atver jaunu, ir jautājums, uz ko atbild pārējā šī apskata daļa, un tas nosaka, ko A var lasīt.

Secīgi: A atšifrē un pēc tam atkārtoti šifrē

Secīgajā dizainā A pārtrauc plūsmu divreiz. Tas noņem aizsardzību no klienta, iegūst lietotnes IP paketi un pēc tam sūta šo paketi pa otru tuneli, ko A veido uz B pusi. Starp šīm divām darbībām pakete atrodas A pārsūtīšanas ceļā kā parasta IP pakete, kas adresēta privātam galamērķim.

Tas dod divas sekas, ko vērts pateikt tieši. A var piemērot politiku iekšējai paketei maršrutu, filtru noteikumu un avota un galamērķa reģistrēšanas veidā, un A ir jātur divi akreditācijas datu komplekti: viens kā serveris klientam un viens kā B klients. Aizsardzība pastāv katrā mirklī, tomēr aizsargājamais objekts A maina identitāti.

No tā neizriet, ka A lasa lietotnes atklāto tekstu. Kad klients un pakalpojums izmanto TLS un pārbauda viens otra sertifikātus, A redz TLS ierakstu plūsmu, nevis lasāmu pieprasījumu. Lai apstiprinātu, kur šī aizsardzība beidzas, jāaplūko pakalpojuma sertifikātu ķēde, nevis tuneļa shēma.

Ligzdoti: A noņem tikai ārējo slāni

Ligzdotajā dizainā klients vispirms izveido iekšējo tuneli uz B un pēc tam nes šo tuneli ārējā līdz A. A noņem ārējo galveni, atrod iekšējo tuneli un pārsūta to, neturot tā atslēgas, tāpēc iekšējā aizsardzība joprojām beidzas pie B.

Tad klienta augšupceļš nes divus slāņus, bet ceļš starp A un B nes vienu. A redz iekšējā tuneļa ārējās adreses, ar ko pietiek zināt, ka plūsma pastāv un apmēram kur tā iet, un nepietiek lietderīgās kravas lasīšanai. Tā ir visa atšķirība no secīgā gadījuma, un to neparāda neviens lēcienu skaitītājs. Ko A vēl var darīt, ir atteikties pārsūtīt to, ko nevar nolasīt, un tas šīs vārtejas operatoram vienmēr ir pieejams.

Ligzdošana maksā par šo īpašību. Katrs slānis pievieno galvenes izmaksas, tāpēc MTU un MSS plānošana kļūst obligāta, nevis vienkārši kārtīga, un ceļš, kas darbojas ar vienu slāni, ar diviem var klusi nomest lielas paketes. Katram slānim vajadzīga arī sava atkārtotas savienošanas un dzīvības uzturēšanas uzvedība, un viena slāņa kļūme caur otru izskatās kā daļējs pārtraukums.

Zīmējiet novērotājus, ne tikai tuneļus

Tuneļi ir vieglā zīmējuma daļa. Novērotāji ir tas, par ko ir dizains, tāpēc rakstiet vienu rindu katram skatupunktam un aizpildiet, ko katrs patiešām var nolasīt.

Divas rindas pastāvīgi tiek sajauktas: A operators un klienta tuneļa nodrošinātājs. Tie var būt viena vienība, un atsevišķi vārteju nosaukumi nepadara tos neatkarīgus. Neatkarīgam īpašumam vajadzīga atsevišķa administratīvā kontrole, atsevišķi akreditācijas dati un atsevišķa reģistrēšana.

Metadati izdzīvo abos dizainos. Laiks, pakešu izmēri un savienojumu skaits joprojām ir novērojami katrā lēcienā, tāpēc divi lēcieni paaugstina korelācijas izmaksas, nevis noņem signālu. Dizains, kas sola neredzamību, būtu jāpārbauda pret šo sarakstu, pirms kāds uz to paļaujas.

Izstaigājiet kļūmju ceļus, pirms izvēlaties

Laužiet lietas apzināti no klienta puses, tādā secībā, kādā lietotājs tās satiktu. Sāciet ar saskarni un tās MTU, jo ligzdošana neizdodas pakešu izmērā daudz agrāk nekā autentifikācijā.

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

Pēc tam apstipriniet aizsardzības galapunktus, nevis pieņemiet tos. Lūdziet pakalpojumam tā sertifikātu no jebkura aktīva tuneļa iekšpuses un salīdziniet ķēdi, ko redz klients, ar ķēdi, ko pakalpojums patiešām uzrāda. Vārteja, kas pārparaksta vai pārtver, maina šo sertifikātu, un pārbaude kļūst redzama ar vienu komandu.

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

Beidziet ar atkārtotas savienošanas matricu: klienta tunelis krīt, B tunelis krīt, ceļš starp A un B mainās. Pierakstiet, kas atgriežas un kas ne, un vai iekšējais savienojums kādreiz krīt uz maršrutu ārpus tā paredzētā nesēja. Reģistrējiet adreses, ko izmantoja katrs tests, jo atkārtošana citā piekļuves tīklā atbild uz citu jautājumu. Atkārtojiet arī MTU pārbaudi pēc katras atkārtotās savienošanas, jo mainīts ceļš var pazemināt izmantojamo izmēru, nepakustinot nevienu konfigurācijas rindu.

Izvēlieties secīgo, kad A jāpiemēro politika iekšējai paketei, vai kad klients nevar palaist divus sakrautus tuneļus. Izvēlieties ligzdošanu, kad iekšējai kravai jāpaliek nenolasāmai pie A. Pierakstiet izvēli ar tās novērotājiem un MTU skaitļiem, un nākamajam cilvēkam nevajadzēs pārzīmēt visu attēlu, lai atbildētu uz vienu jautājumu.