Atteindre un poste de travail derrière NAT sans redirection de port

Deux extrémités derrière le NAT de l’opérateur et un routeur de bureau verrouillé ne laissent aucun port entrant à rediriger, et le réflexe est d’en demander un quand même. La meilleure question est de savoir quel côté peut sortir et quel service joignable a le droit de porter le trafic. Quatre conceptions répondent différemment à cette question et échouent différemment lorsqu’un chemin est bloqué. Choisir entre elles est une comparaison de garanties, non de noms de protocoles.

Quatre conceptions, quatre promesses différentes

Le tableau ci-dessous est la version courte. Lisez la colonne du milieu comme la promesse que vous pouvez tester et la colonne de droite comme la promesse que personne n’a faite.

La ligne qui s’applique dépend de la tâche plutôt que d’une préférence. Une session de bureau à distance, un shell d’administration et l’accès à tout un sous-réseau privé sont trois exigences qui n’ont pas besoin du même point d’entrée, même lorsqu’elles concernent par hasard la même machine.

Un concentrateur change qui sort, pas ce qui est autorisé

Dans une conception à concentrateur routé, l’ordinateur portable distant et le poste de travail, ou la passerelle du site devant lui, ouvrent chacun un tunnel sortant vers un service que les deux peuvent atteindre. Rien n’accepte de connexion non sollicitée sur le routeur du poste de travail, et c’est exactement pourquoi cette conception survit au NAT et fonctionne encore lorsque le site n’a pas d’adresse statique. Le concentrateur route ensuite le trafic entre les deux adresses internes selon sa propre politique.

Le coût est que le concentrateur doit exister, être joignable des deux côtés et être exploité par quelqu’un. Le filtrage sortant doit autoriser le transport, et un réseau qui le bloque fera échouer la conception même si aucune redirection de port n’était nécessaire.

Le point subtil est que joignabilité et autorisation sont deux décisions distinctes prises à des endroits différents. Une route vers un préfixe ne dit rien sur le service du poste de travail que l’identité peut utiliser, et une règle de pare-feu qui autorise le tunnel ne dit rien sur la capacité du compte à se connecter. Configurez les deux, testez les deux, et gardez la décision d’autorisation auprès du système qui possède la ressource plutôt qu’auprès de la table de routage.

Le franchissement ne fonctionne que si les deux piles l’implémentent

Le franchissement entre pairs est une capacité d’un système précis, non un réglage qui améliore un VPN. Interactive Connectivity Establishment rassemble plusieurs adresses candidates et teste des paires jusqu’à ce qu’une fonctionne : candidates hôte sur les interfaces locales, candidates réflexives de serveur construites à partir de ce qu’un NAT révèle, et candidates relayées allouées sur un relais. Une adresse privée seule n’est pas un chemin, car l’autre côté ne peut pas y router.

Le cas relayé mérite d’être compris avant d’être écarté. RFC 8656 décrit TURN comme un protocole dans lequel un client demande à un serveur une adresse de transport relayée et le serveur transmet le trafic entre ce client et ses pairs. Le relais porte donc les données, ce qui diffère nettement d’un annuaire qui ne fait qu’aider les extrémités à se rencontrer. Échanger l’adresse du relais avec le pair est une étape de coordination que l’application doit accomplir.

Ce que vous ne pouvez pas promettre, c’est un chemin direct. Le NAT symétrique et certains pare-feux d’entreprise déjouent le percement de trous, et lorsqu’ils y parviennent, le système revient à un relais ou échoue. Vous ne pouvez pas non plus conclure que deux extrémités traduites ne pourront jamais se parler ; une pile prise en charge avec repli sur relais existe précisément parce qu’elles le peuvent souvent. Décidez si la disponibilité ou le caractère direct compte le plus, puis vérifiez quel chemin le déploiement a réellement choisi au lieu de supposer le cas favorable.

Un courtier est plus étroit qu’un réseau

Lorsque l’exigence est une seule application, un courtier d’applications ou une connexion inverse lancée par le poste de travail peut être la plus petite réponse. Le poste de travail sort vers un courtier, le courtier authentifie l’utilisateur distant, et seule cette session d’application est transportée. Aucune route vers le sous-réseau du poste de travail n’est créée, si bien qu’une compromission de la session distante n’hérite pas d’un chemin vers chaque appareil à côté.

Cette étroitesse a un prix : chaque application supplémentaire a besoin de sa propre intégration, et tout ce que l’application suppose d’un réseau local, comme un partage de fichiers qu’elle ouvre sur un serveur proche, peut ne pas être joignable. Les courtiers concentrent aussi politique et journalisation en un seul endroit, ce qui est utile jusqu’à ce que cet endroit devienne la panne.

Comparez les frontières de confiance, puis testez le chemin

Un concentrateur qui termine les tunnels peut lire le trafic qu’il route. Un relais peut porter un échange protégé de façon indépendante lorsque l’application chiffre de bout en bout, et un courtier termine généralement la session qu’il présente. Établissez où la protection se termine réellement avant de décider que deux conceptions sont équivalentes parce que toutes deux sont chiffrées.

Vérifiez ensuite ce que le poste de travail peut réellement atteindre en sortie, car chaque conception ci-dessus en dépend. Exécutez ceci sur le poste de travail, en remplaçant le nom d’hôte que vous comptez utiliser.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

N’acceptez la conception qu’après que l’opération distante prévue réussit sous l’identité autorisée, qu’une identité non approuvée est refusée, et que le comportement lorsque le chemin direct ou relayé est indisponible est connu et documenté. Incluez une reconnexion et le contexte de démarrage habituel du poste de travail, car une session commencée au bureau via le LAN ne teste rien de ce dont l’accès distant dépend.