Een tunnel koopt topologie, niet versleuteling of latentie

De aanname is dat een tunnel een private, snelle draad is: je bouwt er een, en het verkeer erin is versleuteld, het pad is korter en de verbinding gedraagt zich als een kabel tussen twee locaties. Elk deel van die aanname is een afzonderlijke eigenschap, en de tunnel levert alleen het eerste dat je ervan vroeg, namelijk een logisch pad. Al het andere moet bewust worden gekozen en geconfigureerd. De eigenschappen verwarren is hoe een ontwerp eindigt met een versleutelde verbinding die niemand kan troubleshooten en een latentiebelofte die niemand kan nakomen.

De mythe: één tunnel, drie garanties

Een tunnel doet één ding betrouwbaar. Hij zorgt dat twee eindpunten die niet direct verbonden zijn zich gedragen alsof ze voor een doel naast elkaar liggen, terwijl het netwerk ertussen de buitenste pakketten vervoert. Dat is een topologiewijziging, en die is op zichzelf echt nuttig.

Versleuteling, protocoltransport en doorstuurisolatie zijn afzonderlijke beslissingen die erbovenop liggen. Een GRE-tunnel heeft in cryptografische zin geen van de drie, en een IP-in-IP-tunnel is een geldig ontwerp zonder enige vertrouwelijkheid. Geen van beide is een fout; het zijn tunnels die precies doen wat tunnels doen. Het label op het diagram vertelt niet welke eigenschappen aanwezig zijn.

Zodra je de eigenschappen scheidt, worden de vragen beantwoordbaar: draagt deze tunnel een routing-buurrelatie, draagt hij frames, verbergt hij de interne adressen, belooft hij iets over vertraging? Dat zijn vier verschillende antwoorden met vier verschillende configuratiegevolgen.

Wat de tunnel feitelijk aan de kaart toevoegt

De eindpunten krijgen een pad dat ze eerder niet hadden. Of dat pad zich gedraagt als een gerouteerde hop of als een Ethernet-segment hangt volledig af van de inkapseling, en het verschil verandert wat de twee locaties ermee kunnen doen. Een gerouteerde tunnel geeft je een volgende hop en een prefix; een Ethernet-uitbreiding geeft je broadcastgedrag en een veel groter foutdomein.

Een IP-tunnel maakt de externe locatie niet automatisch deel van hetzelfde subnet, en laat er geen routingprotocol over lopen tenzij de implementatie die buurrelatie ondersteunt. Multicast is een andere afzonderlijke vraag met zijn eigen antwoord.

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

Die commando's beantwoorden verschillende delen van de vraag. De eerste zegt welk type interface bestaat, de tweede zegt welk pad de kernel zou kiezen, en de laatste twee tonen het werkelijke gedrag van de onderlaag in plaats van de belofte van het label.

Transport is een afzonderlijke beslissing van bereikbaarheid

Een tunnel kan een protocol dragen dat de onderlaag niet doorstuurt. IPv6 over een IPv4-pad is het klassieke geval, en het werkt omdat de eindpunten beide families begrijpen terwijl de routers ertussen alleen de buitenste pakketten hoeven af te leveren. De onderlaag heeft een werkend pad naar het tunneleindpunt nodig en niets meer.

De eindpunten hebben echter volledige ondersteuning nodig: doorsturen, adressen en een applicatie die de interne familie echt gebruikt. Een IPv6-prefix aan een tunnel toewijzen maakt een dienst die alleen met IPv4 werkt niet bereikbaar via IPv6, en maakt de onderlaag niet dual-stack.

Frametransport is een grotere verplichting dan protocoltransport. Een broadcastdomein over een tunnel uitbreiden verplaatst spanning-treegedrag, ARP en foutpropagatie mee, wat een ontwerpbeslissing is en geen functieschakelaar.

Isolatie is geen vertrouwelijkheid

Provider-VPN's houden klantroutes en -verkeer in aparte doorstuurcontexten, en die scheiding is echt en waardevol. Het is geen versleuteling. De BGP/MPLS VPN-specificatie zegt uitdrukkelijk dat de privacy uit het doorstuurmodel komt en niet uit cryptografie, en dat is precies het onderscheid dat verloren gaat in een slide die alleen VPN zegt.

Als je vertrouwelijkheid nodig hebt, heb je een cryptografisch mechanisme met authenticatie en sleutelbeheer nodig, en je moet weten waar het eindigt. Een tunnel die scheiding biedt en een tunnel die versleuteling biedt kunnen dezelfde tunnel zijn, maar alleen wanneer iemand beide heeft geconfigureerd.

Het praktische gevolg is dat „het zit in een VPN“ een vraag over de routingcontext beantwoordt en je niets zegt over wie de bytes op het pad kan lezen. Twee teams kunnen beiden gelijk hebben en toch verschillende dingen beschrijven. Als de beveiligingsvraag opkomt, vraag dan waar de cryptografie eindigt en wat de peers authenticeert, niet of er een tunnel bestaat.

Latentie en QoS volgen de onderlaag

Een logische rand is geen korter fysiek pad. De buitenste pakketten gaan nog steeds door dezelfde links, wachtrijen en providers, en inkapseling voegt overhead per pakket plus verwerking aan beide uiteinden toe. Een tunnel kan snel zijn omdat de onderlaag goed is, nooit omdat het een tunnel is.

De behandeling van kwaliteit van dienst is erger dan dat, omdat die afhangt van administratieve domeinen die je misschien niet beheert. Interne markeringen moeten bewust op externe worden afgebeeld, en elke provider op het pad moet de behandeling bieden die je verwacht. Versleuteling maakt geen prioriteit; het verbergt het veld dat een tussenbox had kunnen gebruiken om de stroom te classificeren.

Meet de onderlaag voordat je iets belooft. Een rapport dat stabiele vertraging en geen verlies op het buitenste pad laat zien, is bewijs; een diagram met een tunnel erop is dat niet.

Kies de tunnel voor de netwerkrelatie die je nodig hebt, en specificeer daarna versleuteling, toegangsbeleid, pakketgrootte en prestaties afzonderlijk. Vier beslissingen, vier bewijzen, en geen enkel label dat voor een van hen in de plaats staat.