Quel VPN permet un accès distant malgré le CGNAT ? Celui qui crée un chemin de retour, pas seulement une nouvelle IP

Le premier signe que quelque chose avait changé n’était pas une panne d’Internet.

C’était justement l’absence de panne.

La nouvelle connexion à la maison était rapide. Les sauvegardes cloud partaient normalement. Netflix fonctionnait. Les appels vidéo aussi.

Seul mon NAS avait disparu.

J’étais à Lyon pour deux jours et j’essayais d’ouvrir depuis mon portable un dossier resté chez moi. Jusqu’à la semaine précédente, j’utilisais une règle de port forwarding sur le routeur et un nom de domaine dynamique.

Ce n’était pas particulièrement élégant, mais ça marchait.

Cette fois: délai d’attente.

J’ai vérifié le nom de domaine.

Correct.

J’ai vérifié le port.

Correct.

J’ai redémarré le NAS.

Toujours rien.

Puis j’ai ouvert à distance l’interface du routeur et comparé son adresse WAN avec l’adresse publique que voyait Internet.

Elles n’étaient pas les mêmes.

La première commençait par 100..

À cet instant, le NAS a cessé d’être mon suspect principal.

J’avais ouvert la porte de mon appartement, pas celle de l’immeuble

Le 24 juillet 2026, l’Arcep a mis à jour sa page consacrée à l’épuisement des adresses IPv4. Elle y rappelle pourquoi les opérateurs utilisent le Carrier-Grade NAT: plusieurs abonnés peuvent partager une même IPv4 publique. Parmi les conséquences concrètes, elle cite justement la difficulté d’accéder à distance à un NAS ou à certains équipements de maison connectée.

C’était exactement ma situation.

Mon routeur traduisait déjà les adresses entre mon réseau domestique et Internet. Le fournisseur en ajoutait maintenant une seconde couche dans son propre réseau.

J’ai fini par me représenter cela comme un immeuble.

Ma règle de port forwarding avait parfaitement ouvert la porte de mon appartement.

Mais la porte principale de l’immeuble appartenait désormais à l’opérateur.

Et je n’avais pas les clés.

La plage 100.64.0.0/10 n’est d’ailleurs pas une adresse privée domestique ordinaire: l’IETF l’a réservée comme espace partagé pour les déploiements de CGNAT.

Une fois cela compris, redémarrer le routeur une cinquième fois n’avait plus beaucoup de sens.

Mon premier réflexe a pourtant été d’ajouter un VPN

Le raisonnement paraissait évident.

Si l’adresse attribuée par mon fournisseur empêchait d’entrer chez moi, un VPN pouvait me donner une autre adresse.

J’ai donc installé un grand VPN commercial sur la petite machine qui restait allumée à côté du NAS.

Connexion établie.

Nouvelle IP publique.

Je suis retourné sur mon portable.

Toujours aucun NAS.

C’est là que j’ai compris la distinction qui change tout avec le CGNAT.

Un VPN classique sait très bien faire sortir une connexion par son serveur.

Cela ne veut pas dire qu’il crée automatiquement une route permettant à une connexion initiée depuis Internet de revenir jusqu’à votre machine.

En plus court:

une nouvelle adresse de sortie n’est pas une porte d’entrée.

Le CGNAT avait fermé cette porte côté opérateur. Empiler un autre tunnel sortant ne la rouvrait pas.

Cette confusion revient souvent chez les personnes qui découvrent le CGNAT après avoir installé un NAS, Plex ou un petit homelab. Dans une discussion publiée en juillet 2026 sur r/homelab, un utilisateur racontait avoir passé un mois à essayer d’obtenir une IPv4 publiquement routable auprès de son opérateur avant de chercher une autre voie vers ses services.

Je me suis reconnu moins dans son installation que dans son changement de question.

On commence par:

« Quel port ai-je mal configuré? »

Puis on finit par demander:

« Comment créer un chemin de retour alors que l’IPv4 publique n’est même plus à moi? »

Un VPN avec port forwarding a réellement ouvert une porte

J’ai donc essayé la solution la plus directe: un fournisseur qui propose explicitement le port forwarding.

Proton VPN documente cette fonction sur ses offres payantes. Le principe est simple: le serveur VPN reçoit une connexion sur un port public et la transmet jusqu’à l’appareil connecté au tunnel.

Cette fois, quelque chose a changé.

J’ai activé le port forwarding.

J’ai configuré un service de test sur la machine distante.

Depuis mon portable, la connexion est arrivée.

Pour la première fois depuis le changement de réseau, une requête initiée depuis l’extérieur atteignait réellement une machine située derrière le CGNAT.

Le diagnostic était donc confirmé.

Quand une application a besoin d’un véritable port entrant, un VPN qui offre le port forwarding peut recréer cette porte malgré l’absence d’IPv4 publique à la maison.

Mais je me suis vite rendu compte que mon besoin était plus large.

Je ne voulais pas publier un seul service vers Internet.

Je voulais retrouver mon petit réseau privé.

Le NAS aujourd’hui.

Home Assistant demain.

Peut-être SSH sur une machine plus tard.

Et je ne voulais pas transformer chaque nouveau service en nouvelle porte exposée.

