Vous avez monté un cluster Proxmox propre à la maison, déployé Nextcloud, Vaultwarden, votre serveur mail, votre wiki, votre Matomo — et au moment d'ouvrir le port 443 pour rendre tout ça accessible depuis l'extérieur, vous découvrez que votre FAI vous a attribué une adresse IP dans le bloc 100.64.0.0/10. C'est du CGNAT (Carrier-Grade NAT) : votre IP publique apparente est partagée avec d'autres clients, vous ne contrôlez plus la traduction d'adresse, et toute tentative de port-forwarding échoue silencieusement.
Mauvaise nouvelle : c'est une situation de plus en plus fréquente, particulièrement chez les opérateurs mobiles (4G/5G fixe, box rurales) et les FAI alternatifs low-cost. Bonne nouvelle : il existe au moins cinq façons de contourner ce verrou, et l'une d'elles préserve 100 % de la souveraineté du trafic.
Pourquoi le CGNAT bloque tout
Dans une configuration internet classique, votre box reçoit une IP publique unique et fait du NAT entre votre LAN privé et l'extérieur. Vous pouvez configurer un port forwarding 443 → 192.168.1.10:443 sur votre box et tout fonctionne. Sous CGNAT, c'est différent : votre box reçoit une IP du bloc privé 100.64.0.0/10, et c'est un routeur en amont chez le FAI qui mutualise plusieurs centaines d'abonnés derrière une seule IP publique. Vous n'avez aucun accès à ce routeur d'opérateur.
Conséquence : vos requêtes sortantes fonctionnent normalement (HTTP, SSH, WireGuard sortant). Mais aucune connexion entrante depuis Internet ne peut atteindre votre LAN — le FAI ne sait pas à quel client envoyer le paquet TCP SYN sur le port 443.
Cinq stratégies de contournement
1. Tunnel Cloudflare
Configuration la plus simple : installer le démon cloudflared sur l'hôte interne, il établit un tunnel sortant vers Cloudflare et expose vos services sur un sous-domaine cloudflare. Zéro configuration réseau, fonctionne en 10 minutes.
2. Tunnel SSH inverse
La méthode la plus rapide : ssh -N -R 0.0.0.0:443:127.0.0.1:443 user@mon-vps. Le VPS ouvre son port 443 et redirige tout le trafic dans le tunnel SSH. Souverain (votre VPS), simple à mettre en place. Le revers : fragile sur les longues durées, latence ajoutée non négligeable, et SSH n'est pas optimisé pour du trafic web haut débit. Bon pour du débogage ou de l'accès admin ponctuel, mauvais pour de la production.
3. frp (Fast Reverse Proxy)
Outil open-source écrit en Go, démon serveur sur le VPS + client sur le LAN domestique. Exposition de ports TCP/UDP arbitraires. Plus performant que SSH-R, plus simple que WireGuard. Moyennement souverain (dépend du projet upstream), reste une bonne option pour qui veut éviter la complexité de WireGuard.
4. VPN site-à-site pfSense vers pfSense
Solution d'entreprise multi-sites : un pfSense au domicile, un pfSense sur un VPS, tunnel IPsec ou OpenVPN entre les deux. Très robuste, mais demande deux machines pfSense dédiées et une vraie expertise réseau. Surdimensionné pour un homelab unique, parfait pour relier plusieurs sites professionnels.
5. VPS européen + WireGuard + socat (recommandé)
La solution la plus équilibrée : un VPS chez un hébergeur souverain européen (Hetzner, OVH, Scaleway, Infomaniak) comme passerelle, un tunnel WireGuard chiffré entre le VPS et l'hôte Proxmox, et un relais socat qui projette le trafic public 443 du VPS vers les services internes via le tunnel. Chiffrement bout-en-bout, souveraineté totale, performances natives WireGuard.
Architecture finale détaillée
Voici comment les paquets circulent dans la solution recommandée. Un client final attaque le port 443 du VPS, qui passe par le reverse proxy public, puis socat encapsule le flux TCP dans le tunnel WireGuard chiffré, qui ressort sur l'hôte Proxmox derrière le CGNAT, puis un second socat (ou directement le service LXC) reçoit le flux.
Configuration WireGuard côté client (Proxmox)
On installe WireGuard directement sur l'hôte Proxmox (ou dans un LXC dédié si vous préférez l'isoler). Le fichier de configuration ressemble à ceci.
# /etc/wireguard/wg0.conf (cote Proxmox derriere CGNAT)
[Interface]
PrivateKey = <cle_privee_proxmox>
Address = 10.66.66.2/32
MTU = 1280
[Peer]
PublicKey = <cle_publique_du_vps>
Endpoint = vps.exemple.fr:51820
AllowedIPs = 10.66.66.1/32
PersistentKeepalive = 25La directive MTU = 1280 est elle aussi importante : elle évite la fragmentation des paquets UDP encapsulés sur les réseaux mobiles à MTU réduite. C'est la valeur officiellement recommandée par WireGuard pour les chemins peu fiables.
Configuration WireGuard côté VPS
# /etc/wireguard/wg0.conf (cote VPS public)
[Interface]
PrivateKey = <cle_privee_vps>
Address = 10.66.66.1/32
ListenPort = 51820
[Peer]
PublicKey = <cle_publique_du_proxmox>
AllowedIPs = 10.66.66.2/32# Activation au demarrage sur les deux cotes
systemctl enable --now wg-quick@wg0
# Verifier que le tunnel est etabli
wg show wg0
# latest handshake doit etre < 2 minutesRelais socat sur le VPS
Une fois le tunnel WireGuard établi, on configure socat sur le VPS pour relayer le trafic TCP du port public vers l'IP interne du Proxmox dans le tunnel. On encapsule ça dans une unité systemd pour avoir un service redémarrable proprement.
# /etc/systemd/system/socat-nextcloud.service
[Unit]
Description=socat relay 443 vers Nextcloud via WireGuard
After=network-online.target wg-quick@wg0.service
Requires=wg-quick@wg0.service
[Service]
Type=simple
ExecStart=/usr/bin/socat -d -d TCP4-LISTEN:8443,reuseaddr,fork TCP4:10.66.66.2:443
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.targetsystemctl daemon-reload
systemctl enable --now socat-nextcloud.service
systemctl status socat-nextcloud.serviceReverse proxy public devant socat
Pour gérer plusieurs services sur le même port 443 public, on place Nginx (ou Traefik) en frontal. Chaque vhost route vers un socat différent selon le server_name.
# /etc/nginx/sites-enabled/nextcloud.conf (sur le VPS)
server {
listen 443 ssl http2;
server_name cloud.exemple.fr;
ssl_certificate /etc/letsencrypt/live/cloud.exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cloud.exemple.fr/privkey.pem;
client_max_body_size 10G;
proxy_request_buffering off;
location / {
proxy_pass http://127.0.0.1:8443;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Sécurité du tunnel
- Les clés WireGuard sont chiffrées sur le disque du Proxmox via LUKS si l'hôte est physiquement vulnérable.
- Le pare-feu du VPS n'autorise que le port 51820 UDP (WireGuard) et 443 TCP (reverse proxy public). SSH d'admin restreint par IP source.
- Le tunnel WireGuard est lui-même chiffré (ChaCha20-Poly1305). Le trafic socat à l'intérieur est en clair côté tunnel mais déjà chiffré par TLS côté application (Nginx termine en TLS face au client, et le service interne fait son propre TLS si nécessaire).
- Pour un chiffrement strict bout-en-bout sans aucune terminaison TLS sur le VPS, utiliser un
stream { ssl_preread; }Nginx avec routage par SNI au lieu d'un vhost HTTP classique.
Limites et pièges
- Latence supplémentaire — 5 à 30 ms selon l'éloignement du VPS. À placer dans la même région que vos utilisateurs.
- Bande passante limitée par le lien VPS — un VPS 1 Gbps suffit largement, mais à vérifier selon votre usage.
- Si le VPS tombe, tous les services exposés deviennent inaccessibles. Prévoir un monitoring externe (UptimeRobot, ou un second VPS de secours en DNS round-robin).
- Le coût d'un VPS d'entrée de gamme tourne autour de 5 à 10 € par mois chez les hébergeurs souverains européens. À intégrer dans le TCO du projet.
- Les services UDP (jeux, VoIP) demandent une configuration socat ou Nginx stream différente — bien réfléchir au protocole transporté avant d'ajouter un service.
Conclusion
Le CGNAT n'est pas une fatalité. Avec un VPS européen à quelques euros par mois, WireGuard et socat — tous trois open-source et matures — on obtient une exposition publique de ses services Proxmox aussi performante qu'avec une IP fixe directe, en gardant 100 % de la souveraineté du trafic. C'est plus de boulot qu'un tunnel Cloudflare, mais c'est cohérent avec la démarche : si on quitte les GAFAM, on ne les fait pas rentrer par la cave.
Pour aller plus loin sur l'infrastructure derrière ce tunnel, le guide PBS détaille comment protéger l'ensemble du parc avec une politique de sauvegarde de classe entreprise, et le comparatif Proxmox vs TrueNAS vs Unraid aide à choisir le bon socle si vous repartez de zéro.
