Twee VPN-spronge na mekaar: wie sien werklik jou verkeer?

Elke kliëntprofiel noem een bediener, so uit die gebruiker se oogpunt is daar een tonnel en een plek waar beskerming eindig. Wat ná daardie eerste poort gebeur, is 'n ontwerpbeslissing wat die kliënt nooit sien nie, en die twee algemene ontwerpe gedra hulle baie anders onder ondersoek. In 'n seriële ketting ontsleutel die eerste poort en versleutel weer. In 'n geneste ketting verwyder dit 'n buitenste laag en stuur 'n binneste tonnel aan wat dit nie kan oopmaak nie. Die sprongtelling is in albei identies, en daarom moet die verskil geteken word eerder as getel.

Begin by die kliënt en benoem albei eindpunte

Begin waar die gebruiker begin, in die verbindingsprofiel. Dit hou een afgeleë adres, een verifikasiemetode en, wanneer die ontwerp dit ondersteun, 'n roetelys. Merk daardie buitenste tonnel van die kliënt na poort A en gee dit voorbeeldadresse: die kliënt se tonneladres 10.77.0.2, A se 10.77.0.1, en A se publieke eindpunt 198.51.100.10, geneem uit die TEST-NET-2-dokumentasiereeks sodat niks in die voorbeeld met 'n regte gasheer kan bots nie.

Niks in daardie profiel noem poort B nie, en dit is nie 'n fout nie. Die tweede sprong behoort aan A, en die kliënt se enigste verpligting is om verkeer na A te lewer en te aanvaar wat terugkom. Of A die tonnel beëindig, dit aanstuur of 'n nuwe een oopmaak, is die vraag wat die res van hierdie uiteensetting antwoord, en dit bepaal wat A kan lees.

Serieel: A ontsleutel, dan versleutel weer

In die seriële ontwerp beëindig A verkeer twee keer. Dit verwyder die beskerming van die kliënt, verkry die toepassing se IP-pakket en stuur daardie pakket dan deur 'n tweede tonnel wat A na B begin. Tussen daardie twee bewerkings sit die pakket in A se aanstuurpad as 'n gewone IP-pakket gerig op 'n private bestemming.

Dit lewer twee gevolge op wat reguit gestel moet word. A kan beleid op die binneste pakket toepas, in die vorm van roetes, filterreëls en logboek van bron en bestemming, en A moet twee stelle geloofsbriewe hou, een as bediener vir die kliënt en een as kliënt van B. Beskerming bestaan op elke oomblik, tog verander die voorwerp wat beskerm word van identiteit by A.

Dit volg nie dat A toepassingsleesteks lees nie. Wanneer die kliënt en die diens TLS gebruik en mekaar se sertifikate verifieer, sien A 'n TLS-rekordstroom eerder as 'n leesbare versoek. Om te bevestig waar daardie beskerming eindig, moet 'n mens na die diens se sertifikaatketting kyk, nie na die tonneldiagram nie.

Genestel: A verwyder net die buitenste laag

In die geneste ontwerp bou die kliënt eers 'n binneste tonnel na B en dra daardie tonnel dan binne die buitenste een na A. A stroop die buitenste kop af, vind 'n binneste tonnel en stuur dit aan sonder om sy sleutels te hou, so die binneste beskerming eindig steeds by B.

Die kliënt se opwaartse skakel dra dan twee lae, terwyl die pad tussen A en B een dra. A sien die buitenste adresse van die binneste tonnel, wat genoeg is om te weet dat verkeer bestaan en ongeveer waarheen dit gaan, en nie genoeg om die vrag te lees nie. Dit is die hele verskil van die seriële geval, en geen sprongteller wys dit nie. Wat A steeds kan doen, is weier om aan te stuur wat dit nie kan lees nie, wat altyd vir die operateur van daardie poort beskikbaar is.

Nesteling betaal vir daardie eienskap. Elke laag voeg kop-oorhoofde by, so MTU- en MSS-beplanning word verpligtend eerder as netjies, en 'n pad wat met een laag werk, kan groot pakkette met twee stilweg laat val. Elke laag het ook sy eie herverbindings- en lewendighougedrag nodig, en 'n fout in een laag lyk soos 'n gedeeltelike onderbreking deur die ander.

Teken die waarnemers, nie net die tonnels nie

Die tonnels is die maklike deel van die tekening. Die waarnemers is waaroor die ontwerp gaan, so skryf een ry per uitkykpunt en vul in wat elkeen werklik kan lees.

Twee rye word gedurig verwar: die operateur van A en die verskaffer van die kliënt se tonnel. Hulle kan een entiteit wees, en aparte poortname maak hulle nie onafhanklik nie. Onafhanklike eienaarskap vereis aparte administratiewe beheer, aparte geloofsbriewe en aparte logboeke.

Metadata oorleef albei ontwerpe. Tydsberekening, pakketgroottes en verbindingstellings bly by elke sprong waarneembaar, so twee sprange verhoog die koste van korrelasie eerder as om die sein te verwyder. 'n Ontwerp wat onsigbaarheid belowe, moet teen daardie lys getoets word voordat iemand daarop vertrou.

Stap die foutpaaie deur voordat jy kies

Breek dinge doelbewus vanaf die kliënt, in die orde waarin 'n gebruiker dit sou teëkom. Begin met die koppelvlak en sy MTU, want nesteling faal by pakketgrootte lank voordat dit by verifikasie faal.

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

Bevestig dan die beskermingseindpunte in plaas daarvan om hulle te aanvaar. Vra die diens om sy sertifikaat van binne watter tonnel ook al op is, en vergelyk die ketting wat die kliënt sien met die ketting wat die diens werklik voorlê. 'n Poort wat heronderteken of onderskep, verander daardie sertifikaat, en die ondersoek word in 'n enkele opdrag sigbaar.

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

Eindig met die herverbindingsmatriks: die kliënt se tonnel val weg, B se tonnel val weg, die pad tussen A en B verander. Let op wat terugkom en wat nie, en of 'n binneste verbinding ooit terugval na 'n roete buite sy beoogde draer. Teken die adresse aan wat elke toets gebruik het, want om dit op 'n ander toegangsnetwerk te herhaal beantwoord 'n ander vraag. Herhaal ook die MTU-toets ná elke herverbinding, want 'n veranderde pad kan die bruikbare grootte verlaag sonder dat 'n enkele konfigurasie-reël beweeg.

Kies serieel wanneer A beleid op die binneste pakket moet toepas, of wanneer die kliënt nie twee gestapelde tonnels kan laat loop nie. Kies nesteling wanneer die binneste vrag by A onleesbaar moet bly. Skryf die keuse neer met sy waarnemers en sy MTU-syfers, en die volgende persoon hoef nie die hele prentjie te herteken om een vraag te antwoord nie.