En tunnel kjøper topologi, ikke kryptering eller latens

Antakelsen er at en tunnel er en privat, rask ledning: du bygger den, og trafikken inni er kryptert, veien er kortere, og forbindelsen oppfører seg som en kabel mellom to steder. Hver del av den antakelsen er en egen egenskap, og tunnelen leverer bare det første du ba den om, nemlig en logisk vei. Alt annet må velges og konfigureres med vilje. Å blande egenskapene er hvordan et design ender med en kryptert forbindelse ingen kan feilsøke, og et løfte om latens ingen kan holde.

Myten: én tunnel, tre garantier

En tunnel gjør én ting pålitelig. Den får to endepunkter som ikke er direkte koblet sammen til å oppføre seg som naboer for et eller annet formål, mens nettet imellom bærer de ytre pakkene. Det er en topologiendring, og den er virkelig nyttig i seg selv.

Kryptering, protokolltransport og videresendingsisolering er separate beslutninger lagt oppå. En GRE-tunnel har ingen av de tre i kryptografisk forstand, og en IP-in-IP-tunnel er et gyldig design helt uten konfidensialitet. Ingen av dem er en feil; det er tunneler som gjør nøyaktig det tunneler gjør. Etiketten på diagrammet forteller ikke hvilke egenskaper som er til stede.

Når du skiller egenskapene, blir spørsmålene besvarlige: bærer denne tunnelen et rutenaboskap, bærer den rammer, skjuler den de indre adressene, lover den noe om forsinkelse? Det er fire ulike svar med fire ulike konfigurasjonskonsekvenser.

Hva tunnelen faktisk tilfører kartet

Endepunktene får en vei de ikke hadde før. Om den veien oppfører seg som et rutet hopp eller som et Ethernet-segment avhenger helt av innkapslingen, og forskjellen endrer hva de to stedene kan gjøre med den. En rutet tunnel gir deg et neste hopp og et prefiks; en Ethernet-utvidelse gir deg kringkastingsadferd og et mye større feildomene.

En IP-tunnel gjør ikke automatisk det fjerne stedet til en del av samme subnett, og den får ikke en rutingsprotokoll til å kjøre over den med mindre implementasjonen støtter det naboskapet. Multicast er et annet separat spørsmål med sitt eget svar.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

De kommandoene besvarer ulike deler av spørsmålet. Den første forteller hvilken type grensesnitt som finnes, den andre forteller hvilken vei kjernen ville velge, og de to siste viser underlagets faktiske oppførsel i stedet for etikettens løfte.

Transport er en separat beslutning fra rekkevidde

En tunnel kan bære en protokoll som underlaget ikke videresender. IPv6 over en IPv4-vei er det klassiske tilfellet, og det virker fordi endepunktene forstår begge familiene, mens rutene mellom dem bare trenger å levere de ytre pakkene. Underlaget trenger en fungerende vei til tunnelendepunktet og ingenting mer.

Endepunktene trenger derimot full støtte: videresending, adresser og en applikasjon som faktisk bruker den indre familien. Å tildele et IPv6-prefiks til en tunnel gjør ikke en tjeneste som bare kjører IPv4 tilgjengelig over IPv6, og det gjør ikke underlaget dual-stack.

Rammetransport er en større forpliktelse enn protokolltransport. Å utvide et kringkastingsdomene over en tunnel flytter spanning-tree-adferd, ARP og feilutbredelse med seg, noe som er en designbeslutning og ikke en funksjonsbryter.

Isolering er ikke konfidensialitet

Tilbyder-VPN-er holder kundenes ruter og trafikk i separate videresendingskontekster, og den separasjonen er reell og verdifull. Det er ikke kryptering. BGP/MPLS VPN-spesifikasjonen sier uttrykkelig at personvernet kommer fra videresendingsmodellen og ikke fra kryptografi, og det er nettopp den forskjellen som går tapt i en slide som bare sier VPN.

Hvis du trenger konfidensialitet, trenger du en kryptografisk mekanisme med autentisering og nøkkeladministrasjon, og du må vite hvor den slutter. En tunnel som gir separasjon, og en tunnel som gir kryptering, kan være samme tunnel, men bare når noen har konfigurert begge.

Den praktiske konsekvensen er at «det er i en VPN» besvarer et spørsmål om rutingskontekst og ikke forteller deg noe om hvem som kan lese bytene på veien. To team kan begge ha rett og likevel beskrive forskjellige ting. Når sikkerhetsspørsmålet kommer opp, spør hvor kryptografien slutter og hva som autentiserer partene, ikke om det finnes en tunnel.

Latens og QoS følger underlaget

En logisk kant er ikke en kortere fysisk vei. De ytre pakkene går fortsatt gjennom de samme koblingene, køene og leverandørene, og innkapsling legger til overhead per pakke pluss behandling i begge ender. En tunnel kan være rask fordi underlaget er godt, aldri fordi den er en tunnel.

Behandling av tjenestekvalitet er verre enn det, fordi den avhenger av administrative domener du kanskje ikke kontrollerer. Indre merker må bevisst mappes til ytre merker, og hver leverandør på veien må tilby behandlingen du forventer. Kryptering skaper ikke prioritet; den skjuler feltet en mellomliggende boks kanskje hadde brukt til å klassifisere flyten.

Mål underlaget før du lover noe. En rapport som viser stabil forsinkelse og ingen tap på den ytre veien, er bevis; et diagram med en tunnel på er det ikke.

Velg tunnelen for nettverksforholdet du trenger, og angi deretter kryptering, tilgangspolicy, pakkestørrelse og ytelse hver for seg. Fire beslutninger, fire bevis, og ingen enkel etikett som står i stedet for noen av dem.