TAP eller TUN? Android OpenVPN-klientar og brukopla serverar

Ein profil som verkar på ein berbar PC, feilar på telefonen. Det openberre trekket er å endre eitt ord i klientkonfigurasjonen. Det ordet hjelper ikkje, fordi dei to endane ikkje snakkar om same type trafikk.

TAP ber Ethernet-rammer. TUN ber IP-pakkar. Ein Android-VPN-app får eit IP-grensesnitt, noko som gjer det eine av dei to arrangementa mogleg og det andre ikkje, uansett kva konfigurasjonen seier.

Samanlikninga er kort, men ho avgjer om du kan reparere dette på telefonen eller må endre tenesta.

To tunneltypar med ulike nyttelaster

Eit TAP-grensesnitt oppfører seg som ein Ethernet-adapter. Det ber rammer, altså ARP, kringkasting og alt anna eit LAN ber under IP. Det er dette som gjer brukopling mogleg: tunnelen utvidar eit kringkastingsdomene, og klientane oppfører seg som om dei var kopla til ein svitsj.

Eit TUN-grensesnitt ber IP-pakkar som er adresserte til det. Det er ingen lenkjelag å forhandle, ingen ARP og inga kringkasting. Ruting avgjer kva som kjem inn i tunnelen, og serversidekonfigurasjonen brukar eit subnett i staden for ei bru.

Begge endane må vere samde om kva av dei to dei gjer. Å endre dev tap til dev tun på éi side konverterer ikkje tenesta; det gir ein klient som ventar ein ruta tunnel og ein server som framleis sender rammer, og handtrykket kan lukkast medan ingenting brukbart passerer.

Kva Android faktisk gir appen

Plattforma sitt VpnService-API gir ein app eit virtuelt grensesnitt for IP-pakkar, konfigurert med adresser, ruter og ein MTU. Det er ingen Ethernet-adapter i det API-et, og appen kan ikkje trylle fram ein.

Difor dokumenterer OpenVPN Connect støtte for ruta TUN-tilkoplingar på Android i staden for TAP-bruing. Android-FAQ-en er klient side si utsegn om denne grensa, og ho samsvarar med plattforma sitt API.

Nettverksverktøy med root, eigen fastvare eller eit produkt som implementerer eit eksplisitt omsetjingslag, er andre arrangement. Det vanlege tilfellet er det du bør planleggje rundt: ein app som kan importere fila di og køyre som ein vanleg brukar, med eit IP-grensesnitt og ingenting under det.

Korleis det ser ut når du prøver likevel

Tilkoplinga vert vanlegvis oppretta. Det er dette som gjer feilen forvirrande: klienten rapporterer tilkopla, serverloggen viser ein peer, og ingen applikasjon verkar.

Trafikk adressert til den tildelte adressa til telefonen kjem ikkje fram, fordi serveren brukoplar rammer til ei MAC-adresse telefonen aldri har hatt. Kringkastingsavhengig oppdaging blir verande tom. Viss LAN-et er avhengig av DHCP over brua, får ikkje telefonen ei leige den vegen, og ei manuelt tildelt adresse i det brukopla subnettet lagar framleis ikkje det manglande grensesnittet.

Nokre klientar feilar tidlegare, ved profilimport, når dei ser ein einingstype dei ikkje kan implementere. Begge åtferdene tyder det same, og ingen av dei vert retta ved å leggje til ruter, endre DNS eller utvide adresseområdet til tunnelen.

Kva serversida må endre

Rettinga høyrer til den som driv VPN-tenesta, og ho er vanlegvis eit tillegg snarare enn ein migrasjon. Køyr ein andre OpenVPN-førekomst med ei ruta eining, sitt eige klient-subnett og ein serversidekonfigurasjon som tildeler adresser og skyv ut rutene telefonane treng. Den eksisterande brukopla førekomsten held fram med å betene einingane som verkeleg treng Ethernet.

To detaljar gjer dette brukbart i praksis. LAN-et treng ei returrute for det nye klient-subnettet, som peikar på VPN-verten, elles kjem svar aldri tilbake. Og brannmuren på tunnelverten må vidaresende mellom tunnelgrensesnittet og LAN-et, og det er trinnet som oftast vert gløymt når ein test frå verten sjølv lukkast.

Viss operatøren ikkje kan leggje til ei teneste, er alternativet ei eining som kan bli med i brua, altså ein berbar PC eller ein ruter som handlar på vegner av telefonen. Det er ein omveg med sin eigen administrasjonskostnad, ikkje ein Android-konfigurasjon.

Avgjer ut frå applikasjonen, ikkje tunnelen

Spør kva telefonen faktisk må nå, og kartlegg det deretter. Ei filutveksling eller ein intranettside som nås med namn eller adresse, er eit IP-krav, og ein ruta tunnel oppfyller det når DNS løyser namnet og ruta finst. Eit oppdagingsverktøy som bla gjennom det lokale kringkastingsdomenet, er ikkje eit IP-krav, og inga mengd ruting vil fylle det.

Den tabellen er også førespurnaden som skal sendast. Namngi applikasjonen, adressa eller namnet han brukar, og om han er avhengig av oppdaging. Ein operatør kan handle på den skildringa, noko ingen kan gjere med ein telefon som ikkje koplar til.

Til slutt, hald på TAP-tenesta for einingane som treng henne i staden for å få kvar klient til å etterlikne ein LAN-adapter. To tenester med klare føremål er lettare å støtte enn éi som halvvegs verkar for alle.