Détection de serveur NAT et recommandations de tunnel

Cet article explique comment le panneau identifie automatiquement un serveur NAT, distingue un « NAT avec ports configurables » d'un « NAT sans ports configurables », et guide l'utilisateur vers le Tunnel et maintenance lorsque c'est nécessaire.

À savoir d'abord : qu'est-ce que le NAT

Un serveur NAT est un serveur « qui n'a qu'une adresse IP privée et aucune IP publique dédiée ». C'est le cas de nombreux VPS NAT bon marché : l'hébergeur attribue une adresse privée (comme 192.168.x.x), inaccessible directement depuis l'extérieur ; on y accède uniquement via la redirection de ports fournie par l'hébergeur (un port public renvoyé vers votre réseau interne).

Présentation de la fonctionnalité

Après l'ajout d'un serveur, lorsque la connexion SSH réussit, le panneau détecte automatiquement si la machine est de type NAT (uniquement des adresses privées en local, aucune IP publique dédiée). En cas de détection NAT, un petit badge apparaît sur la carte du serveur et un encadré explicatif s'affiche en haut de « Vue d'ensemble ». L'utilisateur peut cliquer sur le badge jaune pour confirmer si ce serveur NAT permet de configurer la redirection de ports dans le panneau de l'hébergeur, et donc décider si le Tunnel et maintenance est nécessaire.

Pourquoi distinguer les NAT

« IP privée » ≠ « besoin de tunnel ». Les serveurs NAT se répartissent en deux catégories :

Seul un « NAT sans ports configurables » nécessite le Tunnel et maintenance. Le NAT avec ports configurables permet de mapper soi-même ses ports et s'utilise comme une machine publique : inutile de le rappeler sans cesse.

Principe de détection

Après une connexion SSH réussie, le panneau exécute la commande en lecture seule ip -4 addr show pour lire les adresses IP des cartes réseau locales du serveur, et déterminer si elles appartiennent toutes à des plages privées :

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10 (NAT opérateur CGNAT)
• 127.0.0.0/8, 169.254.0.0/16, 0.0.0.0/8

Dès qu'une seule adresse de plage publique existe, la machine est jugée « avec IP publique » (non NAT) ; si toutes sont privées, elle est jugée « NAT ».

> La commande de détection est en lecture seule : elle ne modifie aucun état du serveur. Le résultat est stocké en base de données et la détection n'a lieu qu'à la première connexion ; ensuite le résultat est réutilisé tel quel, sans ralentir la connexion.

Emplacements du badge et des explications

Après détection d'un NAT, les informations sont présentées à deux endroits :

1. Onglet « Vue d'ensemble » du panneau de gestion système : après avoir cliqué sur « Gestion système » sur une carte de serveur, le premier onglet « Vue d'ensemble » affiche la bannière NAT correspondante — les serveurs marqués en jaune affichent une explication jaune (avec la marche à suivre pour retirer le marquage), les serveurs marqués en rouge affichent un guide rouge vers le tunnel. L'avertissement n'apparaît que sur les serveurs NAT non confirmés en connexion directe, pour ne pas encombrer la carte.

2. Petit badge sur la carte : la carte ne conserve qu'un petit badge, en trois états :

Le badge jaune NAT correspond à l'état « en attente de confirmation » : un clic ouvre une boîte de confirmation avec deux choix :

• « Les ports sont sans problème, retirer le marquage » → le badge disparaît et n'apparaîtra plus ;
• « Les ports sont inaccessibles, marquer comme nécessitant un tunnel » → le badge devient rouge et guide vers le Tunnel et maintenance.

Le badge rouge Tunnel requis est un « avertissement » : un clic mène directement au Tunnel et maintenance + Tunnel de ports.

> Pourquoi ne pas « tester automatiquement l'accessibilité des ports » : le serveur du panneau et le serveur cible peuvent se trouver dans le même centre de données, le test passerait alors par le réseau interne — un test « réussi » ne garantit pas qu'un visiteur externe y accède. Le marquage « tunnel requis » est donc fait manuellement par l'utilisateur dans la boîte d'explication jaune.

Pourquoi un serveur NAT « se déconnecte au bout d'un moment »

Les serveurs NAT subissent un idle timeout (expiration des connexions inactives) au niveau de la passerelle de l'hébergeur. Après quelques minutes d'inactivité SSH, la passerelle coupe discrètement la connexion (TCP semi-ouvert), sans que les deux côtés s'en aperçoivent.

Le panneau y remédie totalement grâce à deux mécanismes :

1. keepalive activé sur les connexions SSH : après établissement de chaque connexion, un paquet de maintien de vie est envoyé toutes les 30 secondes, ce qui évite la coupure par inactivité NAT et détecte rapidement les connexions à demi mortes.

2. Nettoyage périodique du pool de connexions : un thread d'arrière-plan ferme toutes les 2 minutes les connexions inactives depuis plus de 2 minutes, évitant l'accumulation infinie de connexions à demi mortes.

Points d'attention

1. La détection dépend d'une connexion SSH réussie : si le serveur est hors ligne ou le mot de passe erroné, la détection est impossible et aucun badge ne s'affiche.

2. Serveurs sans badge : les serveurs publics, les appareils Android (Termux) et les appareils déjà tunnelisés (avec tunnel_token) n'affichent pas de badge NAT — ils passent par leurs propres canaux et n'ont pas besoin de ce rappel.

3. Cas particuliers laissés ouverts : de très rares « NAT 1:1 » (tous les ports ouverts) ont aussi une IP locale privée et sont détectés comme NAT. Dans ce cas, l'utilisateur choisit « d'accord » dans la boîte de confirmation, sans impact sur l'usage.

4. Modifiable après confirmation : l'état du badge dépend de la confirmation de l'utilisateur et peut être ajusté à tout moment en cliquant dessus.

Documentation associée

• Gestion des serveurs
• Tunnel et maintenance
• Tunnel de ports