Un client VPN itinérant peut-il héberger un service pour le bureau ?

Votre portable de bureau peut se connecter depuis chez vous et tout de même fournir quelque chose dont le bureau a besoin, mais seulement lorsque trois décisions distinctes s'alignent. Le tunnel est le transport, l'adresse interne est la destination, et la politique décide qui a le droit de frapper. Traiter l'une de ces trois comme la réponse complète produit la plainte familière : l'hôte répond aux pings mais l'application ne se connecte jamais. Les rôles ne sont pas les mêmes, et la différence est exactement là où se trouve le travail de conception.

Le sens de la connexion ne dit rien du sens du service

Lorsqu'un client démarre un tunnel, il ouvre un chemin que les deux sens peuvent emprunter une fois qu'il existe. Savoir si une nouvelle connexion peut entrer du concentrateur vers ce client est une question de politique de passerelle, pas une propriété de celui qui s'est connecté. Sur un concentrateur OpenVPN routé, par exemple, le serveur a besoin d'une route vers l'adresse interne du client et d'un transfert qui autorise la relation de pair à pair.

Imaginez un système d'inventaire qui interroge un agent sur des portables itinérants, ou un développeur qui a besoin d'une API de test depuis un poste de travail à la maison. Les deux veulent que le côté bureau commence la conversation, ce qui est l'inverse du schéma habituel client-vers-serveur.

Les produits d'accès distant hébergés varient sur ce point, et cette variation n'est pas un défaut. Certains VPN de service géré bloquent délibérément les connexions non sollicitées vers les clients connectés, car leur modèle est client-vers-ressource et non ressource-vers-client. Lisez l'architecture documentée du produit avant de promettre à un collègue que son portable peut faire office de serveur.

Suivez le chemin de retour avant d'ouvrir un port

Le chemin comporte trois parties : une route sur la passerelle qui pointe vers l'adresse interne du client, une politique qui autorise l'appelant précis, et un service à l'écoute sur la cible. Chaque partie échoue différemment, c'est pourquoi « le VPN est monté » ne dit presque rien.

La bonne nouvelle, c'est que le chemin interne n'a pas besoin d'une redirection de port sur le routeur domestique du client. C'est tout l'intérêt de publier le service sur l'adresse du tunnel plutôt que sur l'adresse WAN du domicile, où l'exposition et les règles NAT seraient entièrement différentes. Un routeur domestique peut aussi refuser de hairpinner une connexion venant du bureau, si bien que la route WAN échoue pour des raisons sans rapport avec votre VPN. Garder le trafic à l'intérieur du tunnel évite les deux problèmes à la fois.

Vérifiez aussi le côté cible. Un service lié uniquement à 127.0.0.1 ne peut pas accepter une connexion arrivant sur l'interface du tunnel, quelle que soit la justesse des routes de la passerelle. Une règle de pare-feu de l'hôte qui n'autorise le port que depuis le sous-réseau local écartera aussi le trafic du bureau, et cette règle est indépendante de la politique VPN au-dessus.

Les noms et les adresses sont des décisions de conception

Une adresse à l'intérieur du tunnel n'est pas automatiquement un nom. Un enregistrement DNS privé que vous contrôlez est plus clair que d'espérer qu'un protocole de découverte traverse le tunnel, car la résolution de noms multicast de lien local reste sur le segment local et ne devient pas du DNS inter-sous-réseaux.

La stabilité de l'adresse compte tout autant. Si les clients VPN tirent d'un pool à baux courts, l'adresse interne du portable change entre les sessions et chaque favori, portée de pare-feu et contrôle de supervision construits dessus se cassent silencieusement. Utilisez une réservation ou un chemin de mise à jour dynamique documenté.

Accordez le nom avec celui qui possède l'identité VPN, afin que l'enregistrement, l'attribution d'adresse et la politique d'accès changent ensemble plutôt que dans trois tickets séparés.

Testez le service, pas l'appartenance

Depuis la cible, confirmez ce qui écoute et sur quelle adresse, puis confirmez la vue de la passerelle sur le chemin de retour :

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Testez maintenant depuis le côté bureau avec une vraie requête plutôt qu'un écho. Un curl réussi vers le service prouve la route, la politique et l'écoute en une fois, tandis qu'un ping réussi ne prouve que l'ICMP est autorisé. Si la requête échoue, remontez les trois parties au lieu d'élargir le pare-feu en espérant.

La disponibilité fait partie de la même conversation. Un portable dort, itinérant entre les réseaux et se déconnecte en fin de journée. Un service qui doit répondre à toute heure relève d'un hôte toujours allumé, tandis qu'un service au mieux peut rester sur le client avec cette limite écrite.

Publiez la ressource délibérément, avec un nom, une liste d'appelants autorisés et un propriétaire, et l'appareil distant devient un service pris en charge plutôt qu'un serveur accidentel.