TAP ou TUN ? Clients OpenVPN Android et serveurs pontés

Un profil qui fonctionne sur un ordinateur portable échoue sur le téléphone. Le geste évident est de modifier un mot dans la configuration du client. Ce mot n’aidera pas, parce que les deux extrémités ne parlent pas du même type de trafic.

TAP transporte des trames Ethernet. TUN transporte des paquets IP. Une application VPN Android reçoit une interface IP, ce qui rend l’une de ces deux dispositions possible et l’autre non, quoi que dise la configuration.

La comparaison est courte, mais elle décide si vous pouvez corriger cela sur le téléphone ou si vous devez changer le service.

Deux types de tunnel aux charges utiles différentes

Une interface TAP se comporte comme un adaptateur Ethernet. Elle transporte des trames, donc ARP, la diffusion et tout ce qu’un LAN transporte sous IP. C’est ce qui rend le pont possible : le tunnel étend un domaine de diffusion et les clients se comportent comme s’ils étaient branchés sur un commutateur.

Une interface TUN transporte des paquets IP qui lui sont adressés. Il n’y a pas de couche de liaison à négocier, pas d’ARP et pas de diffusion. Le routage décide de ce qui entre dans le tunnel, et la configuration côté serveur utilise un sous-réseau plutôt qu’un pont.

Les deux extrémités doivent s’accorder sur celle des deux qu’elles font. Remplacer dev tap par dev tun d’un côté ne convertit pas le service ; cela produit un client qui attend un tunnel routé et un serveur qui pousse encore des trames, et la poignée de main peut réussir alors que rien d’utilisable ne passe.

Ce qu’Android remet réellement à l’application

L’API VpnService de la plateforme donne à une application une interface virtuelle pour les paquets IP, configurée avec des adresses, des routes et une MTU. Il n’y a pas d’adaptateur Ethernet dans cette API, et aucun moyen pour l’application d’en inventer un.

C’est pourquoi OpenVPN Connect documente la prise en charge des connexions TUN routées sur Android plutôt que du pontage TAP. La FAQ Android est l’énoncé côté client de cette limite, et il correspond à l’API de la plateforme.

Les outils réseau avec root, un firmware personnalisé ou un produit qui implémente une couche de traduction explicite sont d’autres dispositions. Le cas ordinaire est celui à prévoir : une application qui peut importer votre fichier et s’exécuter comme un utilisateur normal, avec une interface IP et rien en dessous.

À quoi cela ressemble quand vous essayez quand même

La connexion s’établit généralement. C’est ce qui rend l’échec déroutant : le client signale une connexion, le journal du serveur montre un pair, et aucune application ne fonctionne.

Le trafic adressé à l’adresse attribuée au téléphone n’arrive pas, parce que le serveur ponte des trames vers une adresse MAC que le téléphone n’a jamais eue. La découverte dépendante de la diffusion reste vide. Si le LAN dépend de DHCP à travers le pont, le téléphone n’obtiendra pas de bail par cette voie, et une adresse attribuée manuellement dans le sous-réseau ponté ne crée toujours pas l’interface manquante.

Certains clients échouent plus tôt, à l’import du profil, lorsqu’ils voient un type d’appareil qu’ils ne peuvent pas implémenter. L’un ou l’autre comportement signifie la même chose, et aucun des deux ne se corrige en ajoutant des routes, en changeant le DNS ou en élargissant la plage d’adresses du tunnel.

Ce que le côté serveur doit changer

La correction revient à qui exploite le service VPN, et elle est généralement additive plutôt qu’une migration. Lancez une seconde instance OpenVPN avec un périphérique routé, son propre sous-réseau client et une configuration côté serveur qui attribue les adresses et pousse les routes dont les téléphones ont besoin. L’instance pontée existante continue de servir les appareils qui ont réellement besoin d’Ethernet.

Deux détails rendent cela opérationnel en pratique. Le LAN a besoin d’une route de retour pour le nouveau sous-réseau client, pointant vers l’hôte VPN, sinon les réponses ne reviendront jamais. Et le pare-feu de l’hôte du tunnel doit transférer entre l’interface du tunnel et le LAN, et c’est l’étape la plus souvent oubliée quand un test depuis l’hôte lui-même réussit.

Si l’opérateur ne peut pas ajouter de service, l’alternative est un appareil qui peut rejoindre le pont, c’est-à-dire un ordinateur portable ou un routeur agissant au nom du téléphone. C’est un contournement avec son propre coût de gestion, pas une configuration Android.

Décidez à partir de l’application, pas du tunnel

Demandez à quoi le téléphone doit réellement accéder, puis cartographiez-le. Un partage de fichiers ou un site intranet joignable par nom ou adresse est une exigence IP, et un tunnel routé y répond une fois que le DNS résout le nom et que la route existe. Un outil de découverte qui parcourt le domaine de diffusion local n’est pas une exigence IP, et aucune quantité de routage ne le remplira.

Ce tableau est aussi la demande à envoyer. Nommez l’application, l’adresse ou le nom qu’elle utilise, et si elle dépend de la découverte. Un opérateur peut agir sur cette description, ce que personne ne peut faire sur un téléphone qui ne se connecte pas.

Enfin, gardez le service TAP pour les appareils qui en ont besoin au lieu de faire imiter un adaptateur LAN à chaque client. Deux services aux objectifs clairs sont plus faciles à maintenir qu’un seul qui fonctionne à moitié pour tout le monde.