NAT ou votre propre IPv4 : ce qu'un seul port redirigé peut faire, et ce qu'il ne peut pas

La plupart des gens découvrent ce que veut dire NAT une dizaine de minutes après l'achat. Nginx démarre, curl localhost renvoie la page, et le navigateur du portable tourne dans le vide. Rien n'est cassé. Le serveur n'a simplement pas d'IPv4 publique à lui, et sa seule porte d'entrée est un port redirigé pour SSH.

Cette porte unique suffit pour une quantité surprenante de travail, et pas du tout pour certaines choses très courantes. Si vous hésitez encore entre les deux types d'offre, notre article plus ancien IP dédiée ou VPS NAT pose la seule question qui tranche. Celui-ci parle de la vie avec la réponse : ce qu'un serveur NAT sait faire en pratique, où il bute, et comment en sortir quand vous le dépassez.

Ce que vous obtenez vraiment

Un serveur NAT a une adresse privée derrière notre passerelle. Le tableau de bord affiche un hôte et un port personnel, et vous vous connectez ainsi :

ssh -p 20123 root@host

Ce port mène au port 22 de votre serveur. Tous les autres ports entrants en IPv4 sont fermés depuis l'extérieur, et il n'existe aucune option pour en rediriger davantage. En sortie, c'est une autre histoire : le serveur atteint tout Internet, sauf les ports SMTP 25 et 465, fermés sur toutes les offres, NAT ou non. Les règles complètes sont dans Réseau et ports.

Un détail de plus, qui compte pour certains : l'adresse sortante n'est pas la vôtre. Le trafic sort par une adresse que vous ne contrôlez pas, vous ne pouvez donc pas y définir de DNS inverse ni y construire une réputation d'expéditeur.

Ce qui tourne très bien derrière un seul port

Tout ce qui engage la conversation soi-même. Et la catégorie est plus large qu'il n'y paraît :

• Les bots qui interrogent. Un bot Telegram en long polling, un bot Discord sur sa connexion gateway, un bot de trading qui parle à l'API d'une plateforme d'échange. Tout est sortant.
• Les agents IA. Un agent qui appelle des API de modèles, navigue, écrit des fichiers et exécute du code n'a besoin de personne pour l'appeler. Il lui faut du CPU, de la mémoire et une connexion vers l'extérieur.
• Les workers et les scrapers. Tout ce qui récupère des tâches dans une file, parcourt des pages ou synchronise des données selon un planning.
• Les machines de build et les runners. Les runners CI s'enregistrent en général eux-mêmes auprès du serveur et vont chercher le travail, ils sont donc à l'aise en NAT.

Pour ce genre de charge, l'offre la moins chère suffit, honnêtement. Nano coûte 3 $ par mois pour 2 vCPU, 1 GB de RAM et 15 GB de disque ; Small 8 $ pour 4 vCPU, 4 GB et 35 GB. La liste complète se trouve sur une page dédiée aux offres NAT.

Là où un seul port ne suffit pas

Le mur, c'est tout ce où quelqu'un d'autre doit ouvrir la connexion.

Le site web est l'exemple évident. Les navigateurs se connectent au port 443 (et au 80 pour la redirection), et sur une offre NAT ces ports n'existent pas vu de l'extérieur. Un port non standard ne marche pas non plus, du moins pas d'une manière que les visiteurs accepteront.

Votre propre domaine en HTTPS se heurte deux fois au même mur. Vous pouvez faire pointer un enregistrement DNS vers l'adresse de la passerelle, mais rien de ce qui y arrive n'est transmis à votre serveur, à part votre port SSH. Et la méthode habituelle pour obtenir un certificat gratuit vérifie votre serveur sur le port 80 ou 443.

Les webhooks échouent en silence. Notifications de paiement, plateforme de bots qui pousse des mises à jour, serveur Git qui annonce un nouveau commit : tous doivent vous joindre. Le bot qui marchait parfaitement en long polling cesse de fonctionner à l'instant où vous le passez en webhooks.

