OpenVPN TUN edo TAP: hiru baldintzak erabakitzen dute

Bi tunelek fitxategi-transferentzia bera eraman dezakete eta erabat desberdinak izan kablean jartzen dutenari dagokionez. Batek IP paketeak mugitzen ditu bi helbideren artean; besteak Ethernet esparruak mugitzen ditu eta segmentu batera zubiratu daiteke. Desberdintasun horrek erabakitzen du zein aplikaziok funtzionatzen duten, zein bezero konekta daitezkeen eta zenbat sare-diseinu hartzen duzun zure gain.

Hiru baldintzek argitzen dute praktikan. Pasa itzazu hurrenez hurren, lehenak eztabaida amaitu ohi baitu.

Zer daraman interfaze bakoitzak benetan

TUN gailu bat 3-geruzako puntutik punturako interfazea da: kernela IP paketeak ematen dizkio eta tunelek pareko helbidera eramaten ditu. TAP gailu bat 2-geruzako interfazea da, Ethernet esparruak daramatzana, eta horrek egiten du zubiratzea posible, kernelaren dokumentazioak deskribatzen duen bezala. Bietako batek ez du aldatzen karga erabilgarria nola zifratzen den, eta ez da indar-ezarpen bat. Aukera muturren artean trukatu behar denari buruzkoa da, ez trafikoa zein ondo babestuta dagoen.

Ondorio bat berehala dator: bi muturrek bat etorri behar dute. Gailu mota baterako konfiguratutako bezero batek ezin dio beste baterako konfiguratutako zerbitzari bati batu, beste guztia bat etorri arren.

Lehen baldintza: behar du ezerk bigarren geruza?

Zubiratzeak bere konplexutasuna merezi du protokolo batek benetan difusio-domeinu bera behar duenean: IP ez den trafikoa, router bat zeharka dezakeen aurkikuntza, edo segmentu berean egon behar duen aplikazioa. Gainerako guztia bideratze-arazo bat da, eta bideratzeak askoz makineria gutxiagorekin konpontzen du. Segmentu bat eremu zabal batera hedatzeak haren difusioak ere hedatzen ditu, beraz begizten prebentzioa, helbide-plangintza eta hutsegite-domeinuak diseinuaren parte bihurtzen dira. Asko da onartzeko bide bakar batek beteko zukeen baldintza batengatik.

Testa zehatza da: izendatu bideratutako tunel batean huts egiten duen aplikazioa eta esan zergatik. Erantzuna difusioa behar duela bada, bigarren geruza da erantzun zintzoa. Erantzuna norbait zerbitzari batera iritsi ezin izan zela bada, baldintza bide bat edo suebaki-arau bat da.

Bigarren baldintza: bezeroek egin dezakete?

Euskarria ez da uniformea. Mahaigaineko bezeroek bi gailu motak eskaintzen dituzte normalean, eta mugikorrek eta txertatuek bideratutako modua soilik inplementatzen dute askotan, eta kexarik gabe inportatzen den profilek huts egin dezake interfazea sortzen saiatzen denean. Egiaztatu bezero eta bertsio zehatza, plataformaren izenetik funtzio-multzoa ondorioztatu beharrean.

Onartzen ez den aukera baten errorea ez da importazioa lortu arte lerro ezezagunak ezabatzeko gonbita. Profilak eta bezeroak posible denari buruz bat ez datozela esan nahi du, eta konponketa profila eman zuen operadoreari dagokio. Balidatzaile bat isilarazteko aukera bat kentzeak funtzionatzen duela dirudien konexioa sor dezake, existitzeko arrazoia zuen propietatea isilka baztertuz.

Hirugarren baldintza: benetan interfaze-kontua da hau?

Alboko bi aukeri egozten zaizkie interfaze-arazoak. Gailu birtualak erabakitzen du zer sartzen den tunelean, eta UDP edo TCPk erabakitzen du kanpoko garraioak nola jokatzen duen, eta batek ere ez du blokeatzen diren transferentziak sendatzen. Transferentzia handiak zintzilik geratzen direnean txikiak lortzen diren bitartean, pakete-tamainak eta MTUk merezi dute arreta.

Konektatu eta gero barneko ostalari batera iritsi ezin den bezeroa bideratzea, suebaki-arau bat edo itzulera-bide bat falta zaiola ohartu ohi da.

Zerbitzu kudeatu baterako, erabili operadorearen profilak zehazten duen interfaze-antolamendua, zerbitzariaren aldea jada haren inguruan eraikita baitago. Inplementazio pribatu baterako, aukeratu aplikazioaren benetako baldintzatik abiatuta eta idatzi arrazoia aukeraren ondoan.

Galdera ez da zein aukera den indartsuena. Galdera da trafikoak zein behar duen benetan.