TAP of TUN? Android OpenVPN-clients en overbrugde servers

Een profiel dat op een laptop werkt, mislukt op de telefoon. De voor de hand liggende stap is één woord in de clientconfiguratie wijzigen. Dat woord zal niet helpen, omdat de twee uiteinden het niet over hetzelfde soort verkeer hebben.

TAP draagt Ethernet-frames. TUN draagt IP-pakketten. Een Android-VPN-app krijgt een IP-interface, waardoor een van de twee opstellingen mogelijk is en de andere niet, wat de configuratie ook zegt.

De vergelijking is kort, maar ze bepaalt of je dit op de telefoon kunt oplossen of de dienst moet wijzigen.

Twee tunneltypen met verschillende payloads

Een TAP-interface gedraagt zich als een Ethernet-adapter. Ze draagt frames, dat wil zeggen ARP, broadcast en al het andere dat een LAN onder IP draagt. Dat maakt overbrugging mogelijk: de tunnel breidt een broadcastdomein uit en clients gedragen zich alsof ze op een switch zijn aangesloten.

Een TUN-interface draagt IP-pakketten die aan haar zijn gericht. Er is geen linklaag om over te onderhandelen, geen ARP en geen broadcast. Routering bepaalt wat de tunnel binnenkomt, en de serverconfiguratie gebruikt een subnet in plaats van een brug.

Beide uiteinden moeten het erover eens zijn welke van de twee ze doen. dev tap door dev tun vervangen aan één kant converteert de dienst niet; het levert een client op die een gerouteerde tunnel verwacht en een server die nog frames stuurt, en de handshake kan slagen terwijl er niets bruikbaars overgaat.

Wat Android de app werkelijk geeft

De VpnService-API van het platform geeft een app een virtuele interface voor IP-pakketten, geconfigureerd met adressen, routes en een MTU. In die API zit geen Ethernet-adapter, en de app kan er geen verzinnen.

Daarom documenteert OpenVPN Connect ondersteuning voor gerouteerde TUN-verbindingen op Android in plaats van TAP-bridging. De Android-FAQ is de uitspraak van de clientkant over die grens, en ze komt overeen met de platform-API.

Netwerkgereedschap met root, eigen firmware of een product met een expliciete vertaallaag zijn andere opstellingen. Het gewone geval is degene waarop je moet plannen: een app die je bestand kan importeren en als normale gebruiker kan draaien, met een IP-interface en niets daaronder.

Hoe het eruitziet als je het toch probeert

De verbinding komt meestal tot stand. Dat maakt de fout verwarrend: de client meldt verbonden, het serverlog toont een peer, en geen enkele toepassing werkt.

Verkeer dat naar het toegewezen adres van de telefoon is gericht, komt niet aan, omdat de server frames overbrugt naar een MAC-adres dat de telefoon nooit heeft gehad. Broadcastafhankelijke ontdekking blijft leeg. Als het LAN op DHCP via de brug vertrouwt, krijgt de telefoon zo geen lease, en een handmatig toegewezen adres in het overbrugde subnet maakt de ontbrekende interface nog steeds niet.

Sommige clients falen eerder, bij het importeren van het profiel, wanneer ze een apparaattype zien dat ze niet kunnen implementeren. Beide gedragingen betekenen hetzelfde, en geen van beide wordt opgelost door routes toe te voegen, DNS te wijzigen of het adresbereik van de tunnel te verbreden.

Wat de serverkant moet wijzigen

De oplossing hoort bij wie de VPN-dienst beheert, en ze is meestal aanvullend in plaats van een migratie. Draai een tweede OpenVPN-instantie met een gerouteerd apparaat, een eigen clientsubnet en een serverconfiguratie die adressen toewijst en de routes pusht die de telefoons nodig hebben. De bestaande overbrugde instantie blijft de apparaten bedienen die echt Ethernet nodig hebben.

Twee details maken dat in de praktijk werkend. Het LAN heeft een retourroute nodig voor het nieuwe clientsubnet, wijzend naar de VPN-host, anders komen antwoorden nooit terug. En de firewall op de tunnelhost moet doorsturen tussen de tunnelinterface en het LAN, en dat is de stap die het vaakst wordt vergeten wanneer een test vanaf de host zelf slaagt.

Als de operator geen dienst kan toevoegen, is het alternatief een apparaat dat aan de brug kan deelnemen, dat wil zeggen een laptop of een router die namens de telefoon handelt. Dat is een omweg met eigen beheerkosten, geen Android-configuratie.

Beslis vanuit de toepassing, niet vanuit de tunnel

Vraag wat de telefoon werkelijk moet bereiken en breng dat in kaart. Een bestandsshare of intranetsite die via naam of adres wordt bereikt, is een IP-vereiste, en een gerouteerde tunnel voldoet daaraan zodra DNS de naam oplost en de route bestaat. Een ontdekkingshulpmiddel dat het lokale broadcastdomein doorzoekt, is geen IP-vereiste, en geen enkele hoeveelheid routering vult dat.

Die tabel is ook het verzoek dat je stuurt. Noem de toepassing, het adres of de naam die ze gebruikt, en of ze van ontdekking afhankelijk is. Een operator kan op die beschrijving handelen, wat niemand kan op een telefoon die niet verbindt.

Ten slotte, houd de TAP-dienst voor de apparaten die hem nodig hebben in plaats van elke client een LAN-adapter te laten nabootsen. Twee diensten met duidelijke doelen zijn eenvoudiger te ondersteunen dan één die voor iedereen half werkt.