Les points d'accès VPN, les serveurs de jeu et les serveurs de mail ont besoin de ports entrants par définition. Tout comme ce que vous voudriez ouvrir à un collègue dans un navigateur.

Les contournements, honnêtement

IPv6. Les nouveaux serveurs Linux reçoivent une adresse IPv6 publique, et sur les offres NAT elle atteint le serveur directement, sur n'importe quel port. Si tous les clients de votre service sont les vôtres (votre portable, vos autres serveurs, une sonde de supervision en IPv6), ça marche bien. Pour un site public, non : une partie des visiteurs est encore sur des réseaux sans IPv6 et ne chargera tout simplement jamais la page. Les offres Windows restent en IPv4 seulement pour l'instant.

Un tunnel. Vous pouvez faire tourner un petit agent qui maintient une connexion sortante vers un relais ailleurs, lequel renvoie le trafic public dans le tunnel. Ça fonctionne, et pour une démo ou un tableau de bord interne c'est raisonnable. Pour quoi que ce soit d'important, vous avez ajouté un tiers au milieu de chaque requête, plus une pièce de plus qui peut lâcher à trois heures du matin.

Un tunnel SSH pour vous-même. Si vous êtes la seule personne à avoir besoin du panneau d'administration, ne l'exposez pas du tout. Faites-le passer par le port SSH que vous avez déjà :

ssh -p 20123 -L 8080:localhost:8080 root@host

Ouvrez ensuite http://localhost:8080 sur votre machine. C'est l'astuce la plus sous-estimée sur un serveur NAT, et c'est de toute façon plus sûr que de mettre le panneau sur Internet.

Mon avis honnête : l'IPv6 et les tunnels SSH sont de bons outils. Un service public permanent qui passe par un tunnel uniquement parce que le serveur n'a pas d'IPv4, c'est en général le signe que vous avez dépassé le NAT.

Passer à votre propre IPv4 sans réinstaller

Inutile de tout reconstruire. Ouvrez le serveur dans le tableau de bord, choisissez « Changer d'offre » et une offre avec IP dédiée de même taille ou plus grande. Le serveur redémarre une fois et revient avec sa propre IPv4 publique, son disque et tout ce que vous avez installé. Les ports 80, 443 et tout ce que vous ouvrez dans le pare-feu deviennent joignables, et SSH passe sur le port 22 habituel. Les détails sont dans Changer d'offre.

Quelques points à connaître avant de cliquer :

• Vous payez la différence au prorata pour le reste de la période en cours, depuis votre solde. Nano-IP coûte 8 $ par mois contre 3 $ pour Nano ; Small-IP 16 $ contre 8 $.
• Il faut une adresse libre dans l'emplacement de votre serveur. S'il n'y en a pas pour le moment, le tableau de bord le dit avant tout débit.
• Si vous avez modifié à la main la configuration réseau dans le serveur, vérifiez-la après le redémarrage. Sur une image standard, elle s'applique toute seule.
• Faites d'abord une sauvegarde. Ce n'est qu'un redémarrage, mais ce sont quand même vos données.

Là où le NAT ne convient pas, et où l'IPv4 non plus

Le NAT est le mauvais choix pour tout ce qui est public, pour tout ce qui reçoit des webhooks et pour tout ce qui a besoin d'une adresse fixe que quelqu'un met en liste d'autorisation. Ne passez pas des jours à le contourner. L'écart de prix entre Nano et Nano-IP est de 5 $ par mois.

Mais une IPv4 dédiée n'a rien de magique non plus. Elle ne fera pas entrer un site qui bloque les adresses de datacenters, et elle ne sauvera pas un scraper limité en débit, car ces décisions portent sur le réseau dans lequel vous êtes, pas sur qui d'autre utilise l'adresse. Et si tout votre projet tient en quelques bots et un agent, acheter une IPv4 sur laquelle personne ne se connectera jamais, c'est de l'argent jeté.

Si vous préparez de toute façon un passage à une configuration plus grosse, déménager un VPS sans interruption détaille l'ordre des opérations, et lire les caractéristiques d'un VPS vous aidera à comparer les offres.