TAP of TUN? Android-OpenVPN-klanten en oerbrêge servers
TAP draacht Ethernet-rammen, TUN draacht IP-pakketten, en in Android-app krijt allinnich it twadde soarte. Ferlykje de beide, en reparearje dan de serverside.
In profyl dat op in laptop wurket, mislearret op ’e telefoan. De foar de hân lizzende stap is ien wurd yn ’e kliïntkonfiguraasje te feroarjen. Dat wurd sil net helpe, want de beide einen prate net oer itselde soarte ferkear.
TAP draacht Ethernet-rammen. TUN draacht IP-pakketten. In Android-VPN-app krijt in IP-ynterfaas, en dat makket ien fan ’e twa regelingen mooglik en de oare net, likefolle wat de konfiguraasje seit.
De ferliking is koart, mar se beslút oft jo dit op ’e telefoan reparearje kinne of de tsjinst feroarje moatte.
Twa soarten tunnels mei ferskillende ladingen
In TAP-ynterfaas hâldt him as in Ethernet-adapter. It draacht rammen, dus ARP, broadcast en al it oare dat in LAN ûnder IP draacht. Dat makket oerbrêgjen mooglik: de tunnel wreidet in broadcast-domein út en klanten hâlde har as wiene se yn in switch stutsen.
In TUN-ynterfaas draacht IP-pakketten dy’t oan him adressearre binne. Der is gjin keppellaach om oer te ûnderhanneljen, gjin ARP en gjin broadcast. Rûtelearring beslút wat de tunnel yn giet, en de serversidekonfiguraasje brûkt in subnet ynstee fan in brêge.
Beide einen moatte it iens wêze oer hokker fan dy twa se dogge. dev tap feroarje nei dev tun oan ien kant konvertearret de tsjinst net; it leveret in klant op dy’t in rûtelearre tunnel ferwachtet en in server dy’t noch rammen stjoert, en de hânskud kin slagje wylst der neat brûkbers trochkomt.
Wat Android de app feitlik jout
De VpnService-API fan it platfoarm jout in app in firtuele ynterfaas foar IP-pakketten, konfigurearre mei adressen, rûtes en in MTU. Der is gjin Ethernet-adapter yn dy API, en de app kin der gjin ien betinke.
Dêrom dokumintearret OpenVPN Connect stipe foar rûtelearre TUN-ferbiningen op Android ynstee fan TAP-oerbrêgjen. De Android-FAQ is de kliïntside-útspraak oer dy grins, en hy komt oerien mei de API fan it platfoarm.
Netwurkark mei root-rjochten, eigen firmware of in produkt dat in eksplisite oersettinglaach ymplemintearret binne oare regelingen. It gewoane gefal is dat dêr’t jo omhinne planje moatte: in app dy’t jo bestân ymportearje kin en as gewoane brûker rinne kin, mei in IP-ynterfaas en neat dêrûnder.
Hoe’t it derút sjocht as jo it dochs besykje
De ferbining komt meastal ta stân. Dat makket it mislearjen betiizjend: de klant meldt ferbûn, it serverlochboek toant in peer, en gjin inkelde applikaasje wurket.
Ferkear dat oan it tawiisde adres fan ’e telefoan adressearre is, komt net oan, want de server oerbrêget rammen nei in MAC-adres dat de telefoan nea hân hat. Untdekking dy’t fan broadcast ôfhinklik is, bliuwt leech. As it LAN op DHCP oer de brêge fertrouwt, krijt de telefoan sa gjin lease, en in mei de hân tawiisde adres yn it oerbrêge subnet makket de ûntbrekkende ynterfaas noch altyd net.
Guon klanten mislearje earder, by profylymport, as se in apparaattype sjogge dat se net ymplemintearje kinne. Beide gedrach betsjut itselde, en gjin fan beide wurdt reparearre troch rûtes ta te foegjen, DNS te feroarjen of it adresberik fan ’e tunnel te ferbreedzjen.
Wat de serverside feroarje moat
De reparaasje heart by wa’t de VPN-tsjinst rint, en is meastal oanfoljend ynstee fan in migraasje. Rin in twadde OpenVPN-eksimplaar mei in rûtelearre apparaat, syn eigen kliïntsubnet en in serversidekonfiguraasje dy’t adressen tawiist en de rûtes skoot dy’t de telefoanen nedich hawwe. It besteande oerbrêge eksimplaar bliuwt de apparaten tsjinje dy’t wier Ethernet nedich hawwe.
Twa details meitsje dat yn ’e praktyk wurkjend. It LAN hat in weromrûte nedich foar it nije kliïntsubnet, nei de VPN-host ta, oars komme antwurden nea werom. En de firewall op ’e tunnelhost moat trochstjoere tusken de tunnel-ynterfaas en it LAN, en dat is de stap dy’t it meast fergetten wurdt as in test fan ’e host sels slagget.
As de operator gjin tsjinst taheakje kin, is it alternative in apparaat dat by de brêge komme kin, dus in laptop of in router dy’t út namme fan ’e telefoan hannelet. Dat is in omwei mei syn eigen behearkosten, gjin Android-konfiguraasje.
Beslis fan ’e applikaasje út, net fan ’e tunnel
Freegje wat de telefoan feitlik berikke moat, en kartearje it dan. In bestânsdieling of intranetside dy’t fia namme of adres berikt wurdt, is in IP-ferplichting, en in rûtelearre tunnel foldocht dêroan sadree’t DNS de namme oplost en de rûte bestiet. In ûntdekkingsark dat it lokale broadcast-domein trochsiket, is gjin IP-ferplichting, en gjin hoemannichte rûtelearring sil it folje.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
Dy tabel is ek it fersyk dat jo stjoere. Neam de applikaasje, it adres of de namme dy’t er brûkt, en oft it fan ûntdekking ôfhinklik is. In operator kin op dy beskriuwing hannelje, wat nimmen op in telefoan dy’t net ferbynt kin.
Ta beslút, hâld de TAP-tsjinst foar de apparaten dy’t it nedich hawwe, ynstee fan elke klant in LAN-adapter neibeare te litten. Twa tsjinsten mei dúdlike doelen binne makliker te stypjen as ien dy’t foar elkenien heal wurket.