OpenVPN TUN kontra TAP: három feltétel dönt

Két alagút ugyanazt a fájlátvitelt viheti, mégis teljesen különbözhet abban, mit tesz a vezetékre. Az egyik IP-csomagokat mozgat két cím között; a másik Ethernet-kereteket, és hídként egy szegmensbe köthető. Ez a különbség dönti el, mely alkalmazások működnek, mely kliensek tudnak csatlakozni, és mennyi hálózattervezést vállal.

A gyakorlatban három feltétel dönti el. Sorban menjen végig rajtuk, mert az első általában lezárja a vitát.

Mit visz valójában az egyes interfészek

A TUN-eszköz 3-as rétegbeli pont-pont interfész: a kernel IP-csomagokat ad neki, és az alagút elviszi őket egy partner címre. A TAP-eszköz 2-es rétegbeli interfész, amely Ethernet-kereteket visz, és éppen ez teszi egyáltalán lehetővé a hidat, ahogy a kernel dokumentációja leírja. Egyik sem változtat azon, hogyan titkosítják a hasznos terhelést, és egyik sem erősségi beállítás. A választás arról szól, mit kell a végpontoknak kicserélniük, nem arról, mennyire jól védett a forgalom.

Egy következmény azonnal adódik: mindkét végnek egyet kell értenie. Az egyik eszköztípusra beállított kliens nem tud csatlakozni a másikra beállított szerverhez, bármi más is egyezzék.

Első feltétel: kell-e bárminek a kettes réteg?

A híd akkor érdemli meg a bonyolultságát, amikor egy protokoll valóban ugyanazt a broadcast-tartományt igényli: nem IP-forgalom, olyan felderítés, amely nem tud átkelni egy routeren, vagy olyan alkalmazás, amely ragaszkodik ahhoz, hogy egy szegmensen legyen. Minden más útválasztási probléma, és az útválasztás sokkal kevesebb gépezettel megoldja. Egy szegmens nagy területre való kiterjesztése a broadcastokat is kiterjeszti, így a hurokvédelem, a címtervezés és a hibadományok mind a tervezés részévé válnak. Ez sok elfogadnivaló egy olyan követelményért, amelyet egyetlen útvonal is kielégített volna.

A próba kézzelfogható: nevezze meg az alkalmazást, amely az útválasztott alagúton elbukik, és mondja meg, miért. Ha a válasz az, hogy broadcast kell neki, a kettes réteg az őszinte válasz. Ha a válasz az, hogy valaki nem ért el egy szervert, a követelmény egy útvonal vagy egy tűzfal-szabály.

Második feltétel: képesek rá a kliensek?

A támogatás nem egységes. Az asztali kliensek általában mindkét eszköztípust kínálják, míg a mobil és beágyazott kliensek gyakran csak az útválasztott módot valósítják meg, és egy panasz nélkül importált profil is elbukhat, amikor megpróbálja létrehozni az interfészt. A konkrét klienst és verziót ellenőrizze, ne a platform nevéből következtessen a funkciókra.

A nem támogatott opcióra vonatkozó hiba nem meghívás arra, hogy ismeretlen sorokat töröljön, amíg az import sikerül. Azt jelenti, hogy a profil és a kliens nem ért egyet abban, mi lehetséges, és a javítás a profilt kiadó üzemeltetőé. Egy opció eltávolítása a validátor elhallgattatására olyan kapcsolatot hozhat létre, amely működni látszik, miközben csendben elhagyja azt a tulajdonságot, amelyért létezett.

Harmadik feltétel: valóban interfészkérdés ez?

Két szomszédos választást okolnak az interfészproblémákért. A virtuális eszköz dönti el, mi kerül az alagútba, míg az UDP vagy a TCP dönti el, hogyan viselkedik a külső szállítás, és egyik sem gyógyítja az elakadó átviteleket. Amikor a nagy átvitelek megakadnak, a kicsik pedig sikerülnek, inkább a csomagméret és az MTU érdemel figyelmet.

Az a kliens, amely csatlakozik, majd egy belső hoszthoz nem ér el, általában útválasztást, tűzfalszabályt vagy hiányzó visszautat néz.

Felügyelt szolgáltatásnál az üzemeltető profilja által előírt interfész-elrendezést használja, mert a kiszolgálói oldal már erre épül. Saját telepítésnél az alkalmazás valódi követelménye alapján válasszon, és írja le az okot a választás mellé.

Nem az a kérdés, melyik opció erősebb. Hanem hogy melyikre van a forgalomnak valóban szüksége.