OpenVPN TUN mot TAP: tre vilkår som avgjør

To tunneler kan frakte den samme filoverføringen og likevel være helt forskjellige i det de setter på ledningen. Den ene flytter IP-pakker mellom to adresser; den andre flytter Ethernet-rammer og kan broes inn i et segment. Den forskjellen avgjør hvilke applikasjoner som virker, hvilke klienter som kan koble til, og hvor mye nettverksdesign du påtar deg.

I praksis avgjør tre vilkår dette. Gå gjennom dem i rekkefølge, for det første avslutter som regel diskusjonen.

Hva hvert grensesnitt faktisk frakter

En TUN-enhet er et punkt-til-punkt-grensesnitt på lag 3: kjernen gir den IP-pakker, og tunnelen frakter dem til en peer-adresse. En TAP-enhet er et grensesnitt på lag 2 som frakter Ethernet-rammer, og det er nettopp dette som gjør broing mulig i det hele tatt, slik kjernedokumentasjonen beskriver. Ingen av dem endrer hvordan nyttelasten krypteres, og ingen av dem er en styrkeinnstilling. Valget handler om hva endepunktene må utveksle, ikke om hvor godt trafikken er beskyttet.

Én konsekvens følger umiddelbart: begge endene må være enige. En klient konfigurert for én enhetstype kan ikke bli med på en server konfigurert for den andre, uansett hva annet som stemmer.

Vilkår én: trenger noe lag to?

Broing fortjener kompleksiteten når en protokoll virkelig trenger samme kringkastingsdomene: ikke-IP-trafikk, oppdagelse som ikke kan krysse en ruter, eller en applikasjon som insisterer på å være på ett segment. Alt annet er et rutingsproblem, og ruting løser det med langt mindre maskineri. Å utvide et segment over et stort område utvider også kringkastingen, så sløyfeforhindring, adresseplanlegging og feildomener blir alle en del av designet. Det er mye å godta for et krav som én enkelt rute ville ha oppfylt.

Testen er konkret: navngi applikasjonen som feiler på en rutet tunnel, og si hvorfor. Hvis svaret er at den trenger kringkasting, er lag to det ærlige svaret. Hvis svaret er at noen ikke kom seg til én server, er kravet en rute eller en brannmurregel.

Vilkår to: kan klientene gjøre det?

Støtten er ikke ensartet. Skrivebordsklienter tilbyr vanligvis begge enhetstypene, mens mobile og innebygde klienter ofte bare implementerer den rutede modusen, og en profil som importeres uten klager kan likevel feile når den prøver å opprette grensesnittet. Sjekk den konkrete klienten og versjonen i stedet for å utlede funksjonene fra plattformnavnet.

En feil om en ikke-støttet valgmulighet er ikke en invitasjon til å slette ukjente linjer til importen lykkes. Det betyr at profilen og klienten er uenige om hva som er mulig, og reparasjonen tilhører operatøren som utstedte profilen. Å fjerne en valgmulighet for å stilne en validator kan gi en tilkobling som ser ut til å virke mens den stille utelater egenskapen den fantes for å gi.

Vilkår tre: er dette egentlig et grensesnittspørsmål?

To nærliggende valg får skylden for grensesnittproblemer. Den virtuelle enheten avgjør hva som kommer inn i tunnelen, mens UDP eller TCP avgjør hvordan den ytre transporten oppfører seg, og ingen av dem kurerer overføringer som stopper. Når store overføringer henger mens små lykkes, fortjener pakkestørrelse og MTU oppmerksomheten i stedet.

En klient som kobler til og deretter ikke når én intern vert, ser vanligvis på ruting, en brannmurregel eller en manglende returvei.

For en administrert tjeneste, bruk grensesnittoppsettet som operatørens profil angir, fordi serversiden allerede er bygget rundt det. For en privat utrulling, velg ut fra applikasjonens reelle krav og skriv grunnen ved siden av valget.

Spørsmålet er ikke hvilket valg som er sterkere. Det er hvilket trafikken faktisk trenger.