OpenVPN TUN tsjin TAP: trije betingsten dy't it beslisse
It iene ynterface ferfiert IP-pakketten, it oare Ethernet-frames. Kontrolearje de applikaasje, de stipe fan 'e klant en it echte symptoom foardat jo eat oan in brêge keppelje.
Twa tunnels kinne deselde bestânsoerdracht drage en dochs folslein ferskille yn wat se op 'e tried sette. De iene ferpleatst IP-pakketten tusken twa adressen; de oare ferpleatst Ethernet-frames en kin yn in segmint brutsen wurde. Dat ferskil beslút hokker applikaasjes wurkje, hokker klanten ferbine kinne, en hoefolle netwurkûntwerp jo oanfreegje.
Trije betingsten meitsje it yn 'e praktyk dúdlik. Wurkje se yn folchoarder ôf, want de earste einiget de diskusje meastentiids.
Wat elk ynterface eins ferfiert
In TUN-apparaat is in layer-3-punt-tot-punt-ynterface: de kernel jout it IP-pakketten en de tunnel ferfiert se nei in peeradres. In TAP-apparaat is in layer-2-ynterface dat Ethernet-frames ferfiert, en dat is krekt wat brêgen mooglik makket, sa't de kernel-dokumintaasje beskriuwt. Gjin fan beide feroaret hoe't de payload fersifere wurdt, en gjin fan beide is in sterkte-ynstelling. De kar giet oer wat de einpunten útwikselje moatte, net oer hoe goed it ferkear beskerme wurdt.
Ien gefolch folget fuortendaliks: beide kanten moatte it iens wêze. In klant dy't foar it iene apparaattype konfigureare is, kin net by in server dy't foar it oare konfigureare is, hokker oare oerienkomsten der ek binne.
Betingst ien: hat eat laach twa nedich?
Brêgen fertsjinnet syn kompleksiteit as in protokol wier itselde broadcastdomein nedich hat: net-IP-ferkear, ûntdekking dy't in router net oerstekke kin, of in applikaasje dy't derop stiet op ien segmint te wêzen. Al it oare is in routingprobleem, en routing lost dat op mei folle minder masjinerie. In segmint oer in grut gebiet útwreidzje wreidet ek syn broadcasts út, sadat lusprevinsje, adresplanning en falldomeinen allegear diel wurde fan it ûntwerp. Dat is in protte om te akseptearjen foar in eask dy't ien inkelde rûte foldien hawwe soe.
De test is konkreet: neam de applikaasje dy't op in routearre tunnel misgiet en sis wêrom. As it antwurd is dat it broadcast nedich hat, dan is laach twa it earlike antwurd. As it antwurd is dat immen ien server net berikke koe, dan is de eask in rûte of in firewallregel.
Betingst twa: kinne de klanten it?
Stipe is net unifoarm. Desktopklanten jouwe oer it generaal beide apparaattypen, wylst mobile en ynboude klanten faak allinnich de routearre modus ymplementearje, en in profyl dat sûnder klachten ymportearret kin dochs misgje as it it ynterface besiket te meitsjen. Kontrolearje de spesifike klant en ferzje ynstee fan de funksjeset út 'e platfoarmnamme ôf te lieden.
In flater oer in net-stipe opsje is gjin útnûging om ûnbekende regels te wiskjen oant de ymport slagget. It betsjut dat it profyl en de klant it net iens binne oer wat mooglik is, en de reparaasje heart by de operator dy't it profyl útjûn hat. In opsje fuorthelje om in falidearder stil te krijen kin in ferbining opleverje dy't liket te wurkjen wylst it de eigenskip dy't it bestean moast jaan, stilwei weilitten wurdt.
Betingst trije: is dit echt in ynterfacekwestje?
Twa oanbuorjende karren krije de skuld fan ynterfaceproblemen. It firtuele apparaat beslút wat de tunnel yn giet, wylst UDP of TCP beslút hoe't it bûtenste transport him hâldt, en gjin fan beide genêst oerdrachten dy't fêstrinne. As grutte oerdrachten hingje wylst lytse slagje, fertsjinje pakketgrutte en MTU oandacht.
In klant dy't ferbynt en dan ien ynterne host net berikke kin, sjocht meastentiids nei routing, in firewallregel of in ûntbrekkend werompaad.
Brûk foar in beheard service de ynterface-opset dy't it profyl fan 'e operator oanjout, want de serverside is der al omhinne boud. Kies foar in privee-ynset út 'e echte eask fan 'e applikaasje en skriuw de reden njonken de kar.
De fraach is net hokker opsje sterker is. It is hokker opsje it ferkear eins nedich hat.