Pourquoi l'adresse de votre tunnel VPN n'ouvre aucun port entrant

Connectez-vous au VPN du bureau, lancez un petit service sur le port 8443, envoyez l'adresse du tunnel à un collègue et regardez la connexion échouer alors que le client signale toujours qu'il est connecté. Rien n'est cassé dans le tunnel : l'adresse a été attribuée, la session est établie et les paquets qui porteraient la réponse ne sont tout simplement jamais admis. Effectuez les trois vérifications ci-dessous dans l'ordre et arrêtez-vous à celle qui échoue, car chacune a une correction différente et une seule concerne le VPN.

Commencez par où la socket est réellement liée

Avant que quoi que ce soit ne soit routé, quelque chose doit écouter sur une adresse que l'appelant peut atteindre. Les serveurs de développement sont le coupable habituel, car beaucoup se lient par défaut à loopback et n'acceptent que les connexions provenant de la même machine. Une adresse de tunnel ne change pas cette liaison, et le système d'exploitation refusera la connexion bien avant que le VPN n'entre en jeu.

ss -ltnp | grep 8443
netstat -ano | findstr 8443

Lisez la colonne de l'adresse locale plutôt que l'état. 127.0.0.1:8443 signifie loopback uniquement, et la correction est une liaison sur 0.0.0.0 ou sur l'adresse du tunnel elle-même. 0.0.0.0:8443 accepte sur toutes les interfaces, ce qui est plus large que ce que la plupart des gens visent lorsque la machine possède aussi une adresse publique ; 10.64.7.15:8443 est la version étroite qui n'écoute que là où le collègue peut l'atteindre. Notez aussi le nom du processus dans la même sortie, car une instance égarée d'un test précédent est une cause fréquente de port qui semble ouvert et répond avec le mauvais contenu.

Demandez ensuite si quelque chose peut router vers cette adresse

Une adresse de tunnel n'a de sens que pour les pairs configurés pour envoyer ce préfixe dans le tunnel. La machine du collègue possède sa propre table, et si elle n'a pas de route pour le sous-réseau du tunnel, le paquet part vers la passerelle par défaut et meurt dans un endroit qui ignore totalement l'existence de l'adresse. C'est une question de routage côté appelant, pas une autorisation côté vôtre.

Le serveur entre les deux clients compte tout autant. Dans la conception habituelle d'accès à distance, chaque client ouvre une connexion sortante vers la passerelle et celle-ci conserve l'état de ces flux, de sorte que les réponses reviennent par un chemin qu'elle connaît déjà. Une connexion d'un client à un autre est un nouveau flux que la passerelle doit accepter et transmettre, et beaucoup de déploiements le désactivent délibérément pour garder les clients isolés les uns des autres. Les services VPN grand public isolent généralement par défaut ; les passerelles d'entreprise l'autorisent parfois par groupe.

Vérifiez le sens avant de modifier quoi que ce soit sur l'hôte. Si l'adresse du tunnel répond depuis la passerelle elle-même mais pas depuis un pair, c'est le réglage client à client de la passerelle qui fait la différence, et aucune modification du pare-feu local ne peut le remplacer.

Enfin, trouvez la politique qui autorise le flux

Trois couches de politique se trouvent entre un paquet routé et un service qui répond : la décision de transmission du serveur VPN, le pare-feu de l'hôte et tout groupe de sécurité cloud devant l'instance. Les trois doivent s'accorder, et elles échouent de manières différentes, c'est pourquoi le symptôme du tableau ci-dessus est plus utile que le message d'erreur du navigateur.

Le pare-feu de l'hôte est la couche que l'on oublie après une liaison réussie, car une règle qui autorise le port sur l'interface LAN ne l'autorise pas automatiquement sur l'interface du tunnel. Les règles limitées à une interface sont une conception correcte et aussi la cause habituelle d'un service qui fonctionne depuis le bureau et pas depuis chez soi. Lisez la portée de la règle plutôt que son numéro de port.

Le filtrage avec état explique le cas inverse. Une connexion sortante depuis votre portable crée un état, et les réponses sont admises sans règle entrante. La connexion du collègue est un flux entièrement nouveau sans état derrière lui, elle a donc besoin d'une autorisation explicite. Cette asymétrie est toute la raison pour laquelle une session de navigateur qui fonctionne sur votre propre machine ne dit rien sur l'accessibilité du service depuis l'extérieur.

Quand une vérification échoue, changez la conception plutôt que le tunnel

Si l'exigence est qu'un collègue ouvre votre service local, la réponse honnête est généralement un mécanisme conçu pour l'accès entrant. Un tunnel SSH inverse est le plus petit : votre machine se connecte en sortie vers un hôte que le collègue peut déjà atteindre, et l'écouteur existe sur cet hôte.

ssh -N -R 8443:127.0.0.1:8443 [email protected]

Le relais a besoin de GatewayPorts clientspecified dans la configuration de son serveur SSH, sinon l'écouteur transmis se lie à loopback sur le relais et le collègue rencontre le même refus qu'avant. Pour tout ce qui dure plus d'un après-midi, un répartiteur de charge ou un ingress avec contrôle de santé et certificat pour le nom publié est le meilleur instrument, et un tunnel de site à site avec des routes pour les deux sous-réseaux est la bonne réponse lorsque deux réseaux doivent réellement communiquer.

Chacune de ces conceptions rend l'exposition explicite, et c'est le but. Un VPN déplace des paquets entre des réseaux que vous étiez déjà autorisé à utiliser ; il ne publie pas de service et ne transforme pas un portable en hôte exposé à internet. Décider laquelle des trois couches changer est la tâche, et le tunnel en fait rarement partie.