TAP ali TUN? Odjemalci OpenVPN za Android in strežniki z mostom
TAP prenaša ethernetne okvire, TUN prenaša pakete IP, aplikacija Android pa prejme le drugo vrsto. Primerjajte oba in nato popravite stran strežnika.
Profil, ki deluje na prenosniku, na telefonu odpove. Očitna poteza je spremeniti eno besedo v konfiguraciji odjemalca. Ta beseda ne bo pomagala, ker oba konca ne govorita o isti vrsti prometa.
TAP prenaša ethernetne okvire. TUN prenaša pakete IP. Aplikacija VPN za Android prejme vmesnik IP, kar naredi eno od obeh postavitev mogočo, drugo pa ne, ne glede na to, kaj pravi konfiguracija.
Primerjava je kratka, a odloči, ali lahko to popravite na telefonu ali morate spremeniti storitev.
Dve vrsti tunelov z različnimi podatki
Vmesnik TAP se obnaša kot ethernetni vmesnik. Prenaša okvire, torej ARP, oddajanje in vse drugo, kar LAN prenaša pod IP. Prav to omogoča most: tunel razširi območje oddajanja in odjemalci se obnašajo, kot da so priključeni na stikalo.
Vmesnik TUN prenaša pakete IP, naslovljene nanj. Ni povezavnega sloja za pogajanja, ni ARP in ni oddajanja. O tem, kaj vstopi v tunel, odloča usmerjanje, konfiguracija na strani strežnika pa uporablja podomrežje namesto mostu.
Oba konca se morata strinjati, katero od tistih dveh izvajata. Zamenjava dev tap z dev tun na eni strani storitve ne pretvori; nastane odjemalec, ki pričakuje usmerjen tunel, in strežnik, ki še vedno pošilja okvire, rokovanje pa lahko uspe, medtem ko nič uporabnega ne prehaja.
Kaj Android v resnici preda aplikaciji
API VpnService platforme da aplikaciji navidezni vmesnik za pakete IP, nastavljen z naslovi, potmi in MTU. V tem API ni nobenega ethernetnega vmesnika in aplikacija si ga ne more izmisliti.
Zato OpenVPN Connect dokumentira podporo usmerjenim povezavam TUN na Androidu, ne TAP mostovom. Pogosta vprašanja o Androidu so izjava odjemalčeve strani o tej meji in se ujemajo z API platforme.
Omrežna orodja s rootom, lastna strojna programska oprema ali izdelek z izrecnim prevajalnim slojem so druge postavitve. Običajen primer je tisti, okoli katerega je treba načrtovati: aplikacija, ki lahko uvozi vašo datoteko in deluje kot običajen uporabnik, z vmesnikom IP in ničemer pod njim.
Kako je videti, ko vseeno poskusite
Povezava se običajno vzpostavi. Prav to naredi napako zmedeno: odjemalec poroča o povezavi, dnevnik strežnika prikaže partnerja in nobena aplikacija ne deluje.
Promet, naslovljen na dodeljeni naslov telefona, ne prispe, ker strežnik mosti okvire na naslov MAC, ki ga telefon ni nikoli imel. Zaznavanje, odvisno od oddajanja, ostane prazno. Če se LAN zanaša na DHCP prek mostu, telefon tako ne dobi najema in ročno dodeljen naslov v mosteni podomrežju še vedno ne ustvari manjkajočega vmesnika.
Nekateri odjemalci odpovejo prej, pri uvozu profila, ko vidijo vrsto naprave, ki je ne morejo izvesti. Obe vedenji pomenita isto in nobenega ne popravi dodajanje poti, sprememba DNS ali razširitev naslovnega obsega tunela.
Kaj mora spremeniti stran strežnika
Popravek pripada tistemu, ki upravlja storitev VPN, in je običajno dodatek, ne selitev. Zaženite drugo instanco OpenVPN z usmerjeno napravo, lastnim odjemalčevim podomrežjem in konfiguracijo na strani strežnika, ki dodeljuje naslove in potiska poti, ki jih telefoni potrebujejo. Obstoječa mostena instanca še naprej streže napravam, ki resnično potrebujejo Ethernet.
Dve podrobnosti to naredita v praksi delujoče. LAN potrebuje povratno pot za novo odjemalčevo podomrežje, usmerjeno na gostitelja VPN, sicer se odgovori ne bodo nikoli vrnili. In požarni zid na gostitelju tunela mora posredovati med vmesnikom tunela in LAN, kar je korak, ki se najpogosteje izpusti, ko preizkus z gostitelja samega uspe.
Če upravljavec ne more dodati storitve, je alternativa naprava, ki se lahko pridruži mostu, torej prenosnik ali usmerjevalnik, ki deluje v imenu telefona. To je obhod z lastnimi stroški upravljanja, ne konfiguracija Androida.
Odločite se glede na aplikacijo, ne na tunel
Vprašajte, do česa mora telefon v resnici priti, in to nato preslikajte. Skupna mapa ali intranetno mesto, dosegljivo z imenom ali naslovom, je zahteva IP, usmerjen tunel pa jo izpolni, ko DNS razreši ime in pot obstaja. Orodje za zaznavanje, ki pregleduje lokalno območje oddajanja, ni zahteva IP in nobena količina usmerjanja tega ne bo napolnila.
| 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 |
Ta tabela je tudi zahteva, ki jo pošljete. Poimenujte aplikacijo, naslov ali ime, ki ga uporablja, in ali je odvisna od zaznavanja. Upravljavec lahko ravna glede na ta opis, česar s telefonom, ki se ne poveže, ne more nihče.
Nazadnje, ohranite storitev TAP za naprave, ki jo potrebujejo, namesto da bi vsakega odjemalca silili k posnemanju vmesnika LAN. Dve storitvi z jasnim namenom je lažje podpirati kot eno, ki vsem deluje na pol.