To VPN-hop i træk: hvem ser egentlig din trafik?

Hver klientprofil nævner én server, så fra brugerens plads er der én tunnel og ét sted, hvor beskyttelsen slutter. Hvad der sker efter den første gateway, er en designbeslutning, som klienten aldrig ser, og de to almindelige designs opfører sig meget forskelligt under inspektion. I en seriel kæde dekrypterer den første gateway og genkrypterer. I en indlejret kæde fjerner den et ydre lag og videresender en indre tunnel, som den ikke kan åbne. Antallet af hop er identisk i begge, og derfor skal forskellen tegnes frem for tælles.

Start ved klienten, og navngiv begge ender

Start, hvor brugeren starter, i forbindelsesprofilen. Den indeholder én fjernadresse, én godkendelsesmetode og, når designet understøtter det, en rutteliste. Mærk den ydre tunnel fra klienten til gateway A, og giv den eksempeladresser: klientens tunneladresse 10.77.0.2, A's 10.77.0.1 og A's offentlige endepunkt 198.51.100.10, taget fra TEST-NET-2-dokumentationsområdet, så intet i eksemplet kan kollidere med en rigtig vært.

Intet i den profil nævner gateway B, og det er ikke en fejl. Det andet hop tilhører A, og klientens eneste forpligtelse er at levere trafik til A og acceptere det, der kommer tilbage. Om A afslutter tunnelen, videresender den eller åbner en ny, er det spørgsmål, som resten af denne gennemgang besvarer, og det afgør, hvad A kan læse.

Serielt: A dekrypterer og genkrypterer derefter

I det serielle design afslutter A trafik to gange. Den fjerner beskyttelsen fra klienten, får applikationens IP-pakke og sender derefter den pakke gennem en anden tunnel, som A opretter mod B. Mellem de to operationer ligger pakken i A's videresendelsesvej som en almindelig IP-pakke adresseret til en privat destination.

Det giver to konsekvenser, som er værd at sige ligeud. A kan anvende politik på den indre pakke i form af ruter, filterregler og logning af kilde og destination, og A skal holde to sæt legitimationsoplysninger: ét som server for klienten og ét som klient hos B. Beskyttelse findes i hvert øjeblik, men det objekt, der beskyttes, skifter identitet hos A.

Det betyder ikke, at A læser applikationens klartekst. Når klienten og tjenesten kører TLS og verificerer hinandens certifikater, ser A en TLS-poststrøm i stedet for en læsbar anmodning. At bekræfte, hvor den beskyttelse slutter, kræver et kig på tjenestens certifikatkæde, ikke på tunneldiagrammet.

Indlejret: A fjerner kun det ydre lag

I det indlejrede design bygger klienten først en indre tunnel til B og bærer derefter den tunnel inde i den ydre til A. A fjerner det ydre header, finder en indre tunnel og videresender den uden at holde dens nøgler, så den indre beskyttelse stadig slutter hos B.

Klientens uplink bærer så to lag, mens vejen mellem A og B bærer ét. A ser den indre tunnels ydre adresser, hvilket er nok til at vide, at der er trafik, og nogenlunde hvor den er på vej hen, og ikke nok til at læse nyttelasten. Det er hele forskellen fra det serielle tilfælde, og ingen hop-tæller viser det. Hvad A stadig kan gøre, er at nægte at videresende det, den ikke kan læse, og det er altid tilgængeligt for operatøren af den gateway.

Indlejring koster for den egenskab. Hvert lag tilføjer header-overhead, så MTU- og MSS-planlægning bliver obligatorisk i stedet for ryddelig, og en vej, der virker med ét lag, kan lydløst tabe store pakker med to. Hvert lag kræver også sin egen genopkoblings- og keepalive-adfærd, og en fejl i ét lag ser ud som en delvis afbrydelse gennem det andet.

Tegn observatørerne, ikke kun tunnelerne

Tunnelerne er den nemme del af tegningen. Observatørerne er det, designet handler om, så skriv en række per udsigtspunkt, og udfyld, hvad hver af dem faktisk kan læse.

To rækker bliver konstant forvekslet: operatøren af A og udbyderen af klientens tunnel. De kan være én enhed, og separate gateway-navne gør dem ikke uafhængige. Uafhængigt ejerskab kræver separat administrativ kontrol, separate legitimationsoplysninger og separat logning.

Metadata overlever begge designs. Timing, pakkestørrelser og forbindelsesantal forbliver observerbare ved hvert hop, så to hop hæver prisen for korrelation i stedet for at fjerne signalet. Et design, der lover usynlighed, bør holdes op mod den liste, før nogen stoler på det.

Gå fejlvejene igennem, før du vælger

Ødelæg ting med vilje fra klienten, i den rækkefølge en bruger ville møde dem. Start med grænsefladen og dens MTU, fordi indlejring fejler på pakkestørrelse længe før, den fejler på godkendelse.

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

Bekræft derefter beskyttelsens endepunkter i stedet for at antage dem. Bed tjenesten om dens certifikat inde fra den tunnel, der er oppe, og sammenlign den kæde, klienten ser, med den kæde, tjenesten faktisk præsenterer. En gateway, der gensignerer eller opsnapper, ændrer det certifikat, og inspektionen bliver synlig i én kommando.

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

Slut af med genopkoblingsmatricen: klientens tunnel falder, B's tunnel falder, vejen mellem A og B ændres. Noter, hvad der vender tilbage, og hvad der ikke gør, og om en indre forbindelse nogensinde falder tilbage til en rute uden for sin tilsigtede bærer. Registrer de adresser, hver test brugte, fordi gentagelse på et andet adgangsnetværk besvarer et andet spørgsmål. Gentag også MTU-proben efter hver genopkobling, fordi en ændret vej kan sænke den brugbare størrelse, uden at en eneste konfigurationslinje flytter sig.

Vælg serielt, når A skal anvende politik på den indre pakke, eller når klienten ikke kan køre to stablede tunneler. Vælg indlejring, når den indre nyttelast skal forblive ulæselig hos A. Skriv valget ned med dets observatører og dets MTU-tal, så skal den næste person ikke tegne hele billedet igen for at besvare ét spørgsmål.