To VPN-hopp på rad: kven ser eigentleg trafikken din?

Kvar klientprofil namngir éin server, så frå brukaren si side er det éin tunnel og ein stad der vernet sluttar. Det som skjer etter den første gatewayen, er eit designval klienten aldri ser, og dei to vanlege designa oppfører seg svært ulikt under inspeksjon. I ein seriell kjede dekrypterer den første gatewayen og krypterer på nytt. I ein nesta kjede fjernar han eit ytre lag og sender vidare ein indre tunnel han ikkje kan opne. Talet på hopp er identisk i båe, difor må skilnaden teiknast og ikkje teljast.

Start ved klienten og namngi båe endane

Start der brukaren startar, i tilkoplingsprofilen. Han inneheld éi ekstern adresse, éin autentiseringsmetode og, når designet støttar det, ei rutteliste. Merk den ytre tunnelen frå klienten til gateway A, og gje han døme på adresser: tunneladressa til klienten 10.77.0.2, A si 10.77.0.1 og det offentlege endepunktet til A 198.51.100.10, henta frå TEST-NET-2-dokumentasjonsområdet slik at ingenting i dømet kan kollidere med ein ekte vert.

Ingenting i den profilen nemner gateway B, og det er ikkje ein feil. Det andre hoppet høyrer til A, og den einaste plikta til klienten er å levere trafikk til A og ta imot det som kjem tilbake. Om A avsluttar tunnelen, sender han vidare eller opnar ein ny, er spørsmålet resten av denne gjennomgangen svarar på, og det avgjer kva A kan lese.

Serielt: A dekrypterer og krypterer deretter på nytt

I det serielle designet avsluttar A trafikken to gonger. Han fjernar vernet frå klienten, hentar IP-pakken til programmet og sender deretter den pakken gjennom ein annan tunnel som A opprettar mot B. Mellom dei to operasjonane ligg pakken i videresendingsvegen til A som ein vanleg IP-pakke adressert til ein privat destinasjon.

Det gjev to konsekvensar det er verdt å seie rett ut. A kan bruke policy på den indre pakken, i form av ruter, filterreglar og logging av kjelde og destinasjon, og A må halde to sett med innloggingsdata: eitt som server for klienten og eitt som klient hos B. Vern finst i kvart augneblink, men objektet som vert verna, skiftar identitet hos A.

Det følgjer ikkje at A les klarteksten til programmet. Når klienten og tenesta køyrer TLS og stadfestar kvarandre sine sertifikat, ser A ein TLS-poststraum i staden for ein lesbar førespurnad. Å stadfeste kvar det vernet sluttar krev eit blikk på sertifikatkjeda til tenesta, ikkje på tunneldiagrammet.

Nesta: A fjernar berre det ytre laget

I det nesta designet byggjer klienten først ein indre tunnel til B og ber deretter den tunnelen inne i den ytre til A. A fjernar den ytre overskrifta, finn ein indre tunnel og sender han vidare utan å halde nyklane, så det indre vernet sluttar framleis hos B.

Klienten sin oppstraumsveg ber då to lag, medan vegen mellom A og B ber eitt. A ser dei ytre adressene til den indre tunnelen, noko som er nok til å vite at det finst trafikk og om lag kvar han er på veg, og ikkje nok til å lese nyttelasta. Det er heile skilnaden frå det serielle tilfellet, og ingen hoppteljar viser det. Det A framleis kan gjere, er å nekte å sende vidare det han ikkje kan lese, og det er alltid tilgjengeleg for operatøren av den gatewayen.

Nesting kostar for den eigenskapen. Kvart lag legg til overhead i overskrifta, så MTU- og MSS-planlegging vert obligatorisk i staden for ryddig, og ein veg som fungerer med eitt lag, kan stille miste store pakkar med to. Kvart lag treng òg si eiga åtferd for attoppkopling og keepalive, og ein feil i eitt lag ser ut som eit delvis utfall gjennom det andre.

Teikn observatørane, ikkje berre tunnelane

Tunnelane er den enkle delen av teikninga. Observatørane er det designet handlar om, så skriv éi rad per synsstad og fyll ut kva kvar av dei faktisk kan lese.

To rader vert stadig blanda saman: operatøren av A og leverandøren av tunnelen til klienten. Dei kan vere éi eining, og separate gateway-namn gjer dei ikkje uavhengige. Uavhengig eigarskap krev separat administrativ kontroll, separate innloggingsdata og separat logging.

Metadata overlever båe designa. Timing, pakkestorleikar og talet på tilkoplingar held fram med å vere observerbare ved kvart hopp, så to hopp aukar kostnaden ved korrelasjon i staden for å fjerne signalet. Eit design som lovar usynlegheit, bør haldast opp mot den lista før nokon stolar på det.

Gå gjennom feilvegane før du vel

Øydelegg ting med vilje frå klienten, i den rekkjefølgja ein brukar ville møte dei. Start med grensesnittet og MTU-en, fordi nesting feilar på pakkestorleik lenge før han feilar 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

Stadfest deretter endepunkta til vernet i staden for å anta dei. Be tenesta om sertifikatet frå innsida av den tunnelen som er open, og samanlikn kjeda klienten ser, med kjeda tenesta faktisk legg fram. Ein gateway som signerer på nytt eller avlyttar, endrar det sertifikatet, og inspeksjonen vert synleg i éin kommando.

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

Avslutt med attoppkoplingsmatrisa: tunnelen til klienten fell, tunnelen til B fell, vegen mellom A og B endrar seg. Noter kva som kjem tilbake og kva som ikkje gjer det, og om ei indre tilkopling nokon gong fell tilbake til ei rute utanfor den tiltenkte beraren. Registrer adressene kvar test brukte, fordi å gjenta han på eit anna aksessnettverk svarar på eit anna spørsmål. Gjenta òg MTU-testen etter kvar attoppkopling, fordi ein endra veg kan senke den brukbare storleiken utan at éi einaste konfigurasjonslinje flyttar seg.

Vel serielt når A må bruke policy på den indre pakken, eller når klienten ikkje kan køyre to stabla tunnelar. Vel nesting når den indre nyttelasta må halde fram med å vere uleseleg hos A. Skriv valet ned med observatørane og MTU-tala, og neste person slepp å teikne heile biletet på nytt for å svare på eitt spørsmål.