TAP of TUN? Android OpenVPN-kliënte en oorbrugde bedieners

’n Profiel wat op ’n skootrekenaar werk, faal op die selfoon. Die ooglopende stap is om een woord in die kliëntkonfigurasie te verander. Daardie woord sal nie help nie, want die twee kante praat nie oor dieselfde soort verkeer nie.

TAP dra Ethernet-rame. TUN dra IP-pakkette. ’n Android-VPN-program kry ’n IP-koppelvlak, wat een van dié twee reëlings moontlik maak en die ander een nie, ongeag wat die konfigurasie sê.

Die vergelyking is kort, maar dit bepaal of jy dit op die selfoon kan regmaak of die diens moet verander.

Twee tonneltipes met verskillende vragte

’n TAP-koppelvlak gedra hom soos ’n Ethernet-adapter. Dit dra rame, wat ARP, uitsending en enigiets anders insluit wat ’n LAN onder IP dra. Dit is wat oorbrugging moontlik maak: die tonnel brei ’n uitsaaidomein uit, en kliënte gedra hulle asof hulle in ’n skakelaar ingeprop is.

’n TUN-koppelvlak dra IP-pakkette wat aan hom gerig is. Daar is geen skakellaag om te beding nie, geen ARP nie en geen uitsending nie. Roetering bepaal wat die tonnel binnegaan, en die bedienerkonfigurasie gebruik ’n subnet eerder as ’n brug.

Albei eindpunte moet saamstem oor watter van dié dinge hulle doen. Om dev tap na dev tun aan een kant te verander, skakel nie die diens om nie; dit lewer ’n kliënt wat ’n geroteerde tonnel verwag en ’n bediener wat nog rame stoot, en die handskud kan slaag terwyl niks bruikbaar deurgaan nie.

Wat Android werklik aan die program gee

Die platform se VpnService-API gee ’n program ’n virtuele koppelvlak vir IP-pakkette, met adresse, roetes en ’n MTU. Daar is geen Ethernet-adapter in daardie API nie, en geen manier waarop die program een kan tower nie.

Daarom dokumenteer OpenVPN Connect ondersteuning vir geroteerde TUN-verbindings op Android eerder as TAP-oorbrugging. Die Android FAQ is die kliëntkant se stelling van die grens, en dit stem ooreen met die platform-API.

Root-netwerkwerktuie, pasgemaakte firmware of ’n produk wat ’n eksplisiete vertaallaag implementeer, is ander reëlings. Die gewone geval is die een om rondom te beplan: ’n program wat jou lêer kan invoer en as ’n normale gebruiker kan hardloop, met ’n IP-koppelvlak en niks daaronder nie.

Hoe dit lyk wanneer jy dit tog probeer

Die verbinding kom gewoonlik tot stand. Dit is wat die mislukking verwarrend maak: die kliënt rapporteer verbind, die bedienerlog wys ’n eweknie, en geen toepassing werk nie.

Verkeer gerig aan die selfoon se toegewysde adres kom nie aan nie, want die bediener brug rame na ’n MAC-adres wat die selfoon nooit gehad het nie. Uitsendingsafhanklike ontdekking bly leeg. As die LAN op DHCP oor die brug staatmaak, sal die selfoon nie so ’n huurkontrak kry nie, en ’n handmatig toegewysde adres in die oorbrugde subnet skep steeds nie die ontbrekende koppelvlak nie.

Sommige kliënte faal vroeër, by profielinvoer, wanneer hulle ’n toesteltipe sien wat hulle nie kan implementeer nie. Enige van die twee gedrag beteken dieselfde ding, en nie een word reggemaak deur roetes by te voeg, DNS te verander of die tonnel se adresreeks te verbreed nie.

Wat die bedienerkant moet verander

Die regstelling behoort aan wie die VPN-diens bedryf, en dit is gewoonlik bykomend eerder as ’n migrasie. Bedryf ’n tweede OpenVPN-instansie met ’n geroteerde toestel, sy eie kliëntsubnet en ’n bedienerkonfigurasie wat adresse toeken en die roetes stoot wat die selfone nodig het. Die bestaande oorbrugde instansie bly dien die toestelle wat werklik Ethernet nodig het.

Twee besonderhede laat dit in die praktyk werk. Die LAN het ’n terugroete vir die nuwe kliëntsubnet nodig, wat na die VPN-gasheer wys, anders sal antwoorde nooit terugkom nie. En die firewall op die tonnelgasheer moet tussen die tonnelkoppelvlak en die LAN deurstuur, wat die stap is wat die meeste gemis word wanneer ’n toets van die gasheer self slaag.

As die operateur nie ’n diens kan byvoeg nie, is die alternatief ’n toestel wat by die brug kan aansluit, wat beteken ’n skootrekenaar of ’n roeteerder wat namens die selfoon optree. Dit is ’n tydelike oplossing met sy eie bestuurskoste, nie ’n Android-konfigurasie nie.

Besluit vanuit die toepassing, nie die tonnel nie

Vra wat die selfoon werklik moet bereik, en karteer dit dan. ’n Lêerdeling of intranetwerf wat by naam of adres bereik word, is ’n IP-vereiste, en ’n geroteerde tonnel bevredig dit sodra DNS die naam oplos en die roete bestaan. ’n Ontdekkingsinstrument wat die plaaslike uitsaaidomein deursoek, is nie ’n IP-vereiste nie, en geen hoeveelheid roetering sal dit vul nie.

Daardie tabel is ook die versoek om te stuur. Noem die toepassing, die adres of naam wat dit gebruik, en of dit van ontdekking afhanklik is. ’n Operateur kan op daardie beskrywing reageer op ’n manier waarop niemand op ’n selfoon wat nie wil koppel nie, kan reageer nie.

Laastens, hou die TAP-diens vir die toestelle wat dit nodig het in plaas daarvan om elke kliënt ’n LAN-adapter te laat naboots. Twee dienste met duidelike doeleindes is makliker om te ondersteun as een wat half werk vir almal.