La règle du VPN unique sur Android ne bloque pas un serveur SSH hébergé

La croyance est assez répandue pour être traitée comme un fait : Android n'autorise qu'un seul VPN, donc un serveur SSH exécuté sur le téléphone ne peut pas fonctionner à travers ce tunnel. La première moitié est vraie et la conclusion ne suit pas. La limite de la plateforme porte sur le nombre d'applications qui peuvent occuper l'emplacement du service VPN, pas sur le nombre de sockets qui peuvent exister ni sur qui a le droit de se connecter au téléphone. Un démon SSH avec une socket en écoute est une application ordinaire avec un port ordinaire, et le tunnel est l'un des chemins que son trafic peut emprunter.

Ce que la règle du VPN unique limite réellement

VpnService est une ressource à emplacement unique. Quand une application établit un tunnel, elle devient le VPN de l'appareil, et une seconde application qui tente d'en établir un est refusée jusqu'à ce que la première disparaisse. C'est une règle sur la propriété du tunnel, et elle explique pourquoi deux clients VPN ne peuvent pas fonctionner en même temps.

Elle ne dit rien sur les sockets en écoute. Le serveur SSH n'appelle pas VpnService, n'intercepte pas les paquets et ne se dispute pas cet emplacement. Il lie un port et accepte des connexions, ce qui est exactement ce qu'il ferait sans VPN installé. Le mythe confond donc une limite sur les fournisseurs de tunnel avec une limite sur les connexions réseau, et les deux n'ont aucun rapport.

L'écouteur est une destination, pas une partie du tunnel

Une fois le tunnel établi, le téléphone y possède une adresse et l'appareil pair dispose d'une route vers cette adresse. C'est l'écouteur qui décide si quelque chose répond. Un démon lié à la boucle locale n'est joignable que depuis le téléphone lui-même ; un démon lié à l'ancienne adresse du tunnel peut conserver sa liaison après une reconnexion alors que l'adresse à laquelle il s'est lié a changé.

Les règles de liaison sont de la configuration SSH ordinaire : l'adresse et le port d'écoute, et qui peut s'authentifier. Sur Android, ces réglages résident dans la configuration propre à l'application, et le propriétaire du processus de l'application n'a peut-être pas le droit d'utiliser des ports privilégiés, si bien que l'habitude de bureau de lier le port 22 en root ne se transpose pas telle quelle.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Il y a ensuite l'autorisation sur le chemin lui-même. Un VPN grand public qui transporte volontiers le trafic web sortant n'a pas besoin d'autoriser du tout les connexions entrantes vers ses clients ; beaucoup ne le font pas, car cela exposerait un client à un autre. Si le pair ne peut atteindre l'adresse de tunnel du téléphone depuis nulle part, le problème se situe dans la politique du service et non dans le téléphone.

Le chemin de retour est là où cela casse le plus souvent

Supposons que le pair atteigne l'adresse de tunnel du téléphone et que le SYN arrive. La réponse doit maintenant sortir par le même chemin, et c'est une décision de routage à l'intérieur du téléphone. Si la réponse part par le Wi-Fi parce que c'est le réseau par défaut, le pair voit une connexion qui ne se termine jamais, ce qui ressemble exactement à un pare-feu.

Android complique la chose par rapport à un ordinateur de bureau, car le réseau par défaut est choisi par processus et peut être modifié par la politique de l'application VPN. Un client VPN peut ne router qu'une liste d'applications autorisées, si bien qu'une application serveur hors de cette liste continue d'utiliser le réseau physique pour ses réponses alors que le pair les attend par le tunnel.

Une application peut aussi lier ses propres sockets à un réseau précis, ce qui supplante la valeur par défaut. Quand vous lisez un rapport disant qu'un service est joignable depuis une adresse et pas depuis une autre, c'est généralement le mécanisme en cause.

Contourner le VPN ne répare pas un service entrant

Le contournement populaire, exclure l'application SSH du VPN pour que son trafic cesse d'être redirigé, est un correctif pour le problème inverse. Il aide quand le transport d'un client SSH sortant ne cesse de casser à cause du tunnel. Pour un serveur hébergé, il peut sortir les réponses du tunnel qu'utilise le pair, ce qui transforme une défaillance partielle en défaillance totale.

Il en va de même pour l'ouverture d'un port public sur le routeur. Si l'exigence est qu'un appareil autorisé atteigne le téléphone via le VPN, exposer SSH à internet relève d'un autre modèle de menace et non d'une réparation.

Décidez d'abord l'adresse du service : l'adresse LAN du téléphone, son adresse de tunnel ou un point de terminaison délibérément redirigé. Chacune a son propre contrat de joignabilité et d'exposition, et les mélanger est la façon dont un petit problème d'accès devient un trou permanent.

Diagnostiquez une direction à la fois

Notez quatre faits avant de changer la configuration : l'adresse à laquelle le pair se connecte, l'état de l'écouteur sur le téléphone, le contexte d'application et d'utilisateur qui le possède, et le chemin observé dans chaque direction. Un rapport qui dit que le VPN déconnecte SSH n'en contient aucun et ne peut pas distinguer un problème de transport côté client d'un serveur injoignable.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Lancez le contrôle de port depuis le pair, pas depuis le téléphone, et lisez la sortie détaillée du client SSH pour voir s'il échoue avant ou après la poignée de main TCP. Une socket qui ne se connecte jamais et une connexion rejetée sont des étapes différentes avec des responsables différents.

Gardez la vérification de clé d'hôte et les restrictions de compte intactes pendant le débogage. Restreindre l'écouteur et les utilisateurs autorisés est ce qui rend un serveur joignable acceptable ; les relâcher pour faire fonctionner une connexion échange un problème contre un pire. La référence du serveur OpenSSH couvre les contrôles d'écoute et d'accès si votre implémentation Android suit les mêmes noms de configuration.