TAP ar TUN? Android OpenVPN klientai ir tiltu sujungti serveriai
TAP perduoda Ethernet kadrus, TUN perduoda IP paketus, o Android programėlė gauna tik antrąjį tipą. Palyginkite abu ir tada sutvarkykite serverio pusę.
Profilis, kuris veikia nešiojamajame kompiuteryje, nepavyksta telefone. Akivaizdus žingsnis yra pakeisti vieną žodį kliento konfigūracijoje. Tas žodis nepadės, nes abu galai nekalba apie to paties tipo srautą.
TAP perduoda Ethernet kadrus. TUN perduoda IP paketus. Android VPN programėlei suteikiama IP sąsaja, todėl vienas iš dviejų išdėstymų tampa įmanomas, o kitas ne, nepriklausomai nuo to, ką sako konfigūracija.
Palyginimas trumpas, bet jis nusprendžia, ar galite tai sutvarkyti telefone, ar turite pakeisti paslaugą.
Du tunelių tipai su skirtingomis naudingosiomis apkrovomis
TAP sąsaja elgiasi kaip Ethernet adapteris. Ji perduoda kadrus, tai yra ARP, transliaciją ir visa kita, ką LAN perduoda žemiau IP. Būtent tai leidžia tiltą: tunelis išplečia transliacijos sritį, o klientai elgiasi taip, tarsi būtų prijungti prie komutatoriaus.
TUN sąsaja perduoda jai adresuotus IP paketus. Nėra jungties sluoksnio, dėl kurio reikėtų derėtis, nėra ARP ir nėra transliacijos. Maršrutizavimas nusprendžia, kas patenka į tunelį, o serverio pusės konfigūracija naudoja potinklį, o ne tiltą.
Abu galai turi sutarti, kurį iš šių dviejų jie daro. Pakeitus dev tap į dev tun vienoje pusėje, paslauga nepaverčiama; gaunamas klientas, kuris tikisi maršrutizuoto tunelio, ir serveris, kuris vis dar siunčia kadrus, o rankų paspaudimas gali pavykti, nors niekas naudingo nepereina.
Ką Android iš tikrųjų duoda programėlei
Platformos VpnService API suteikia programėlei virtualią sąsają IP paketams, sukonfigūruotą adresais, maršrutais ir MTU. Toje API nėra Ethernet adapterio, ir programėlė negali jo išsigalvoti.
Todėl OpenVPN Connect dokumentuoja maršrutizuotų TUN jungčių palaikymą Android sistemoje, o ne TAP tiltą. Android DUK yra šios ribos kliento pusės pareiškimas, ir jis atitinka platformos API.
Tinklo įrankiai su root teisėmis, pasirinktinė programinė aparatinė įranga ar produktas, įgyvendinantis aiškų vertimo sluoksnį, yra kiti išdėstymai. Įprastas atvejis yra tas, dėl kurio reikia planuoti: programėlė, kuri gali importuoti jūsų failą ir veikti kaip įprastas naudotojas, su IP sąsaja ir nieko po ja.
Kaip tai atrodo, kai vis tiek bandote
Ryšys paprastai užmezgamas. Būtent tai daro gedimą klaidinančiu: klientas praneša apie prisijungimą, serverio žurnalas rodo partnerį, o nė viena programa neveikia.
Srautas, adresuotas telefonui priskirtu adresu, neateina, nes serveris tiltu perduoda kadrus į MAC adresą, kurio telefonas niekada neturėjo. Nuo transliacijos priklausantis aptikimas lieka tuščias. Jei LAN priklauso nuo DHCP per tiltą, telefonas taip negaus nuomos, o rankiniu būdu priskirtas adresas tiltu sujungtame potinklyje vis tiek nesukuria trūkstamos sąsajos.
Kai kurie klientai nepavyksta anksčiau, importuojant profilį, kai pamato įrenginio tipą, kurio negali įgyvendinti. Abi elgsenos reiškia tą patį, ir nė viena netaisoma pridedant maršrutus, keičiant DNS ar išplečiant tunelio adresų diapazoną.
Ką turi pakeisti serverio pusė
Pataisymas priklauso tam, kas valdo VPN paslaugą, ir paprastai jis yra papildomas, o ne migracija. Paleiskite antrą OpenVPN egzempliorių su maršrutizuotu įrenginiu, savo klientų potinkliu ir serverio pusės konfigūracija, kuri priskiria adresus ir stumia maršrutus, kurių reikia telefonams. Esamas tiltu sujungtas egzempliorius toliau aptarnauja įrenginius, kuriems tikrai reikia Ethernet.
Dvi detalės daro tai praktiškai veikiančiu. LAN reikia grįžtamojo maršruto naujam klientų potinkliui, nukreipto į VPN mazgą, kitaip atsakymai niekada negrįš. Ir tunelio mazgo užkarda turi persiųsti tarp tunelio sąsajos ir LAN, ir tai yra žingsnis, kuris dažniausiai praleidžiamas, kai testas iš paties mazgo pavyksta.
Jei operatorius negali pridėti paslaugos, alternatyva yra įrenginys, galintis prisijungti prie tilto, tai yra nešiojamasis kompiuteris ar maršrutizatorius, veikiantis telefono vardu. Tai savo valdymo kainą turinti apėjimo priemonė, o ne Android konfigūracija.
Spręskite pagal programėlę, o ne pagal tunelį
Paklauskite, ką telefonas iš tikrųjų turi pasiekti, ir tada tai sužymėkite. Failų bendrinimas ar intraneto svetainė, pasiekiama vardu ar adresu, yra IP reikalavimas, o maršrutizuotas tunelis jį patenkina, kai DNS išsprendžia vardą ir maršrutas egzistuoja. Aptikimo įrankis, naršantis vietinę transliacijos sritį, nėra IP reikalavimas, ir joks maršrutizavimo kiekis jo neužpildys.
| 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 lentelė yra ir siunčiama užklausa. Įvardykite programėlę, jos naudojamą adresą ar vardą ir ar ji priklauso nuo aptikimo. Operatorius gali veikti pagal tą aprašymą, ko niekas negali padaryti su telefonu, kuris nesijungia.
Galiausiai, palikite TAP paslaugą tiems įrenginiams, kuriems jos reikia, o ne verskite kiekvieną klientą imituoti LAN adapterį. Dvi paslaugas su aiškiais tikslais lengviau palaikyti nei vieną, kuri visiems veikia pusėtinai.