TAP eller TUN? Android OpenVPN-klienter och bryggade servrar

En profil som fungerar på en bärbar dator misslyckas på telefonen. Det uppenbara draget är att ändra ett ord i klientens konfiguration. Det ordet hjälper inte, eftersom de två ändarna inte talar om samma sorts trafik.

TAP bär Ethernet-ramar. TUN bär IP-paket. En Android-VPN-app får ett IP-gränssnitt, vilket gör det ena av de två arrangemangen möjligt och det andra inte, oavsett vad konfigurationen säger.

Jämförelsen är kort, men den avgör om du kan reparera detta på telefonen eller måste ändra tjänsten.

Två tunneltyper med olika nyttolaster

Ett TAP-gränssnitt beter sig som en Ethernet-adapter. Det bär ramar, alltså ARP, broadcast och allt annat ett LAN bär under IP. Det är detta som gör bryggning möjlig: tunneln utökar en broadcast-domän och klienterna beter sig som om de vore inkopplade i en switch.

Ett TUN-gränssnitt bär IP-paket som är adresserade till det. Det finns inget länklager att förhandla, ingen ARP och ingen broadcast. Routning avgör vad som kommer in i tunneln, och serverkonfigurationen använder ett subnät i stället för en brygga.

Båda ändarna måste vara överens om vilket av de två de gör. Att ändra dev tap till dev tun på ena sidan konverterar inte tjänsten; det ger en klient som förväntar sig en routad tunnel och en server som fortfarande skickar ramar, och handskakningen kan lyckas medan inget användbart passerar.

Vad Android faktiskt ger appen

Plattformens VpnService-API ger en app ett virtuellt gränssnitt för IP-paket, konfigurerat med adresser, rutter och en MTU. Det finns ingen Ethernet-adapter i det API:t, och appen kan inte trolla fram en.

Därför dokumenterar OpenVPN Connect stöd för routade TUN-anslutningar på Android i stället för TAP-bryggning. Android-FAQ:n är klientsidans uttalande om den gränsen, och den stämmer med plattformens API.

Nätverksverktyg med root, egen firmware eller en produkt som implementerar ett uttryckligt översättningslager är andra arrangemang. Det vanliga fallet är det du bör planera kring: en app som kan importera din fil och köras som en vanlig användare, med ett IP-gränssnitt och ingenting under det.

Hur det ser ut när du ändå försöker

Anslutningen upprättas oftast. Det är detta som gör felet förvirrande: klienten rapporterar ansluten, serverloggen visar en peer, och ingen applikation fungerar.

Trafik adresserad till telefonens tilldelade adress kommer inte fram, eftersom servern bryggar ramar till en MAC-adress som telefonen aldrig haft. Broadcastberoende upptäckt förblir tom. Om LAN:et är beroende av DHCP över bryggan får telefonen ingen lease den vägen, och en manuellt tilldelad adress i det bryggade subnätet skapar fortfarande inte det saknade gränssnittet.

Vissa klienter misslyckas tidigare, vid profilimport, när de ser en enhetstyp de inte kan implementera. Båda beteendena betyder samma sak, och ingen av dem åtgärdas genom att lägga till rutter, ändra DNS eller bredda tunnelns adressområde.

Vad serversidan måste ändra

Rättelsen tillhör den som driver VPN-tjänsten, och den är oftast ett tillägg snarare än en migrering. Kör en andra OpenVPN-instans med en routad enhet, ett eget klientsubnät och en serverkonfiguration som tilldelar adresser och skickar ut de rutter telefonerna behöver. Den befintliga bryggade instansen fortsätter att betjäna de enheter som verkligen behöver Ethernet.

Två detaljer gör detta användbart i praktiken. LAN:et behöver en returrutt för det nya klientsubnätet, som pekar på VPN-värden, annars kommer svar aldrig tillbaka. Och brandväggen på tunnelvärden måste vidarebefordra mellan tunnelgränssnittet och LAN:et, och det är steget som oftast glöms bort när ett test från värden själv lyckas.

Om operatören inte kan lägga till en tjänst är alternativet en enhet som kan ansluta till bryggan, alltså en bärbar dator eller en router som agerar på telefonens vägnar. Det är en kringgång med egen administrationskostnad, inte en Android-konfiguration.

Bestäm utifrån applikationen, inte tunneln

Fråga vad telefonen faktiskt måste nå, och kartlägg det sedan. En filutdelning eller en intranätsida som nås via namn eller adress är ett IP-krav, och en routad tunnel uppfyller det när DNS löser namnet och rutten finns. Ett upptäcktsverktyg som bläddrar genom den lokala broadcast-domänen är inte ett IP-krav, och ingen mängd routning fyller det.

Den tabellen är också begäran som ska skickas. Namnge applikationen, adressen eller namnet den använder, och om den är beroende av upptäckt. En operatör kan agera på den beskrivningen, vilket ingen kan göra med en telefon som inte ansluter.

Slutligen, behåll TAP-tjänsten för de enheter som behöver den i stället för att låta varje klient härma en LAN-adapter. Två tjänster med tydliga syften är lättare att stödja än en som halvt fungerar för alla.