OpenVPN sur Android n'ajoute pas de route sans adresse de tunnel

Votre profil OpenVPN sous Android n'ajoute pas de route parce que le téléphone n'a aucune adresse sur l'interface virtuelle : une route n'a donc rien vers quoi pointer. Les routes répondent seulement à la question de la destination des paquets. L'adresse de tunnel répond à la question de l'identité du téléphone à l'intérieur du tunnel, et le client doit en fournir une avant que l'interface puisse exister. Parcourez les quatre vérifications ci-dessous dans l'ordre et arrêtez-vous au premier échec, car modifier des routes avant que l'adresse existe masque le vrai problème.

Lisez l'échec dans l'ordre où le client l'exécute

Le VpnService.Builder d Android sépare les deux notions : addAddress() place une adresse sur l'interface que l'application construit, addRoute() ajoute un préfixe de destination, et establish() refuse de créer l'interface tant qu'au moins une adresse n'a pas été ajoutée. Un client OpenVPN fait correspondre le profil et les options poussées par le serveur exactement à ces appels, si bien qu'une connexion qui n'analyse jamais d'adresse ne peut pas construire l'interface du tout.

C'est pourquoi la ligne de journal que vous lisez peut nommer une route alors que la cause se situe une étape plus tôt. Le client n'atteint l'étape de la route qu'une fois l'interface créée ; sans adresse, l'appel de route échoue immédiatement ou ne s'exécute jamais. Quand le journal dit qu'il ne peut pas ajouter de route, commencez par l'adresse et non par la syntaxe de la route.

Vérification 1 : le serveur met-il une adresse dans la réponse ?

Pour un service OpenVPN routé, l'adresse vient du pool du serveur ou d'une attribution par client, et la topologie décide de sa forme. Sur un serveur OpenVPN 2.4 ou ultérieur, un service en topologie sous-réseau ressemble à ceci :

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Avec cette forme, le serveur pousse quelque chose comme ifconfig 10.8.0.6 255.255.255.0. Un déploiement plus ancien en topology net30 pousse à la place une adresse de pair, par exemple ifconfig 10.8.0.6 10.8.0.5, si bien qu'un profil déplacé entre les deux modèles peut sembler correct tout en portant le mauvais masque de réseau.

Cherchez dans le journal de connexion du client l'ensemble des options poussées. S'il ne contient aucune ligne ifconfig, le serveur n'a jamais envoyé d'adresse ou le client a refusé l'option. Sur un serveur qui utilise client-config-dir, le fichier nommé d'après le common name du certificat doit exister et porter l'attribution :

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Vérification 2 : le client conserve-t-il l'adresse qu'on lui a donnée ?

Un filtre trop large est la deuxième cause courante. pull-filter existe dans OpenVPN 2.4 et ultérieur, et lorsque plusieurs filtres correspondent à la même option, le dernier correspondant l'emporte : un catch-all placé à la fin supprime donc l'adresse sans erreur :

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Restreignez le filtre à l'option dont vous voulez vraiment vous débarrasser et laissez l'adresse tranquille :

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Le conseil de désactiver tous les pull vient généralement de quelqu un qui cherche à se débarrasser d'une seule route. route-nopull est l'interrupteur plus étroit : il conserve ifconfig et les autres options poussées tout en refusant les routes poussées et les options de type DHCP. Utilisez-le quand c'est réellement ce que vous voulez, et traitez la question de l'adresse séparément.

Vérification 3 : l'adresse est-elle à vous de saisir ?

L'adressage manuel n'est légitime que lorsque l'exploitant vous remet la valeur. Si vous en saisissez une vous-même, elle doit provenir du sous-réseau du client VPN, être unique parmi les sessions actives et correspondre à la topologie que le serveur exécute. Copier l'adresse d'un pont de bureau ou d'un hôte du LAN distant échoue sur les deux points : le téléphone revendiquerait une adresse qui existe déjà ailleurs, et la passerelle n'aurait aucun chemin de retour vers elle.

Le préfixe du LAN distant dans une route est une destination, jamais l'identité du téléphone. Une route pour 10.60.0.0/24 dit d'atteindre ce réseau par le tunnel ; elle ne dit rien de l'adresse 10.60.0.x que le téléphone devrait détenir, et le téléphone ne devrait en détenir aucune. Les attributions statiques appartiennent au côté serveur, où elles ne peuvent pas entrer en collision avec le pool dynamique.

Deux sessions sur une même identité exposent la même collision. Si le même certificat se connecte deux fois et que le serveur pousse une adresse fixe aux deux, la seconde session duplique la première, et la solution est de séparer les identités'ou les attributions plutôt que de modifier le client.

Vérification 4 : autre chose occupe-t-il l'emplacement du tunnel ?

Android n'autorise qu'un seul service VPN actif à la fois. Une autre application VPN, ou une entrée VPN toujours actif laissée activée pour un profil qui ne fonctionne plus, peut prendre cet emplacement avant que votre client OpenVPN n'appelle establish(). L'interface n'apparaît'alors jamais même si le profil est valide : déconnectez l'autre VPN, désactivez le réglage toujours actif et reconnectez-vous avant de toucher au profil.

Un service qui exige un pont Ethernet est l'autre impasse. Une application Android non root peut créer un tunnel IP, pas un segment Ethernet ponté, donc aucune adresse que vous saisirez ne fera fonctionner un serveur dev tap ; l'exploitant doit proposer un service routé. Lorsque vous signalez le problème, indiquez le nom et la version du client, l'ensemble des options poussées, la topologie et l'étape exacte où l'adresse aurait dû apparaître.

Si les quatre vérifications passent et que l'adresse est présente, unique et correctement masquée, la question de la route devient la question ordinaire : quels préfixes le serveur autorise et comment le client doit les délimiter. Notez l'adresse du tunnel, son masque de réseau et la topologie avant de changer quoi que ce soit d'autre, car ces trois valeurs sont ce dont l'exploitant a besoin pour comparer avec la vue du serveur.