OpenVPN TUN vai TAP: kolme ehtoa ratkaisevat

Kaksi tunnelia voi kuljettaa saman tiedostonsiirron ja erota täysin siinä, mitä ne laskevat johdolle. Toinen siirtää IP-paketteja kahden osoitteen välillä; toinen siirtää Ethernet-kehyksiä ja voidaan sillata segmenttiin. Tämä ero ratkaisee, mitkä sovellukset toimivat, mitkä asiakkaat voivat yhdistää ja kuinka paljon verkkosuunnittelua otat niskoillesi.

Kolme ehtoa ratkaisee sen käytännössä. Käy ne läpi järjestyksessä, sillä ensimmäinen lopettaa yleensä keskustelun.

Mitä kukin rajapinta todella kuljettaa

TUN-laite on kerroksen 3 piste-piste-rajapinta: ydin antaa sille IP-paketit ja tunneli kuljettaa ne vastapuolen osoitteeseen. TAP-laite on kerroksen 2 rajapinta, joka kuljettaa Ethernet-kehyksiä, ja juuri se tekee sillaamisesta ylipäätään mahdollista, kuten ytimen dokumentaatio kuvaa. Kumpikaan ei muuta sitä, miten hyötykuorma salataan, eikä kumpikaan ole vahvuusasetus. Valinta koskee sitä, mitä päätepisteiden on vaihdettava, ei sitä, kuinka hyvin liikenne on suojattu.

Yksi seuraus seuraa heti: molempien päiden on oltava samaa mieltä. Yhdelle lajityypille määritetty asiakas ei voi liittyä palvelimeen, joka on määritetty toiselle, vaikka kaikki muu täsmäisi.

Ehto yksi: tarvitseeko mikään toista kerrosta?

Sillaaminen ansaitsee monimutkaisuutensa, kun protokolla todella tarvitsee saman lähetysverkkotunnuksen: muu kuin IP-liikenne, löytäminen joka ei voi ylittää reititintä, tai sovellus joka vaatii päästä samaan segmenttiin. Kaikki muu on reititysongelma, ja reititys ratkaisee sen paljon vähemmällä koneistolla. Segmentin laajentaminen laajalle alueelle laajentaa myös sen lähetykset, joten silmukoiden esto, osoitesuunnittelu ja vikavyöhykkeet tulevat osaksi suunnittelua. Se on paljon hyväksyttävää vaatimukselle, jonka yksi reitti olisi täyttänyt.

Testi on konkreettinen: nimeä sovellus, joka epäonnistuu reititetyssä tunnelissa, ja kerro miksi. Jos vastaus on, että se tarvitsee lähetystä, toinen kerros on rehellinen vastaus. Jos vastaus on, että joku ei päässyt yhteen palvelimeen, vaatimus on reitti tai palomuurisääntö.

Ehto kaksi: pystyvätkö asiakkaat siihen?

Tuki ei ole yhtenäinen. Työpöytäasiakkaat tarjoavat yleensä molemmat lajityypit, kun taas mobiili- ja sulautetut asiakkaat toteuttavat usein vain reititetyn tilan, ja profiili, joka tuodaan ilman valituksia, voi silti epäonnistua yrittäessään luoda rajapinnan. Tarkista tietty asiakas ja versio sen sijaan, että päättelet ominaisuudet alustan nimestä.

Virhe tukemattomasta valinnasta ei ole kutsu poistaa tuntemattomia rivejä, kunnes tuonti onnistuu. Se tarkoittaa, että profiili ja asiakas ovat eri mieltä siitä, mikä on mahdollista, ja korjaus kuuluu operaattorille, joka profiilin myönsi. Valinnan poistaminen validoijan vaientamiseksi voi tuottaa yhteyden, joka näyttää toimivan ja samalla hiljaa jättää pois ominaisuuden, jota varten se oli olemassa.

Ehto kolme: onko tämä todella rajapintakysymys?

Kahta vierekkäistä valintaa syytetään rajapintaongelmista. Virtuaalilaite päättää, mitä tunneliin tulee, kun taas UDP tai TCP päättää, miten ulompi kuljetus käyttäytyy, eikä kumpikaan paranna siirtoja, jotka juuttuvat. Kun suuret siirrot juuttuvat pienten onnistuessa, paketin koko ja MTU ansaitsevat huomion.

Asiakas, joka yhdistää ja ei sitten tavoita yhtä sisäistä isäntää, katsoo yleensä reititystä, palomuurisääntöä tai puuttuvaa paluureittiä.

Hallitulle palvelulle käytä rajapintajärjestelyä, jonka operaattorin profiili määrittää, sillä palvelinpuoli on jo rakennettu sen ympärille. Yksityiseen käyttöönottoon valitse sovelluksen todellisesta vaatimuksesta ja kirjoita syy valinnan viereen.

Kysymys ei ole siitä, mikä vaihtoehto on vahvempi. Vaan siitä, mitä liikenne todella tarvitsee.