Ein tunnel kjøper topologi, ikkje kryptering eller latens

Føresetnaden er at ein tunnel er ein privat, rask leidning: du byggjer han, og trafikken inni er kryptert, vegen er kortare, og sambandet oppfører seg som ein kabel mellom to stader. Kvar del av den føresetnaden er ein eigen eigenskap, og tunnelen leverer berre det første du bad han om, nemleg ein logisk veg. Alt anna må veljast og konfigurerast med vilje. Å blande eigenskapane er korleis eit design endar med eit kryptert samband ingen kan feilsøkje, og eit løfte om latens ingen kan halde.

Myten: éin tunnel, tre garantiar

Ein tunnel gjer éin ting påliteleg. Han får to endepunkt som ikkje er direkte kopla saman til å oppføre seg som naboar for eit eller anna føremål, medan nettet imellom ber dei ytre pakkane. Det er ei topologiendring, og ho er verkeleg nyttig i seg sjølv.

Kryptering, protokolltransport og vidaresendingsisolering er separate avgjerder lagde oppå. Ein GRE-tunnel har ingen av dei tre i kryptografisk forstand, og ein IP-in-IP-tunnel er eit gyldig design heilt utan konfidensialitet. Ingen av dei er ein feil; det er tunnelar som gjer nøyaktig det tunnelar gjer. Etiketten på diagrammet fortel ikkje kva eigenskapar som er til stades.

Når du skil eigenskapane, blir spørsmåla svarlege: ber denne tunnelen eit rutenaboskap, ber han rammer, skjuler han dei indre adressene, lovar han noko om forseinking? Det er fire ulike svar med fire ulike konfigurasjonskonsekvensar.

Kva tunnelen faktisk legg til på kartet

Endepunkta får ein veg dei ikkje hadde før. Om den vegen oppfører seg som eit ruta hopp eller som eit Ethernet-segment, kjem heilt an på innkapslinga, og skilnaden endrar kva dei to stadene kan gjere med han. Ein ruta tunnel gir deg eit neste hopp og eit prefiks; ei Ethernet-utviding gir deg kringkastingsåtferd og eit mykje større feildomene.

Ein IP-tunnel gjer ikkje automatisk den fjerne staden til ein del av same subnett, og han får ikkje ein rutingsprotokoll til å køyre over han med mindre implementasjonen støttar det naboskapet. Multicast er eit anna separat spørsmål med sitt eige 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

Dei kommandoane svarar på ulike delar av spørsmålet. Den første fortel kva type grensesnitt som finst, den andre fortel kva veg kjernen ville velje, og dei to siste viser den faktiske åtferda til underlaget i staden for løftet til etiketten.

Transport er ei separat avgjerd frå rekkjevidd

Ein tunnel kan bere ein protokoll som underlaget ikkje vidaresender. IPv6 over ein IPv4-veg er det klassiske tilfellet, og det verkar fordi endepunkta forstår begge familiane, medan rutarane mellom dei berre treng å levere dei ytre pakkane. Underlaget treng ein fungerande veg til tunnelendepunktet og ingenting meir.

Endepunkta treng derimot full støtte: vidaresending, adresser og ein applikasjon som faktisk brukar den indre familien. Å gi eit IPv6-prefiks til ein tunnel gjer ikkje ein teneste som berre køyrer IPv4 tilgjengeleg over IPv6, og det gjer ikkje underlaget dual-stack.

Rammetransport er ei større forplikting enn protokolltransport. Å utvide eit kringkastingsdomene over ein tunnel flyttar spanning-tree-åtferd, ARP og feilutbreiing med seg, noko som er eit designval og ikkje ein funksjonsbrytar.

Isolering er ikkje konfidensialitet

Tilbydar-VPN-ar held kundane sine ruter og trafikk i separate vidaresendingskontekstar, og den separasjonen er reell og verdifull. Det er ikkje kryptering. BGP/MPLS VPN-spesifikasjonen seier uttrykkeleg at personvernet kjem frå vidaresendingsmodellen og ikkje frå kryptografi, og det er nettopp den skilnaden som går tapt i ein slide som berre seier VPN.

Viss du treng konfidensialitet, treng du ein kryptografisk mekanisme med autentisering og nøkkeladministrasjon, og du må vite kvar han sluttar. Ein tunnel som gir separasjon, og ein tunnel som gir kryptering, kan vere same tunnel, men berre når nokon har konfigurert begge.

Den praktiske konsekvensen er at «det er i ein VPN» svarar på eit spørsmål om rutingskontekst og ikkje fortel deg noko om kven som kan lese byta på vegen. To team kan begge ha rett og likevel skildre ulike ting. Når tryggleiksspørsmålet kjem opp, spør kvar kryptografien sluttar og kva som autentiserer partane, ikkje om det finst ein tunnel.

Latens og QoS følgjer underlaget

Ein logisk kant er ikkje ein kortare fysisk veg. Dei ytre pakkane går framleis gjennom dei same koplingane, køane og leverandørane, og innkapsling legg til overhead per pakke pluss handsaming i begge endar. Ein tunnel kan vere rask fordi underlaget er godt, aldri fordi han er ein tunnel.

Handsaming av tenestekvalitet er verre enn det, fordi ho avheng av administrative domene du kanskje ikkje kontrollerer. Indre merke må med vilje mappast til ytre merke, og kvar leverandør på vegen må tilby handsaminga du forventar. Kryptering skapar ikkje prioritet; ho skjuler feltet ein mellomliggande boks kanskje hadde brukt til å klassifisere flyten.

Mål underlaget før du lovar noko. Ein rapport som viser stabil forseinking og ingen tap på den ytre vegen, er bevis; eit diagram med ein tunnel på er det ikkje.

Vel tunnelen for nettverksforholdet du treng, og angi deretter kryptering, tilgangspolicy, pakkestorleik og yting kvar for seg. Fire avgjerder, fire bevis, og ingen enkel etikett som står i staden for nokon av dei.