OpenVPN TUN versus TAP: drie voorwaarden die het beslissen

Twee tunnels kunnen dezelfde bestandsoverdracht vervoeren en toch volledig verschillen in wat ze op de draad zetten. De ene verplaatst IP-pakketten tussen twee adressen; de andere verplaatst Ethernet-frames en kan in een segment worden overbrugd. Dat verschil bepaalt welke toepassingen werken, welke clients kunnen verbinden en hoeveel netwerkontwerp je op je neemt.

In de praktijk beslechten drie voorwaarden het. Werk ze in volgorde af, want de eerste beëindigt meestal de discussie.

Wat elke interface werkelijk vervoert

Een TUN-apparaat is een punt-tot-punt-interface op laag 3: de kernel geeft het IP-pakketten en de tunnel vervoert ze naar een peeradres. Een TAP-apparaat is een interface op laag 2 die Ethernet-frames vervoert, en dat is juist wat overbruggen überhaupt mogelijk maakt, zoals de kerneldocumentatie beschrijft. Geen van beide verandert hoe de payload wordt versleuteld, en geen van beide is een sterkte-instelling. De keuze gaat over wat de eindpunten moeten uitwisselen, niet over hoe goed het verkeer is beschermd.

Eén gevolg volgt onmiddellijk: beide uiteinden moeten het eens zijn. Een client die voor het ene apparaattype is geconfigureerd, kan niet bij een server terecht die voor het andere is geconfigureerd, wat verder ook klopt.

Voorwaarde één: heeft iets laag twee nodig?

Overbruggen verdient zijn complexiteit wanneer een protocol echt hetzelfde broadcastdomein nodig heeft: niet-IP-verkeer, ontdekking die een router niet kan passeren, of een toepassing die erop staat in één segment te zitten. Al het andere is een routingprobleem, en routing lost dat met veel minder machinerie op. Een segment over een groot gebied uitbreiden breidt ook de broadcasts uit, waardoor luspreventie, adresplanning en foutdomeinen allemaal deel van het ontwerp worden. Dat is veel om te accepteren voor een eis die één enkele route zou hebben vervuld.

De test is concreet: noem de toepassing die op een gerouteerde tunnel faalt en zeg waarom. Als het antwoord is dat die broadcast nodig heeft, is laag twee het eerlijke antwoord. Als het antwoord is dat iemand één server niet kon bereiken, is de eis een route of een firewallregel.

Voorwaarde twee: kunnen de clients het?

De ondersteuning is niet uniform. Desktopclients bieden doorgaans beide apparaattypen, terwijl mobiele en embedded clients vaak alleen de gerouteerde modus implementeren, en een profiel dat zonder klachten importeert, kan alsnog falen wanneer het de interface probeert te maken. Controleer de specifieke client en versie in plaats van de functies uit de platformnaam af te leiden.

Een fout over een niet-ondersteunde optie is geen uitnodiging om onbekende regels te verwijderen tot de import lukt. Het betekent dat het profiel en de client het niet eens zijn over wat mogelijk is, en de reparatie hoort bij de operator die het profiel heeft uitgegeven. Een optie verwijderen om een validator stil te krijgen kan een verbinding opleveren die lijkt te werken terwijl die stilzwijgend de eigenschap weglaat waarvoor hij bestond.

Voorwaarde drie: is dit echt een interfacevraag?

Twee naburige keuzes krijgen de schuld van interfaceproblemen. Het virtuele apparaat bepaalt wat de tunnel in gaat, terwijl UDP of TCP bepaalt hoe het buitenste transport zich gedraagt, en geen van beide geneest overdrachten die vastlopen. Als grote overdrachten blijven hangen terwijl kleine slagen, verdienen pakketgrootte en MTU eerder de aandacht.

Een client die verbindt en dan één interne host niet bereikt, kijkt meestal naar routing, een firewallregel of een ontbrekend retourpad.

Gebruik voor een beheerde dienst de interface-indeling die het profiel van de operator voorschrijft, want de serverkant is daar al omheen gebouwd. Kies voor een eigen implementatie op basis van de werkelijke eis van de toepassing en schrijf de reden naast de keuze.

De vraag is niet welke optie sterker is. Het is welke het verkeer werkelijk nodig heeft.