Android OpenVPN : ajouter une route privée sans rooter le téléphone

Il vous faut un sous-réseau privé de plus — disons 10.60.0.0/24 — que le profil ne contient pas actuellement. Sur un ordinateur portable, vous ajouteriez une route et passeriez à la suite. Sous Android, le VPN est une application, l'interface tun appartient à cette application, et il n'y a pas de table de routage à modifier sans root. La route doit tout de même exister, mais elle va dans le profil que le client charge, et elle ne fonctionne que si l'autre extrémité est d'accord. Voici la modification, la reconnexion, le côté serveur et le retour arrière.

Avant la modification : ce qu'une route peut et ne peut pas faire

Une route répond à une seule question : quelle interface doit porter le trafic vers cette destination. Elle n'autorise rien. Si le propriétaire du réseau n'a pas accepté que ce téléphone atteigne ce sous-réseau, une route correcte produit une configuration d'apparence correcte et un rejet silencieux à la passerelle, et vous passerez l'heure suivante à modifier le mauvais fichier.

Obtenez cet accord d'abord, par écrit si le réseau a un propriétaire. Notez ensuite ce que vous ne faites pas : vous n'attribuez pas au téléphone une adresse à l'intérieur de ce LAN, vous ne changez pas l'écouteur du serveur, et vous ne choisissez pas un site par nom d'hôte. Ce sont quatre changements différents et seul le premier est le vôtre.

Modifiez le profil que le client charge réellement

Pour un client compatible qui importe du texte d'options OpenVPN ordinaire, l'ajout tient en une ligne :

route 10.60.0.0 255.255.255.0

Ajoutez-la au corps du profil, près des autres directives de routage, en conservant l'endpoint, les certificats, la gestion des clés et les lignes de vérification de l'opérateur exactement comme ils étaient. Ne collez pas un exemple ancien entier pour emprunter une ligne : la compression, les chemins de fichiers absolus et les réglages de chiffrement obsolètes voyagent avec lui et vous coûteront une séance de débogage séparée.

L'étape que les gens ratent, c'est la propriété du fichier. Si l'application a importé un profil, la copie qu'elle utilise lui appartient, et modifier l'original téléchargé ne change rien. Utilisez l'éditeur pris en charge par le client, ou réimportez le fichier modifié via le chemin de mise à jour, et confirmez le nom du profil actif lorsque plusieurs noms similaires existent. Notez lequel vous avez modifié.

Si le profil porte déjà route-nopull, aucune route du serveur n'est installée et chaque préfixe dont le téléphone a besoin doit être listé explicitement. C'est une conception légitime, mais cela signifie qu'une ligne omise ressemble exactement à un refus du serveur.

Reconnectez et vérifiez sur l'appareil

Déconnectez d'abord, puis reconnectez le profil précis que vous avez modifié au lieu de laisser l'application restaurer la dernière session. Ouvrez le journal de connexion et confirmez que le client a analysé la nouvelle ligne ; une directive de route ignorée par l'interface est un résultat courant quand on modifie la mauvaise copie.

Testez la destination par adresse, pas par nom. Un contrôle TCP vers un port de service connu est plus informatif qu'un ping, car beaucoup d'hôtes répondent à ICMP alors que le port de service est filtré. Si l'adresse répond et qu'un nom ne répond pas, vous avez une question de résolveur plutôt que de routage, et la section suivante n'est pas pour vous.

Deux contrôles de portée ont aussi leur place ici. Le VPN par application signifie qu'une route d'adresse peut être présente alors que l'application avec laquelle vous testez est hors de l'ensemble inclus, donc testez avec une application réellement incluse. Et un préfixe IPv4 ne dit rien du chemin IPv6 ; si le service est dual-stack, ajoutez la route IPv6 correspondante ou attendez-vous à ce que le client préfère un chemin que vous n'aviez pas prévu.

Un résultat négatif mérite d'être reconnu tôt : si une route de tunnel complet couvre déjà 0.0.0.0/0, le préfixe ne manque pas et l'ajouter de nouveau ne change rien. Une couverture en double ne répare ni un refus côté serveur ni une réponse absente.

Terminez le chemin sur le serveur

Trois choses doivent être vraies au-delà du téléphone. La passerelle a besoin d'une route vers la destination et de l'autorisation de transmettre la source du téléphone vers elle. La cible doit accepter cette source et renvoyer les réponses par la passerelle, sinon la conception a besoin d'une traduction délibérée en sortie. L'option route du manuel OpenVPN couvre la directive côté client ; le transfert et le routage de retour sont des réglages distincts sur des machines distinctes.

Si la destination se trouve derrière un autre client VPN plutôt que directement derrière la passerelle, le serveur a besoin d'un iroute pour le sous-réseau de ce pair. Cette directive appartient au serveur et décrit quel client possède un préfixe ; un téléphone ne peut pas la fournir depuis son propre profil, et aucune quantité de modification côté client ne la remplace.

Vérifiez explicitement le chemin de retour. Une réponse qui sort par la route par défaut au lieu du tunnel produit le symptôme classique de connexion à moitié ouverte : la connexion s'établit dans un sens et rien ne revient. La traduction de source sur la passerelle est un correctif légitime quand la cible ne peut pas router en retour, mais c'est une décision de politique avec ses propres conséquences.

Retour arrière et acceptation

Conservez le profil précédent avant de le modifier. Si le changement aggrave la situation, restaurez cette copie par le même chemin de réimportation, reconnectez, et confirmez que l'ancien comportement revient — cela confirme que vous avez changé ce que vous pensiez changer. Un retour arrière qui ne restaure pas l'ancien état signifie que l'application détient une troisième copie que vous n'avez pas trouvée.

Acceptez le changement lorsque quatre conditions tiennent, testées dans cet ordre après une reconnexion récente : la destination répond sur son port de service, le nom privé se résout s'il est attendu, HTTPS valide toujours le nom d'hôte prévu, et l'ensemble fonctionne encore après un redémarrage ou un passage du Wi-Fi au réseau cellulaire. Le dernier contrôle est celui qui attrape une route qui n'existe que jusqu'à ce qu'Android rétablisse le tunnel.

• Confirmez que le propriétaire du réseau autorise la destination avant toute modification.
• Placez la route dans le profil que le client charge, puis réimportez et reconnectez.
• Vérifiez par port de service, à l'intérieur de la portée par application, pour la bonne famille d'adresses.
• Corrigez le transfert, le routage de retour et l'iroute sur le serveur, pas sur le téléphone.
• Gardez une copie de retour arrière, et retestez après un redémarrage.