Le port fourni par Proton peut aussi changer après une reconnexion, ce qui oblige l’application concernée à suivre ce changement. Sa documentation rappelle également qu’un port ouvert augmente la surface exposée.

Le port forwarding avait donc résolu le problème technique.

Il ne correspondait simplement pas à la manière dont je voulais vivre avec mon NAS.

J’ai arrêté d’essayer de rendre ma maison publiquement joignable

La solution qui a rendu le NAS banal à nouveau reposait sur l’idée inverse.

Au lieu d’attendre qu’une connexion inconnue venue d’Internet trouve le chemin jusqu’à chez moi, j’ai demandé aux deux appareils de construire eux-mêmes leur chemin privé.

J’ai installé un VPN maillé sur une machine de mon réseau domestique et sur mon portable.

Ce type de réseau essaie d’établir directement une liaison entre les appareils à travers les NAT. Si le CGNAT empêche cette liaison directe, un relais peut prendre le relais. Tailscale documente précisément cette logique de traversée de NAT et de relais lorsque le réseau ne permet pas une connexion directe.

En pratique, c’était beaucoup moins technique que l’explication.

J’ai installé.

J’ai associé les deux appareils.

J’ai ouvert l’adresse privée du NAS.

La page de connexion est apparue.

J’ai cliqué sur le dossier que je cherchais depuis le début.

Le fichier était là.

Je l’ai téléchargé.

Terminé.

Le routeur de la maison était toujours derrière CGNAT.

Je n’avais toujours pas d’IPv4 publique.

Je n’avais demandé aucun port à mon opérateur.

Et surtout, je n’avais pas rendu l’interface entière du NAS directement accessible depuis Internet.

J’avais simplement choisi un tunnel conçu pour relier des appareils entre eux.

C’est devenu mon critère principal: derrière CGNAT, la capacité à construire le chemin entre deux appareils compte davantage que la quantité de serveurs affichés dans une application.

C’est aussi là que j’ai arrêté de demander à un seul VPN de faire deux métiers

Cette conclusion a changé la place de OnlydogVPN dans mon installation.

Au départ, j’essayais de mettre tous mes besoins dans la même boîte:

accéder au NAS;

protéger mon navigateur sur le Wi-Fi d’un hôtel;

changer ma route Internet;

garder une connexion stable lorsque le réseau devient mauvais.

Mais ces tâches n’ont pas besoin du même type de tunnel.

Pour faire entrer une connexion jusqu’à une machine placée derrière CGNAT, il faut une solution pensée pour le port forwarding ou pour relier directement plusieurs appareils à travers les NAT.

Le petit service ne prétend pas transformer une machine derrière CGNAT en serveur publiquement joignable. Ses propres contenus distinguent d’ailleurs clairement ce besoin d’un usage VPN ordinaire: lorsqu’un véritable port entrant est nécessaire, il faut un service qui l’offre explicitement.

Cette limite m’a plutôt rassuré.

Au lieu d’ajouter une fonction complexe et de me laisser deviner dans quel cas l’utiliser, l’application restait concentrée sur ce qu’elle faisait réellement pour moi en déplacement: protéger mon trafic Internet, retrouver une route simple et rester agréable à utiliser lorsque le réseau change.

Une fois l’accès au NAS confié au tunnel privé adapté, je n’avais plus besoin de faire passer tout mon ordinateur par ma maison.

Je pouvais ouvrir mon réseau privé lorsque j’avais besoin d’un fichier.

Puis revenir au VPN Internet pour le Wi-Fi de l’hôtel, le coworking ou une connexion mobile.

Cette séparation a rendu les deux usages plus simples.

Le NAS avait son chemin privé.

Internet avait son tunnel.

Et je ne demandais plus à un seul bouton « Connecter » de résoudre deux problèmes qui n’avaient rien à voir.

Le test CGNAT que je ferais désormais prend une minute

Si mon accès distant tombe en panne alors qu’Internet fonctionne normalement, je ne commence plus par changer dix paramètres.

Je compare l’adresse WAN affichée par le routeur avec l’adresse publique visible depuis Internet.

Si elles diffèrent, je regarde de plus près.

Et si l’adresse WAN appartient à la plage 100.64.0.0/10, le CGNAT devient immédiatement mon premier suspect.

À partir de là, je ne demande plus:

« Quel VPN possède le plus de serveurs? »

Je demande:

« Est-ce que je veux publier un service vers Internet, ou simplement relier mes propres appareils? »

Pour un port entrant précis, il me faut un VPN qui propose réellement le port forwarding.

Pour retrouver plusieurs appareils privés derrière des NAT, je préfère un réseau maillé capable de construire cette liaison ou de passer par un relais.

Et pour protéger le reste de mon trafic Internet, je garde un VPN conçu pour ce travail plutôt que de transformer ma maison en sortie obligatoire de tout mon ordinateur.

Mon premier réflexe avait été de chercher une meilleure adresse IP.

Le CGNAT m’a appris à chercher un chemin.

Pour retrouver un NAS derrière une IPv4 partagée, une nouvelle sortie ne suffit pas: il faut d’abord recréer le chemin jusqu’à la maison — puis laisser un VPN comme OnlydogVPN s’occuper du trafic Internet pour lequel il a réellement été conçu.