TAP eller TUN? Android OpenVPN-klienter og broforbundne servere

En profil, der virker på en bærbar computer, fejler på telefonen. Det oplagte skridt er at ændre ét ord i klientens konfiguration. Det ord hjælper ikke, fordi de to ender ikke taler om samme slags trafik.

TAP bærer Ethernet-rammer. TUN bærer IP-pakker. En Android-VPN-app får stillet en IP-grænseflade til rådighed, og det gør det ene af de to arrangementer muligt og det andet umuligt, uanset hvad konfigurationen siger.

Sammenligningen er kort, men den afgør, om du kan rette det på telefonen, eller om du må ændre tjenesten.

To tunnetyper med forskellige nyttelaster

En TAP-grænseflade opfører sig som en Ethernet-adapter. Den bærer rammer, altså ARP, broadcast og alt andet, som et LAN bærer under IP. Det er det, der gør brodannelse mulig: tunnelen udvider et broadcast-domæne, og klienterne opfører sig, som om de var sat i en switch.

En TUN-grænseflade bærer IP-pakker, der er adresseret til den. Der er ingen linklag at forhandle, ingen ARP og ingen broadcast. Ruting afgør, hvad der kommer ind i tunnelen, og serversidekonfigurationen bruger et subnet i stedet for en bro.

Begge ender skal være enige om, hvilket af de to de gør. At ændre dev tap til dev tun i den ene ende konverterer ikke tjenesten; det giver en klient, der forventer en rutet tunnel, og en server, der stadig sender rammer, og håndtrykket kan lykkes, mens intet brugbart passerer.

Hvad Android faktisk giver appen

Platformens VpnService-API giver en app en virtuel grænseflade til IP-pakker, konfigureret med adresser, ruter og en MTU. Der er ingen Ethernet-adapter i den API, og appen kan ikke fremmane en.

Derfor dokumenterer OpenVPN Connect støtte til rutede TUN-forbindelser på Android frem for TAP-broer. Android-faq'en er klientsidens udsagn om den grænse, og den svarer til platformens API.

Netværksværktøjer med root, egen firmware eller et produkt, der implementerer et eksplicit oversættelseslag, er andre arrangementer. Det almindelige tilfælde er det, du skal planlægge efter: en app, der kan importere din fil og køre som en normal bruger, med en IP-grænseflade og intet under den.

Sådan ser det ud, når du alligevel prøver

Forbindelsen oprettes som regel. Det er det, der gør fejlen forvirrende: klienten rapporterer forbindelse, serverloggen viser en peer, og ingen applikation virker.

Trafik adresseret til telefonens tildelte adresse når ikke frem, fordi serveren broer rammer til en MAC-adresse, som telefonen aldrig har haft. Broadcast-afhængig opdagelse forbliver tom. Hvis LAN'et er afhængigt af DHCP over broen, får telefonen ikke en leje ad den vej, og en manuelt tildelt adresse i det broforbundne subnet skaber stadig ikke den manglende grænseflade.

Nogle klienter fejler tidligere, ved profilimport, når de ser en enhedstype, de ikke kan implementere. Begge adfærd betyder det samme, og ingen af dem rettes ved at tilføje ruter, ændre DNS eller udvide tunnelens adresseområde.

Hvad serversiden skal ændre

Rettelsen tilhører den, der driver VPN-tjenesten, og den er som regel additiv snarere end en migrering. Kør en anden OpenVPN-instans med en rutet enhed, sit eget klient-subnet og en serversidekonfiguration, der tildeler adresser og skubber de ruter, telefonerne har brug for. Den eksisterende broforbundne instans bliver ved med at betjene de enheder, der virkelig har brug for Ethernet.

To detaljer får det til at virke i praksis. LAN'et har brug for en returrute til det nye klient-subnet, der peger på VPN-værten, ellers kommer svarene aldrig tilbage. Og firewallen på tunnelværten skal videresende mellem tunnelgrænsefladen og LAN'et, og det er det skridt, der oftest glemmes, når en test fra værten selv lykkes.

Hvis operatøren ikke kan tilføje en tjeneste, er alternativet en enhed, der kan tilslutte sig broen, altså en bærbar computer eller en router, der handler på telefonens vegne. Det er en omgåelse med sin egen administrationsomkostning, ikke en Android-konfiguration.

Beslut ud fra applikationen, ikke tunnelen

Spørg, hvad telefonen faktisk skal nå, og kortlæg det så. En filshare eller et intranetsted, der nås via navn eller adresse, er et IP-krav, og en rutet tunnel opfylder det, når DNS opløser navnet, og ruten findes. Et opdagelsesværktøj, der gennemser det lokale broadcast-domæne, er ikke et IP-krav, og ingen mængde ruting vil fylde det.

Den tabel er også den anmodning, der skal sendes. Navngiv applikationen, den adresse eller det navn, den bruger, og om den afhænger af opdagelse. En operatør kan handle på den beskrivelse, hvilket ingen kan på en telefon, der ikke vil forbinde.

Endelig, behold TAP-tjenesten til de enheder, der har brug for den, i stedet for at få hver klient til at efterligne en LAN-adapter. To tjenester med klare formål er lettere at understøtte end én, der halvt virker for alle.