OpenVPN TUN vs TAP: kolm tingimust, mis otsustavad

Kaks tunnelit võivad kanda sama failiülekannet ja erineda täielikult selles, mida nad juhtmesse panevad. Üks liigutab IP-pakette kahe aadressi vahel; teine liigutab Etherneti kaadreid ja seda saab sildada segmenti. See erinevus otsustab, millised rakendused töötavad, millised kliendid saavad ühenduda ja kui palju võrguprojekteerimist sa enda peale võtad.

Kolm tingimust otsustavad selle praktikas. Käi need järjekorras läbi, sest esimene lõpetab tavaliselt arutelu.

Mida kumbki liides tegelikult kannab

TUN-seade on kihi 3 punkt-punkt liides: kernel annab sellele IP-paketid ja tunnel kannab need vastaspoole aadressile. TAP-seade on kihi 2 liides, mis kannab Etherneti kaadreid, ja just see teeb sildamise üldse võimalikuks, nagu kirjeldab tuuma dokumentatsioon. Kumbki ei muuda seda, kuidas kasulik koormus krüptitakse, ja kumbki ei ole tugevuse säte. Valik puudutab seda, mida otspunktid peavad vahetama, mitte seda, kui hästi liiklus on kaitstud.

Üks tagajärg järgneb kohe: mõlemad otsad peavad olema ühel meelel. Ühe seadmetüübi jaoks seadistatud klient ei saa liituda serveriga, mis on seadistatud teise jaoks, ükskõik mis muu kattub.

Tingimus esimene: kas miski vajab teist kihti?

Sildamine õigustab oma keerukust siis, kui protokoll vajab tõesti sama ringhäälingu domeeni: mitte-IP liiklus, avastamine, mis ei saa ruuterist üle, või rakendus, mis nõuab, et ta oleks ühes segmendis. Kõik muu on marsruutimise probleem ja marsruutimine lahendab selle palju vähema masinavärgiga. Segmendi laiendamine üle suure ala laiendab ka selle ringhäälingut, nii et silmuste vältimine, aadresside planeerimine ja tõrkedomeenid saavad projekti osaks. See on palju taluda nõude eest, mille oleks rahuldanud üksainus marsruut.

Test on konkreetne: nimeta rakendus, mis marsruuditud tunnelis ebaõnnestub, ja ütle, miks. Kui vastus on, et see vajab ringhäälingut, on teine kiht aus vastus. Kui vastus on, et keegi ei saanud ühte serverit kätte, on nõue marsruut või tulemüürireegel.

Tingimus teine: kas kliendid suudavad?

Tugi ei ole ühtlane. Töölauakliendid pakuvad tavaliselt mõlemat seadmetüüpi, samas kui mobiilsed ja manustatud kliendid rakendavad sageli ainult marsruutimisrežiimi, ja profiil, mis imporditakse kaebusteta, võib siiski ebaõnnestuda, kui see üritab liidest luua. Kontrolli konkreetset klienti ja versiooni, selle asemel et tuletada funktsioonide kogum platvormi nimest.

Toetamata valiku viga ei ole kutse kustutada tundmatuid ridu seni, kuni import õnnestub. See tähendab, et profiil ja klient on eriarvamusel selles, mis on võimalik, ja parandus kuulub operaatorile, kes profiili väljastas. Valiku eemaldamine valideerija vaigistamiseks võib anda ühenduse, mis näib töötavat, samal ajal kui see vaikselt jätab välja omaduse, mille jaoks see oli mõeldud.

Tingimus kolmas: kas see on tõesti liidese küsimus?

Kahte kõrvuti asetsevat valikut süüdistatakse liideseprobleemides. Virtuaalne seade otsustab, mis tunnelisse läheb, samas kui UDP või TCP otsustab, kuidas väline transport käitub, ja kumbki ei ravi ülekandeid, mis takerduvad. Kui suured ülekanded takerduvad, aga väikesed õnnestuvad, väärivad tähelepanu hoopis paketi suurus ja MTU.

Klient, mis ühendub ja seejärel ei saa ühte sisemist hosti kätte, vaatab tavaliselt marsruutimist, tulemüürireeglit või puuduvat tagasiteed.

Hallatava teenuse puhul kasuta liideste paigutust, mille operaatori profiil ette annab, sest serveripool on juba selle ümber ehitatud. Privaatse juurutuse puhul vali rakenduse tegelikust nõudest lähtudes ja kirjuta põhjus valiku kõrvale.

Küsimus ei ole, milline valik on tugevam. Küsimus on, millist liiklus tegelikult vajab.