TAP või TUN? Androidi OpenVPN-kliendid ja sillatud serverid
TAP kannab Etherneti kaadreid, TUN kannab IP-pakette ja Androidi rakendus saab ainult teist tüüpi. Võrrelge mõlemat ja parandage siis serveripool.
Profiil, mis töötab sülearvutis, ebaõnnestub telefonis. Ilmselge samm on muuta kliendi konfiguratsioonis üks sõna. See sõna ei aita, sest kaks otsa ei räägi sama liiki liiklusest.
TAP kannab Etherneti kaadreid. TUN kannab IP-pakette. Androidi VPN-rakendusele antakse IP-liides, mis muudab ühe kahest korraldusest võimalikuks ja teise mitte, ükskõik mida konfiguratsioon ütleb.
Võrdlus on lühike, kuid see otsustab, kas saate selle telefonis parandada või peate teenust muutma.
Kaks erineva kasuliku koormusega tunnelitüüpi
TAP-liides käitub nagu Etherneti adapter. See kannab kaadreid, see tähendab ARP-d, ringhäälingut ja kõike muud, mida LAN kannab IP all. See teeb silla loomise võimalikuks: tunnel laiendab ringhäälingu domeeni ja kliendid käituvad nii, nagu oleksid lülitisse ühendatud.
TUN-liides kannab talle adresseeritud IP-pakette. Läbirääkimiseks pole lülikihti, pole ARP-d ja pole ringhäälingut. Marsruutimine otsustab, mis tunnelisse satub, ja serveripoolne konfiguratsioon kasutab silla asemel alamvõrku.
Mõlemad otsad peavad kokku leppima, kumba neist nad teevad. dev tap asendamine dev tun-ga ühel küljel ei muuda teenust; selle tulemuseks on klient, kes ootab marsruuditud tunnelit, ja server, mis saadab endiselt kaadreid, ning käepigistus võib õnnestuda, samal ajal kui midagi kasutatavat ei läbi.
Mida Android rakendusele tegelikult annab
Platvormi VpnService-API annab rakendusele IP-pakettide jaoks virtuaalse liidese, mis on seadistatud aadresside, marsruutide ja MTU-ga. Selles API-s pole Etherneti adapterit ja rakendus ei saa seda välja mõelda.
Seetõttu dokumenteerib OpenVPN Connect Androidis marsruuditud TUN-ühenduste, mitte TAP-silla toetust. Androidi KKK on selle piiri kliendipoolne sõnastus ja see vastab platvormi API-le.
Juurkasutaja võrgutööriistad, kohandatud püsivara või toode, mis rakendab selgesõnalist tõlkekihti, on teistsugused korraldused. Tavaline juhtum on see, millega arvestada: rakendus, mis suudab teie faili importida ja töötada tavalise kasutajana, IP-liidesega ja mitte millegagi selle all.
Kuidas see välja näeb, kui siiski proovite
Ühendus tavaliselt luuakse. Just see teebki tõrke segadusse ajavaks: klient teatab ühendusest, serveri logi näitab vastaspoolt ja ükski rakendus ei tööta.
Telefonile määratud aadressile adresseeritud liiklus ei jõua kohale, sest server sillab kaadreid MAC-aadressile, mida telefonil kunagi polnud. Ringhäälingust sõltuv avastamine jääb tühjaks. Kui LAN toetub sillal DHCP-le, ei saa telefon sel viisil rendilepingut ja käsitsi määratud aadress sillatud alamvõrgus ei loo ikkagi puuduvat liidest.
Mõned kliendid ebaõnnestuvad varem, profiili importimisel, kui näevad seadme tüüpi, mida nad ei suuda rakendada. Mõlemad käitumised tähendavad sama ja kumbagi ei paranda marsruutide lisamine, DNS-i muutmine ega tunneli aadressivahemiku laiendamine.
Mida serveripool peab muutma
Parandus kuulub VPN-teenuse haldajale ja on tavaliselt täiendav, mitte migratsioon. Käivitage teine OpenVPN-i eksemplar marsruuditud seadmega, oma kliendi alamvõrguga ja serveripoolse konfiguratsiooniga, mis määrab aadressid ja surub välja telefonidele vajalikud marsruudid. Olemasolev sillatud eksemplar teenindab edasi seadmeid, mis tõesti vajavad Etherneti.
Kaks detaili teevad selle praktikas toimivaks. LAN vajab uue kliendi alamvõrgu jaoks tagasiteed, mis osutab VPN-hostile, muidu ei tule vastused kunagi tagasi. Ja tunnelihosti tulemüür peab edastama tunneliliidese ja LAN-i vahel, ning see on samm, mis jääb kõige sagedamini vahele, kui hostist endast tehtud test õnnestub.
Kui operaator ei saa teenust lisada, on alternatiiviks seade, mis saab sillaga liituda, see tähendab sülearvuti või ruuter, mis tegutseb telefoni nimel. See on oma halduskuluga ajutine lahendus, mitte Androidi konfiguratsioon.
Otsustage rakenduse, mitte tunneli järgi
Küsige, milleni telefon tegelikult peab jõudma, ja kaardistage see. Nime või aadressi kaudu saavutatav failijagamine või intranetisait on IP-nõue ja marsruuditud tunnel täidab selle, kui DNS nimi lahendab ja marsruut olemas on. Kohalikku ringhäälingu domeeni sirviv avastamisvahend ei ole IP-nõue ja ükski marsruutimise kogus ei täida seda.
| 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 |
See tabel on ka päring, mille saadate. Nimetage rakendus, selle kasutatav aadress või nimi ja kas see sõltub avastamisest. Operaator saab sellise kirjelduse põhjal tegutseda, mida ei saa keegi teha telefoni puhul, mis ei ühendu.
Lõpuks, jätke TAP-teenus neile seadmetele, mis seda vajavad, selle asemel et panna iga klient LAN-adapterit jäljendama. Kahte selge eesmärgiga teenust on lihtsam toetada kui ühte, mis töötab kõigi jaoks poolikult.