To VPN-hopp på rad: hvem ser egentlig trafikken din?

Hver klientprofil navngir én server, så fra brukerens plass er det én tunnel og ett sted der beskyttelsen slutter. Det som skjer etter den første gatewayen, er en designbeslutning klienten aldri ser, og de to vanlige designene oppfører seg svært forskjellig under inspeksjon. I en seriell kjede dekrypterer den første gatewayen og krypterer på nytt. I en nestet kjede fjerner den et ytre lag og videresender en indre tunnel den ikke kan åpne. Antall hopp er identisk i begge, derfor må forskjellen tegnes og ikke telles.

Start ved klienten og navngi begge endene

Start der brukeren starter, i tilkoblingsprofilen. Den inneholder én ekstern adresse, én autentiseringsmetode og, når designet støtter det, en rutteliste. Merk den ytre tunnelen fra klienten til gateway A, og gi den eksempeladresser: klientens tunneladresse 10.77.0.2, A sin 10.77.0.1 og A sitt offentlige endepunkt 198.51.100.10, hentet fra TEST-NET-2-dokumentasjonsområdet slik at ingenting i eksempelet kan kollidere med en ekte vert.

Ingenting i den profilen nevner gateway B, og det er ikke en feil. Det andre hoppet tilhører A, og klientens eneste plikt er å levere trafikk til A og godta det som kommer tilbake. Om A avslutter tunnelen, videresender den eller åpner en ny, er spørsmålet resten av denne gjennomgangen besvarer, og det avgjør hva A kan lese.

Serielt: A dekrypterer, og krypterer deretter på nytt

I det serielle designet avslutter A trafikken to ganger. Den fjerner beskyttelsen fra klienten, henter applikasjonens IP-pakke og sender deretter den pakken gjennom en annen tunnel som A oppretter mot B. Mellom de to operasjonene ligger pakken i A sin videresendingsvei som en vanlig IP-pakke adressert til en privat destinasjon.

Det gir to konsekvenser det er verdt å si rett ut. A kan anvende policy på den indre pakken, i form av ruter, filterregler og logging av kilde og destinasjon, og A må holde to sett med påloggingsinformasjon: ett som server for klienten og ett som klient hos B. Beskyttelse finnes i hvert øyeblikk, men objektet som beskyttes, skifter identitet hos A.

Det følger ikke at A leser applikasjonens klartekst. Når klienten og tjenesten kjører TLS og verifiserer hverandres sertifikater, ser A en TLS-poststrøm i stedet for en lesbar forespørsel. Å bekrefte hvor den beskyttelsen slutter krever et blikk på tjenestens sertifikatkjede, ikke på tunneldiagrammet.

Nestet: A fjerner bare det ytre laget

I det nestede designet bygger klienten først en indre tunnel til B og bærer deretter den tunnelen inne i den ytre til A. A fjerner den ytre overskriften, finner en indre tunnel og videresender den uten å holde nøklene, så den indre beskyttelsen slutter fortsatt hos B.

Klientens oppstrømskobling bærer da to lag, mens veien mellom A og B bærer ett. A ser de ytre adressene til den indre tunnelen, noe som er nok til å vite at det finnes trafikk og omtrent hvor den er på vei, og ikke nok til å lese nyttelasten. Det er hele forskjellen fra det serielle tilfellet, og ingen hopp-teller viser det. Det A fortsatt kan gjøre, er å nekte å videresende det den ikke kan lese, og det er alltid tilgjengelig for operatøren av den gatewayen.

Nesting koster for den egenskapen. Hvert lag legger til overhead i overskriften, så MTU- og MSS-planlegging blir obligatorisk i stedet for ryddig, og en vei som fungerer med ett lag, kan stille miste store pakker med to. Hvert lag trenger også sin egen oppførsel for gjenoppkobling og keepalive, og en feil i ett lag ser ut som en delvis utfall gjennom det andre.

Tegn observatørene, ikke bare tunnelene

Tunnelene er den enkle delen av tegningen. Observatørene er det designet handler om, så skriv én rad per synspunkt og fyll ut hva hver av dem faktisk kan lese.

To rader blir stadig blandet sammen: operatøren av A og leverandøren av klientens tunnel. De kan være én enhet, og separate gateway-navn gjør dem ikke uavhengige. Uavhengig eierskap krever separat administrativ kontroll, separate påloggingsdata og separat logging.

Metadata overlever begge designene. Timing, pakkestørrelser og antall tilkoblinger forblir observerbare ved hvert hopp, så to hopp øker kostnaden ved korrelasjon i stedet for å fjerne signalet. Et design som lover usynlighet, bør holdes opp mot den listen før noen stoler på det.

Gå gjennom feilveiene før du velger

Ødelegg ting med vilje fra klienten, i den rekkefølgen en bruker ville møte dem. Start med grensesnittet og MTU-en, fordi nesting feiler på pakkestørrelse lenge før den feiler på autentisering.

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

Bekreft deretter beskyttelsens endepunkter i stedet for å anta dem. Be tjenesten om sertifikatet fra innsiden av den tunnelen som er oppe, og sammenlign kjeden klienten ser, med kjeden tjenesten faktisk presenterer. En gateway som signerer på nytt eller avlytter, endrer det sertifikatet, og inspeksjonen blir synlig i én kommando.

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

Avslutt med gjenoppkoblingsmatrisen: klientens tunnel faller, B sin tunnel faller, veien mellom A og B endres. Noter hva som kommer tilbake og hva som ikke gjør det, og om en indre tilkobling noen gang faller tilbake til en rute utenfor sin tiltenkte bærer. Registrer adressene hver test brukte, fordi å gjenta den på et annet aksessnettverk besvarer et annet spørsmål. Gjenta også MTU-testen etter hver gjenoppkobling, fordi en endret vei kan senke den brukbare størrelsen uten at én eneste konfigurasjonslinje flytter seg.

Velg serielt når A må anvende policy på den indre pakken, eller når klienten ikke kan kjøre to stablede tunneler. Velg nesting når den indre nyttelasten må forbli uleselig hos A. Skriv valget ned med observatørene og MTU-tallene, og neste person slipper å tegne hele bildet på nytt for å svare på ett spørsmål.