OpenVPN TUN mot TAP: tre vilkår som avgjer

To tunnelar kan frakte den same filoverføringa og likevel vere heilt ulike i det dei set på leidninga. Den eine flyttar IP-pakkar mellom to adresser; den andre flyttar Ethernet-rammer og kan bruast inn i eit segment. Den skilnaden avgjer kva applikasjonar som verkar, kva klientar som kan kople til, og kor mykje nettverksdesign du påtek deg.

I praksis avgjer tre vilkår dette. Gå gjennom dei i rekkefølgje, for det første avsluttar som regel diskusjonen.

Kva kvart grensesnitt faktisk fraktar

Ei TUN-eining er eit punkt-til-punkt-grensesnitt på lag 3: kjernen gjev ho IP-pakkar, og tunnelen fraktar dei til ei peer-adresse. Ei TAP-eining er eit grensesnitt på lag 2 som fraktar Ethernet-rammer, og det er nettopp dette som gjer bruing mogeleg i det heile, slik kjernedokumentasjonen skildrar. Ingen av dei endrar korleis nyttelasta vert kryptert, og ingen av dei er ei styrkeinnstilling. Valet handlar om kva endepunkta må utveksle, ikkje om kor godt trafikken er verna.

Éin konsekvens følgjer med ein gong: båe endane må vere samde. Ein klient konfigurert for éin einingstype kan ikkje bli med på ein tenar konfigurert for den andre, uansett kva anna som stemmer.

Vilkår éin: treng noko lag to?

Bruing fortener kompleksiteten når ein protokoll verkeleg treng same kringkastingsdomene: ikkje-IP-trafikk, oppdaging som ikkje kan krysse ein ruter, eller ein applikasjon som insisterer på å vere på eitt segment. Alt anna er eit rutingsproblem, og ruting løyser det med langt mindre maskineri. Å utvide eit segment over eit stort område utvidar òg kringkastinga, så sløyfeførebygging, adresseplanlegging og feildomene vert alle delar av designet. Det er mykje å godta for eit krav som éin einaste rute ville ha oppfylt.

Testen er konkret: nemn applikasjonen som feilar på ein ruta tunnel, og seg kvifor. Viss svaret er at han treng kringkasting, er lag to det ærlege svaret. Viss svaret er at nokon ikkje kom seg til éin tenar, er kravet ei rute eller ei brannmurregel.

Vilkår to: kan klientane gjere det?

Støtta er ikkje einsarta. Skrivebordsklientar tilbyr vanlegvis båe einingstypane, medan mobile og innebygde klientar ofte berre implementerer den ruta modusen, og ein profil som vert importert utan klager kan likevel feile når han prøver å opprette grensesnittet. Sjekk den konkrete klienten og versjonen i staden for å slute funksjonane frå plattformnamnet.

Ein feil om eit ikkje-støtta val er ikkje ei invitasjon til å slette ukjende linjer til importen lukkast. Det tyder at profilen og klienten er usamde om kva som er mogeleg, og reparasjonen høyrer til operatøren som gav ut profilen. Å fjerne eit val for å stilne ein validator kan gje ei tilkopling som ser ut til å verke medan ho stille utelèt eigenskapen ho fanst for å gje.

Vilkår tre: er dette eigentleg eit grensesnittspørsmål?

To nærliggjande val får skulda for grensesnittproblem. Den virtuelle eininga avgjer kva som kjem inn i tunnelen, medan UDP eller TCP avgjer korleis den ytre transporten oppfører seg, og ingen av dei kurerer overføringar som stoppar. Når store overføringar heng medan små lukkast, fortener pakkestorleik og MTU merksemda i staden.

Ein klient som koplar til og deretter ikkje når éin intern vert, ser vanlegvis på ruting, ei brannmurregel eller ein manglande returveg.

For ein administrert teneste, bruk grensesnittoppsettet som profilen til operatøren angir, fordi tenarsida alt er bygd rundt det. For ein privat utrulling, vel ut frå det reelle kravet til applikasjonen og skriv grunnen ved sida av valet.

Spørsmålet er ikkje kva val som er sterkare. Det er kva trafikken faktisk treng.