OpenVPN TUN vs. TAP: tre betingelser afgør valget

To tunneller kan bære den samme filoverførsel og være helt forskellige i det, de lægger på ledningen. Den ene flytter IP-pakker mellem to adresser; den anden flytter Ethernet-frames og kan brobygges ind i et segment. Forskellen afgør, hvilke applikationer der virker, hvilke klienter der kan forbinde, og hvor meget netværksdesign du skriver under på.

Tre betingelser afgør det i praksis. Gå dem igennem i rækkefølge, for den første afslutter normalt diskussionen.

Hvad hver grænseflade faktisk bærer

En TUN-enhed er en punkt-til-punkt-grænseflade på lag 3: kernen giver den IP-pakker, og tunnelen bærer dem til en peer-adresse. En TAP-enhed er en grænseflade på lag 2, der bærer Ethernet-frames, og det er netop det, der overhovedet gør brobygning mulig, som kernens dokumentation beskriver. Ingen af dem ændrer, hvordan nyttelasten krypteres, og ingen af dem er en styrkeindstilling. Valget handler om, hvad endepunkterne skal udveksle, ikke om hvor godt trafikken er beskyttet.

En konsekvens følger med det samme: begge ender skal være enige. En klient, der er konfigureret til den ene enhedstype, kan ikke slutte sig til en server, der er konfigureret til den anden, uanset hvad ellers passer.

Betingelse et: er der noget, der har brug for lag to?

Brobygning gør sig fortjent til sin kompleksitet, når en protokol virkelig har brug for det samme broadcast-domæne: ikke-IP-trafik, opdagelse der ikke kan krydse en router, eller en applikation, der insisterer på at være på ét segment. Alt andet er et routingproblem, og routing løser det med langt mindre maskineri. At strække et segment over et stort område strækker også dets broadcasts, så loopforebyggelse, adresseplanlægning og fejldomæner bliver en del af designet. Det er meget at acceptere for et krav, som en enkelt rute ville have opfyldt.

Testen er konkret: navngiv den applikation, der fejler på en routet tunnel, og sig hvorfor. Hvis svaret er, at den har brug for broadcast, er lag to det ærlige svar. Hvis svaret er, at nogen ikke kunne nå én server, er kravet en rute eller en firewallregel.

Betingelse to: kan klienterne gøre det?

Understøttelsen er ikke ensartet. Skrivebordsklienter udstiller normalt begge enhedstyper, mens mobil- og indlejrede klienter ofte kun implementerer den routed tilstand, og en profil, der importeres uden klager, kan stadig fejle, når den forsøger at oprette grænsefladen. Kontrollér den konkrete klient og version i stedet for at udlede funktionssættet af platformsnavnet.

En fejl om en ikke-understøttet indstilling er ikke en opfordring til at slette ukendte linjer, indtil importen lykkes. Den betyder, at profilen og klienten er uenige om, hvad der er muligt, og reparationen hører til den operatør, der udstedte profilen. At fjerne en indstilling for at bringe en validator til tavshed kan give en forbindelse, der ser ud til at virke, mens den lydløst udelader den egenskab, den var der for at levere.

Betingelse tre: er det her virkelig et spørgsmål om grænsefladen?

To beslægtede valg får skylden for grænsefladeproblemer. Den virtuelle enhed afgør, hvad der kommer ind i tunnelen, mens UDP eller TCP afgør, hvordan den ydre transport opfører sig, og ingen af dem kurerer overførsler, der går i stå. Når store overførsler hænger, mens små lykkes, fortjener pakkestørrelse og MTU opmærksomheden i stedet.

En klient, der forbinder og derefter ikke kan nå én intern vært, kigger normalt på routing, en firewallregel eller en manglende returvej.

Til en administreret tjeneste bruger du det grænsefladeopræt, som operatørens profil angiver, for serversiden er allerede bygget op omkring det. Til en privat udrulning vælger du ud fra applikationens reelle krav og skriver begrundelsen ved siden af valget.

Spørgsmålet er ikke, hvilken mulighed der er stærkest. Det er, hvilken af dem trafikken faktisk har brug for.