OpenVPN TUN teenoor TAP: drie voorwaardes wat die keuse beslis

Twee tonnels kan dieselfde lêeroordrag dra en heeltemal verskil in wat hulle op die draad plaas. Die een beweeg IP-pakkette tussen twee adresse; die ander beweeg Ethernet-rame en kan in 'n segment ingebrug word. Daardie verskil bepaal watter toepassings werk, watter kliënte kan koppel en hoeveel netwerkontwerp jy op jou nek haal.

Drie voorwaardes beslis dit in die praktyk. Werk hulle in volgorde deur, want die eerste een beëindig gewoonlik die gesprek.

Wat elke koppelvlak werklik dra

'n TUN-toestel is 'n laag-3-punt-tot-punt-koppelvlak: die kernel gee dit IP-pakkette en die tonnel dra hulle na 'n eweknie-adres. 'n TAP-toestel is 'n laag-2-koppelvlak wat Ethernet-rame dra, en dit is wat bridging hoegenaamd moontlik maak, soos die kerndokumentasie beskryf. Nie een verander hoe die vrag versleutel word nie, en nie een is 'n sterkte-instelling nie. Die keuse gaan oor wat die eindpunte moet uitruil, nie oor hoe goed die verkeer beskerm word nie.

Een gevolg volg onmiddellik: albei kante moet saamstem. 'n Kliënt wat vir die een toestelsoort opgestel is, kan nie by 'n bediener aansluit wat vir die ander opgestel is nie, maak nie saak wat anders ooreenstem nie.

Voorwaarde een: het enigiets laag twee nodig?

Bridging verdien sy kompleksiteit wanneer 'n protokol werklik dieselfde uitsaaidomein nodig het: nie-IP-verkeer, ontdekking wat nie oor 'n router kan beweeg nie, of 'n toepassing wat daarop aandring om op een segment te wees. Alles anders is 'n routeringsprobleem, en routering los dit met veel minder masjinerie op. Om 'n segment oor 'n wye gebied te strek, strek ook sy uitsendings, so lusvoorkoming, adresbeplanning en foutdomeine word deel van die ontwerp. Dit is baie om te aanvaar vir 'n vereiste wat 'n enkele roete sou bevredig het.

Die toets is konkreet: noem die toepassing wat op 'n gerouteerde tonnel misluk en sê waarom. As die antwoord is dat dit uitsending nodig het, is laag twee die eerlike antwoord. As die antwoord is dat iemand een bediener nie kon bereik nie, is die vereiste 'n roete of 'n firewall-reël.

Voorwaarde twee: kan die kliënte dit doen?

Ondersteuning is nie eenvormig nie. Tafelbladkliënte bied gewoonlik albei toestelsoorte, terwyl mobiele en ingebedde kliënte dikwels net die gerouteerde modus implementeer, en 'n profiel wat sonder klagte invoer, kan steeds misluk wanneer dit die koppelvlak probeer skep. Kyk na die spesifieke kliënt en weergawe eerder as om die kenmerke uit die platformnaam af te lei.

'n Fout oor 'n ongesteunde opsie is nie 'n uitnodiging om onbekende reëls te skrap tot die invoer slaag nie. Dit beteken die profiel en die kliënt stem nie saam oor wat moontlik is nie, en die herstelling hoort by die operateur wat die profiel uitgereik het. Om 'n opsie te verwyder om 'n valideerder stil te maak, kan 'n verbinding lewer wat lyk of dit werk terwyl dit stilletjies die eienskap weglaat waarvoor dit bestaan het.

Voorwaarde drie: is dit werklik 'n koppelvlakvraag?

Twee naburige keuses kry die skuld vir koppelvlakprobleme. Die virtuele toestel besluit wat die tonnel binnegaan, terwyl UDP of TCP besluit hoe die buitenste transport optree, en nie een genees oordragte wat vasval nie. Wanneer groot oordragte hang terwyl klein s'n slaag, verdien pakketgrootte en MTU eerder die aandag.

'n Kliënt wat koppel en dan een interne gasheer nie kan bereik nie, kyk gewoonlik na routering, 'n firewall-reël of 'n ontbrekende terugweg.

Vir 'n bestuurde diens, gebruik die koppelvlakreëling wat die operateur se profiel bepaal, want die bedienerkant is reeds daarom gebou. Vir 'n private ontplooiing, kies op grond van die toepassing se werklike vereiste en skryf die rede langs die keuse.

Die vraag is nie watter opsie sterker is nie. Dit is watter een die verkeer werklik nodig het.