TAP ala TUN? Android OpenVPN bezeroak eta zubidun zerbitzariak
TAPek Ethernet markoak garraiatzen ditu, TUNek IP paketeak, eta Android aplikazio batek bigarren mota baino ez du jasotzen. Alderatu biak, eta gero konpondu zerbitzariaren aldea.
Ordenagailu eramangarrian funtzionatzen duen profil batek huts egiten du telefonoan. Urrats nabarmena bezeroaren konfigurazioan hitz bat aldatzea da. Hitz horrek ez du lagunduko, bi muturrak ez baitira trafiko mota beraz ari.
TAPek Ethernet markoak garraiatzen ditu. TUNek IP paketeak garraiatzen ditu. Android VPN aplikazio bati IP interfaze bat ematen zaio, eta horrek bi antolamendu horietako bat posible egiten du eta bestea ez, konfigurazioak esan dezakeena edozein dela ere.
Konparazioa laburra da, baina erabakitzen du telefonoan konpon dezakezun edo zerbitzua aldatu behar duzun.
Karga desberdineko bi tunel mota
TAP interfaze bat Ethernet egokitzaile bat bezala portatzen da. Markoak garraiatzen ditu, hau da ARP, difusioa eta LAN batek IP azpitik garraiatzen duen guztia. Horrek egiten du zubia posible: tunelak difusio domeinu bat hedatzen du eta bezeroak kommutagailu batera konektaturik balego bezala portatzen dira.
TUN interfaze batek berari zuzendutako IP paketeak garraiatzen ditu. Ez dago negoziatzeko esteka geruzarik, ez ARPrik, ez difusiorik. Bideratzeak erabakitzen du tunelera zer sartzen den, eta zerbitzariaren konfigurazioak zubi bat erabili beharrean azpisare bat erabiltzen du.
Bi muturrek ados egon behar dute bi gauza horietako zein egiten ari diren. dev tap dev tun-gatik aldatzeak alde batean ez du zerbitzua bihurtzen; bideratutako tunel bat espero duen bezeroa eta markoak bidaltzen jarraitzen duen zerbitzaria sortzen ditu, eta esku-emateak arrakasta izan dezake erabilgarririk pasatzen ez den bitartean.
Androidek aplikazioari benetan ematen diona
Plataformaren VpnService APIak interfaze birtual bat ematen dio aplikazioari IP paketeetarako, helbide, bide eta MTUrekin konfiguratuta. API horretan ez dago Ethernet egokitzailerik, eta aplikazioak ezin du bat asmatu.
Horregatik OpenVPN Connectek Androiden bideratutako TUN konexioen laguntza dokumentatzen du, TAP zubien ordez. Android maiz egindako galderak muga horren bezero aldeko adierazpena dira, eta plataformaren APIarekin bat datoz.
Root sare tresnak, firmware pertsonalizatua edo itzulpen geruza esplizitu bat inplementatzen duen produktua beste antolamendu batzuk dira. Ohiko kasua planifikatzeko dagoena da: zure fitxategia inportatu eta erabiltzaile arrunt gisa exekuta dezakeen aplikazioa, IP interfaze batekin eta haren azpian ezer gabe.
Nola ikusten den hala ere saiatzen zarenean
Konexioa normalean ezartzen da. Horrek egiten du hutsa nahasgarri: bezeroak konektatuta dagoela jakinarazten du, zerbitzariaren erregistroak pare bat erakusten du, eta inolako aplikaziok ez du funtzionatzen.
Telefonoari esleitutako helbidera zuzendutako trafikoak ez du heltzen, zerbitzariak markoak telefonak inoiz izan ez zuen MAC helbide batera zubiratzen dituelako. Difusioan oinarritutako aurkikuntza hutsik geratzen da. LANak zubian zehar DHCPren mende badago, telefonak ez du horrela lizentziarik lortuko, eta zubidun azpisarean eskuz esleitutako helbideak ez du falta den interfazea sortzen.
Bezero batzuek lehenago huts egiten dute, profilaren inportazioan, inplementatu ezin duten gailu mota bat ikustean. Bi portaerek gauza bera esan nahi dute, eta bat ere ez da konpontzen bideak gehituta, DNS aldatuta edo tunelaren helbide tartea zabalduta.
Zerbitzari aldeak zer aldatu behar duen
Konponketa VPN zerbitzua kudeatzen duenarena da, eta normalean gehigarria da, ez migrazioa. Abiarazi bigarren OpenVPN instantzia bat bideratutako gailu batekin, bere bezero azpisarearekin eta helbideak esleitu eta telefonoek behar dituzten bideak bultzatzen dituen zerbitzari aldeko konfigurazioarekin. Lehendik dagoen zubidun instantziak Ethernet benetan behar duten gailuei zerbitzatzen jarraitzen die.
Bi xehetasunek egiten dute hori praktikan funtzionatzea. LANak atzera-bide bat behar du bezero azpisare berrirako, VPN ostalarira joz, bestela erantzunak ez dira inoiz itzuliko. Eta tunelaren ostalariaren suebakiak tunel interfazearen eta LANaren artean birbidali behar du, eta hori da ostalaritik bertatik egindako proba bat arrakastatsua denean gehien ahazten den urratsa.
Operadoreak ezin badu zerbitzurik gehitu, alternatiba zubira batu daitekeen gailu bat da, hau da, telefonoaren izenean jarduten duen ordenagailu eramangarri edo bideratzaile bat. Kudeaketa kostu propioa duen aldi baterako irtenbidea da, ez Android konfigurazio bat.
Erabaki aplikaziotik, ez tunelatik
Galdetu telefonak benetan zer lortu behar duen, eta gero mapatu. Izen edo helbidez lortzen den fitxategi partekatze edo intranet gune bat IP baldintza bat da, eta bideratutako tunel batek betetzen du DNSak izena ebazten duenean eta bidea existitzen denean. Tokiko difusio domeinua arakatzen duen aurkikuntza tresna ez da IP baldintza bat, eta bideratze kopuruak ez du beteko.
| 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 |
Taula hori bidaltzeko eskaera ere bada. Izenda itzazu aplikazioa, erabiltzen duen helbidea edo izena, eta ea aurkikuntzaren mende dagoen. Operadoreak deskribapen horren arabera jardun dezake, eta inork ezin du hori egin konektatzen ez den telefono batekin.
Azkenik, mantendu TAP zerbitzua behar duten gailuentzat, bezero bakoitzari LAN egokitzaile bat imita dezan eragin beharrean. Helburu argiak dituzten bi zerbitzu errazago mantentzen dira denentzat erdi funtzionatzen duen bakarra baino.