OpenVPN TUN mot TAP: tre villkor som avgör

Två tunnlar kan transportera samma filöverföring och ändå vara helt olika i vad de lägger på ledningen. Den ena flyttar IP-paket mellan två adresser; den andra flyttar Ethernet-ramar och kan bryggas in i ett segment. Den skillnaden avgör vilka program som fungerar, vilka klienter som kan ansluta och hur mycket nätverksdesign du tar på dig.

I praktiken avgör tre villkor saken. Gå igenom dem i ordning, för det första avslutar oftast diskussionen.

Vad varje gränssnitt faktiskt transporterar

En TUN-enhet är ett punkt-till-punkt-gränssnitt på lager 3: kärnan ger den IP-paket och tunneln transporterar dem till en peer-adress. En TAP-enhet är ett gränssnitt på lager 2 som transporterar Ethernet-ramar, och det är just detta som gör bryggning möjlig över huvud taget, som kärndokumentationen beskriver. Ingen av dem ändrar hur nyttolasten krypteras, och ingen av dem är en styrkeinställning. Valet handlar om vad ändpunkterna måste utbyta, inte om hur väl trafiken skyddas.

En konsekvens följer direkt: båda ändarna måste vara överens. En klient konfigurerad för en enhetstyp kan inte ansluta till en server konfigurerad för den andra, vad som än annars stämmer.

Villkor ett: behöver något lager två?

Bryggning förtjänar sin komplexitet när ett protokoll verkligen behöver samma broadcastdomän: icke-IP-trafik, upptäckt som inte kan passera en router, eller ett program som insisterar på att ligga i ett segment. Allt annat är ett routingproblem, och routing löser det med mycket mindre maskineri. Att sträcka ut ett segment över ett stort område sträcker också ut dess broadcasts, så slingförebyggande, adressplanering och feldomaner blir alla en del av designen. Det är mycket att acceptera för ett krav som en enda route hade uppfyllt.

Testet är konkret: namnge programmet som misslyckas på en routad tunnel och säg varför. Om svaret är att det behöver broadcast är lager två det ärliga svaret. Om svaret är att någon inte kunde nå en server är kravet en route eller en brandväggsregel.

Villkor två: kan klienterna?

Stödet är inte enhetligt. Skrivbordsklienter erbjuder vanligtvis båda enhetstyperna, medan mobila och inbäddade klienter ofta bara implementerar det routade läget, och en profil som importeras utan klagomål kan ändå misslyckas när den försöker skapa gränssnittet. Kontrollera den specifika klienten och versionen i stället för att härleda funktionerna från plattformsnamnet.

Ett fel om ett icke-stött alternativ är inte en inbjudan att radera okända rader tills importen lyckas. Det betyder att profilen och klienten inte är överens om vad som är möjligt, och reparationen tillhör operatören som utfärdade profilen. Att ta bort ett alternativ för att tysta en validator kan ge en anslutning som verkar fungera men tyst utelämnar egenskapen den fanns för att ge.

Villkor tre: är detta verkligen en gränssnittsfråga?

Två närliggande val får skulden för gränssnittsproblem. Den virtuella enheten avgör vad som kommer in i tunneln, medan UDP eller TCP avgör hur den yttre transporten beter sig, och ingen av dem botar överföringar som stannar. När stora överföringar hänger medan små lyckas förtjänar paketstorlek och MTU uppmärksamheten i stället.

En klient som ansluter och sedan inte når en intern värd tittar oftast på routing, en brandväggsregel eller en saknad returväg.

För en hanterad tjänst, använd det gränssnittsupplägg som operatörens profil anger, eftersom serversidan redan är byggd kring det. För en privat driftsättning, välj utifrån programmets verkliga krav och skriv skälet bredvid valet.

Frågan är inte vilket alternativ som är starkare. Den är vilket trafiken faktiskt behöver.