TAP eller TUN? Android OpenVPN-klienter og brokoblede servere

En profil som virker på en bærbar PC, feiler på telefonen. Det åpenbare trekket er å endre ett ord i klientkonfigurasjonen. Det ordet hjelper ikke, fordi de to endene ikke snakker om samme type trafikk.

TAP bærer Ethernet-rammer. TUN bærer IP-pakker. En Android-VPN-app får et IP-grensesnitt, noe som gjør det ene av de to arrangementene mulig og det andre ikke, uansett hva konfigurasjonen sier.

Sammenligningen er kort, men den avgjør om du kan reparere dette på telefonen eller må endre tjenesten.

To tunneltyper med forskjellige nyttelaster

Et TAP-grensesnitt oppfører seg som en Ethernet-adapter. Det bærer rammer, altså ARP, kringkasting og alt annet et LAN bærer under IP. Det er dette som gjør brokobling mulig: tunnelen utvider et kringkastingsdomene, og klientene oppfører seg som om de var koblet til en svitsj.

Et TUN-grensesnitt bærer IP-pakker som er adressert til det. Det er ingen lenkelag å forhandle, ingen ARP og ingen kringkasting. Ruting avgjør hva som kommer inn i tunnelen, og serversidekonfigurasjonen bruker et subnett i stedet for en bro.

Begge endene må være enige om hvilket av de to de gjør. Å endre dev tap til dev tun på én side konverterer ikke tjenesten; det gir en klient som forventer en rutet tunnel og en server som fortsatt sender rammer, og håndtrykket kan lykkes mens ingenting brukbart passerer.

Hva Android faktisk gir appen

Plattformens VpnService-API gir en app et virtuelt grensesnitt for IP-pakker, konfigurert med adresser, ruter og en MTU. Det er ingen Ethernet-adapter i den API-en, og appen kan ikke trylle frem en.

Derfor dokumenterer OpenVPN Connect støtte for rutede TUN-tilkoblinger på Android i stedet for TAP-broing. Android-FAQ-en er klientsidens uttalelse om denne grensen, og den samsvarer med plattformens API.

Nettverksverktøy med root, egen fastvare eller et produkt som implementerer et eksplisitt oversettelseslag, er andre arrangementer. Det vanlige tilfellet er det du bør planlegge rundt: en app som kan importere filen din og kjøre som en vanlig bruker, med et IP-grensesnitt og ingenting under det.

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

Tilkoblingen opprettes vanligvis. Det er dette som gjør feilen forvirrende: klienten rapporterer tilkoblet, serverloggen viser en peer, og ingen applikasjon virker.

Trafikk adressert til telefonens tildelte adresse kommer ikke frem, fordi serveren brokobler rammer til en MAC-adresse telefonen aldri har hatt. Kringkastingsavhengig oppdagelse forblir tom. Hvis LAN-et er avhengig av DHCP over broen, får ikke telefonen en leie den veien, og en manuelt tildelt adresse i det brokoblede subnettet lager fortsatt ikke det manglende grensesnittet.

Noen klienter feiler tidligere, ved profilimport, når de ser en enhetstype de ikke kan implementere. Begge atferdene betyr det samme, og ingen av dem rettes ved å legge til ruter, endre DNS eller utvide tunnelens adresseområde.

Hva serversiden må endre

Rettelsen tilhører den som driver VPN-tjenesten, og den er vanligvis et tillegg snarere enn en migrering. Kjør en andre OpenVPN-forekomst med en rutet enhet, sitt eget klient-subnett og en serversidekonfigurasjon som tildeler adresser og skyver ut rutene telefonene trenger. Den eksisterende brokoblede forekomsten fortsetter å betjene enhetene som virkelig trenger Ethernet.

To detaljer gjør dette brukbart i praksis. LAN-et trenger en returrute for det nye klient-subnettet, som peker på VPN-verten, ellers kommer svar aldri tilbake. Og brannmuren på tunnelverten må videresende mellom tunnelgrensesnittet og LAN-et, og det er trinnet som oftest glemmes når en test fra verten selv lykkes.

Hvis operatøren ikke kan legge til en tjeneste, er alternativet en enhet som kan bli med i broen, altså en bærbar PC eller en ruter som handler på telefonens vegne. Det er en omvei med sin egen administrasjonskostnad, ikke en Android-konfigurasjon.

Bestem ut fra applikasjonen, ikke tunnelen

Spør hva telefonen faktisk må nå, og kartlegg det deretter. En filutveksling eller et intranettsted som nås med navn eller adresse, er et IP-krav, og en rutet tunnel oppfyller det når DNS løser navnet og ruten finnes. Et oppdagelsesverktøy som bla gjennom det lokale kringkastingsdomenet, er ikke et IP-krav, og ingen mengde ruting vil fylle det.

Den tabellen er også forespørselen som skal sendes. Navngi applikasjonen, adressen eller navnet den bruker, og om den er avhengig av oppdagelse. En operatør kan handle på den beskrivelsen, noe ingen kan gjøre med en telefon som ikke kobler til.

Til slutt, behold TAP-tjenesten for enhetene som trenger den i stedet for å få hver klient til å etterligne en LAN-adapter. To tjenester med klare formål er lettere å støtte enn én som halvveis virker for alle.