En tunnel køber topologi, ikke kryptering eller latenstid

Antagelsen er, at en tunnel er en privat, hurtig ledning: du bygger den, og trafikken indeni er krypteret, vejen er kortere, og forbindelsen opfører sig som et kabel mellem to steder. Hver del af den antagelse er en separat egenskab, og tunnelen leverer kun det første, du bad den om, nemlig en logisk vej. Alt andet skal vælges og konfigureres med vilje. At blande egenskaberne sammen er, hvordan et design ender med en krypteret forbindelse, som ingen kan fejlsøge, og et løfte om latenstid, som ingen kan holde.

Myten: én tunnel, tre garantier

En tunnel gør én ting pålideligt. Den får to endepunkter, der ikke er direkte forbundet, til at opføre sig som naboer til et eller andet formål, mens netværket imellem bærer de ydre pakker. Det er en topologiændring, og den er virkelig nyttig i sig selv.

Kryptering, protokoltransport og videresendelsesisolering er separate beslutninger ovenpå. En GRE-tunnel har ingen af de tre i kryptografisk forstand, og en IP-in-IP-tunnel er et gyldigt design helt uden fortrolighed. Ingen af dem er en fejl; de er tunneler, der gør præcis det, tunneler gør. Etiketten på diagrammet fortæller ikke, hvilke egenskaber der er til stede.

Når du adskiller egenskaberne, bliver spørgsmålene besvarlige: bærer denne tunnel et routingnaboskab, bærer den rammer, skjuler den de indre adresser, lover den noget om forsinkelse? Det er fire forskellige svar med fire forskellige konfigurationskonsekvenser.

Hvad tunnelen faktisk tilføjer til kortet

Endepunkterne får en vej, de ikke havde før. Om den vej opfører sig som et routet hop eller som et Ethernet-segment, afhænger helt af indkapslingen, og forskellen ændrer, hvad de to steder kan gøre med den. En routet tunnel giver dig et næste hop og et præfiks; en Ethernet-udvidelse giver dig broadcastadfærd og et meget større fejldomæne.

En IP-tunnel gør ikke automatisk det fjerne sted til en del af det samme undernet, og den får ikke en routingprotokol til at køre over den, medmindre implementeringen understøtter det naboskab. Multicast er endnu et separat spørgsmål med sit 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 kommandoer besvarer forskellige dele af spørgsmålet. Den første fortæller, hvilken type interface der findes, den anden fortæller, hvilken vej kernen ville vælge, og de sidste to viser underlagets faktiske adfærd i stedet for etikettens løfte.

Transport er en separat beslutning fra rækkevidde

En tunnel kan bære en protokol, som underlaget ikke videresender. IPv6 over en IPv4-vej er det klassiske tilfælde, og det virker, fordi endepunkterne forstår begge familier, mens routerne imellem dem kun skal levere de ydre pakker. Underlaget har brug for en fungerende vej til tunnelendepunktet og intet mere.

Endepunkterne har dog brug for fuld støtte: videresendelse, adresser og en applikation, der faktisk bruger den indre familie. At tildele et IPv6-præfiks til en tunnel gør ikke en tjeneste, der kun kører IPv4, tilgængelig over IPv6, og det gør ikke underlaget dual-stack.

Rammetransport er en større forpligtelse end protokoltransport. At udvide et broadcastdomæne over en tunnel flytter spanning-tree-adfærd, ARP og fejludbredelse med sig, hvilket er en designbeslutning og ikke en funktionskontakt.

Isolering er ikke fortrolighed

UdbydervPN'er holder kundernes ruter og trafik i separate videresendelseskontekster, og den adskillelse er reel og værdifuld. Det er ikke kryptering. BGP/MPLS VPN-specifikationen siger udtrykkeligt, at dens privatliv kommer fra videresendelsesmodellen og ikke fra kryptografi, og det er netop den forskel, der går tabt i et slide, der bare siger VPN.

Hvis du har brug for fortrolighed, har du brug for en kryptografisk mekanisme med autentificering og nøglestyring, og du skal vide, hvor den slutter. En tunnel, der giver adskillelse, og en tunnel, der giver kryptering, kan være den samme tunnel, men kun når nogen har konfigureret begge.

Den praktiske konsekvens er, at „det er i en VPN“ besvarer et spørgsmål om routingkontekst og ikke fortæller dig noget om, hvem der kan læse byte på vejen. To teams kan begge have ret og stadig beskrive forskellige ting. Når sikkerhedsspørgsmålet kommer op, så spørg hvor kryptografien slutter og hvad der autentificerer parterne, ikke om der findes en tunnel.

Latenstid og QoS følger underlaget

En logisk kant er ikke en kortere fysisk vej. De ydre pakker gennemløber stadig de samme links, køer og udbydere, og indkapsling tilføjer overhead per pakke plus behandling i begge ender. En tunnel kan være hurtig, fordi underlaget er godt, aldrig fordi den er en tunnel.

Behandling af servicekvalitet er værre end det, fordi den afhænger af administrative domæner, som du måske ikke kontrollerer. Indre markeringer skal bevidst mappes til ydre markeringer, og hver udbyder på vejen skal tilbyde den behandling, du forventer. Kryptering skaber ikke prioritet; den skjuler det felt, en mellemboks måske havde brugt til at klassificere strømmen.

Mål underlaget, før du lover noget. En rapport, der viser stabil forsinkelse og ingen tab på den ydre vej, er bevis; et diagram med en tunnel på er ikke.

Vælg tunnelen efter det netværksforhold, du har brug for, og angiv derefter kryptering, adgangspolitik, pakkestørrelse og ydeevne hver for sig. Fire beslutninger, fire beviser, og ingen enkelt etiket, der står i stedet for nogen af dem.