CGNAT et double NAT : tunnels SSH inverses vers votre Mac mini cloud quand le VNC entrant disparaît (2026)

Si votre accès grand public est derrière un CGNAT (NAT opérateur) ou un double NAT façon hôtel, ouvrir le TCP 5900 sur une box est souvent impossible : il n’y a tout simplement pas d’IPv4 publique stable mappée sur votre Mac de bureau. Pourtant la QA offshore a encore besoin du Partage d’écran ou de tests navigateur en local. Ce guide 2026 montre comment initier un tunnel SSH inverse sortant depuis ce Mac « piégé » vers une Mac mini ProxyMac à HK, JP, KR, SG ou aux États-Unis, puis faire transiter le flux VNC dans le transport chiffré pour ne plus dépendre de forwards imaginaires. Vous obtiendrez une matrice de décision (SSH inverse vs sortie SOCKS vs VPN d’entreprise), une liste de prévol avec trois signaux numériques (dont une sonde SSH de 90 secondes), un runbook en huit étapes et des garde-fous sécurité explicites, car exposer des protocoles de bureau n’est jamais du « set and forget ».

L’objectif : des mains à distance prévisibles sur macOS sans supplier les FAI pour des IP statiques : vous louez du métal prévisible à côté de votre région d’API via le catalogue tarifs, documentez le tunnel à côté des recettes SSH du centre d’aide, et cessez de traiter le CGNAT comme une faute morale du DevOps.

Pourquoi le CGNAT tue le Partage d’écran entrant classique

Le Partage d’écran traditionnel suppose que vous pouvez exposer le TCP 5900 ou relayer via les successeurs de Back to My Mac. Le CGNAT regroupe des milliers d’abonnés derrière une seule IPv4 publique : les règles de port forwarding sur votre box n’atteignent jamais le bord opérateur—il n’y a pas de liaison NAT 1:1 pour votre portable. Ajoutez un second NAT (routeur voyage + box FAI) : le traceroute peut être propre pendant que les SYN entrants meurent en silence. Les symptômes ressemblent à « ProxyMac est lent » alors que le vrai blocage n’a jamais touché la mini cloud.

• Règle de preuve : si l’IP WAN affichée par la box diffère de ce que curl ifconfig.me voit sur le même uplink, vous êtes probablement derrière du CGNAT.
• Illusion de latence : le RTT ICMP peut rester à 22 ms alors que le TCP entrant ne se termine jamais—les tables NAT filtrent, elles ne modifient pas le timing des échos.
• Dette opérationnelle : les équipes gaspillent 4 à 8 heures-ingénieur par incident à prouver le CGNAT au lieu d’automatiser le routage—documentez la topologie WAN à côté du choix de nom d’hôte.

Matrice : SSH inverse vs sortie SOCKS vs épingle VPN

Approche	Idéal quand	Temps de mise en place typique	Risques
SSH inverse (-R) vers une mini ProxyMac	Vous devez piloter l’interface graphique ou lier des services locaux uniquement joignables depuis le domicile	25–40 min durcissement inclus	Un GatewayPorts mal réglé élargit la surface—couplez avec la discipline bastion
Sortie SOCKS / proxy HTTP sur la mini	Vous n’avez besoin que de tests HTTP(S) géo ou de façonnage de sortie API	15 min	Ne résout pas à lui seul le Partage d’écran—voir le guide nœud de sortie proxy
Épingle VPN d’entreprise	L’IT impose l’inspection du split tunnel	60+ min d’approbations	Casse souvent les chemins UDP voix ; coordonnez avec le playbook routage VPN
IPv6 + IPsec	Le FAI délivre une IPv6 globale avec contrôle pare-feu	Très variable	Encore rare sur les uplinks colocation/APAC—gardez le repli SSH

Liste de prévol : trois chiffres avant de tunneliser

1. Le SSH sortant doit réussir en moins de 90 secondes depuis le Mac piégé vers le nom d’hôte de la mini—sinon corrigez d’abord DNS ou MTU (article DNS, article MTU).
2. Choisissez une stratégie de liaison distante : loopback uniquement (127.0.0.1 sur la mini) ajoute un saut mais évite de publier des services—c’est la base recommandée.
3. Prévoyez 512 Kbit/s à 2 Mbit/s en montante sur le lien domicile pour du VNC interactif sur SSH ; sous 400 Kbit/s, attendez-vous à une latence de framebuffer inutilisable.

Runbook tunnel inverse en huit étapes

1. Créez un utilisateur d’automatisation dédié des deux côtés avec auth par clé uniqué—désactivez les invites mot de passe qui bloquent les reconnexions sans surveillance.
2. Réservez un écouteur distant tel que 127.0.0.1:19090 sur la mini pour le mappage inverse ; évitez les collisions avec le Partage d’écran local (5900).
3. Depuis le Mac domicile, lancez :

   ssh -N -T -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes \ -R 127.0.0.1:19090:127.0.0.1:5900 \ tunnel-user@your-mini-hostname

   Cela relie la loopback distante 19090 sur la mini au VNC local—ajustez le port interne si le Partage d’écoute ailleurs.
4. Vérifiez sur la mini : nc -vz 127.0.0.1 19090 pendant que le Partage d’écran est actif au domicile—attendez-vous à Connected en moins de 2 s.
5. Chemin visualiseur : tunnelisez une seconde session SSH avec -L 5901:127.0.0.1:19090 depuis votre portable vers la mini pour que l’app Partage d’écran macOS ne touche que localhost—pas de VNC grand ouvert sur le WAN.
6. Automatisez les redémarrages : enveloppez avec autossh ou un LaunchAgent qui exporte AUTOSSH_GATETIME=0 sur Wi‑Fi instable.
7. Corrélation des journaux : étiquetez les tunnels avec des codes région (HK, SG) dans votre collecte syslog pour que la finance relie les incidents aux SKU de nœud.
8. Exercice trimestriel : prouvez que vous pouvez reconstruire le tunnel depuis un cold boot en moins de 12 minutes—documentez le temps réel, pas un OKR théorique.

VNC, Partage d’écran et pourquoi la loopback compte

Le Partage d’écran macOS parle RFB sur TCP. Lier les forwards inverses à la loopback sur la mini garantit que les scanners Internet ne voient jamais de VNC en clair—même si SSH chiffre l’enveloppe, la défense en profondeur compte quand les mots de passe tournent lentement. Pour partager l’accès avec des partenaires, préférez des utilisateurs SSH temporaires avec ForceCommand plutôt qu’élargir les règles pare-feu.

AutoSSH, keepalives et survivre au Wi‑Fi hôtel

Les SSID hôtel recyclent les baux DHCP toutes les 40 à 120 minutes ; sans ServerAliveInterval, les canaux SSH de contrôle se figent alors que l’UI affiche encore « connecté ». Couplez les keepalives aux modèles de stabilité du guide AutoSSH/Mosh—les tunnels inverses héritent des mêmes cas d’écheil veille/réveil.

Paramètre	Valeur prudente	Quand resserrer
ServerAliveInterval	30 s	WAN retail avec idle agressif
ServerAliveCountMax	4	Compromis bascule rapide vs autonomie batterie
TCPKeepAlive	yes	Chemins rares où seuls les sondes noyau réveillent le NAT

Garde-fous sécurité à ne pas sauter

Faites tourner les clés d’automatisation tous les 90 jours, restreignez les IP sources SSH quand c’est possible, et ne publiez jamais GatewayPorts yes globalement sans ACL compensatoires.

Guides liés : SOCKS, SSH vs VNC, Wi‑Fi invité

Les tunnels inverses coexistent avec la sortie SOCKS, le choix SSH vs VNC et les repli Wi‑Fi invité. Chaque couche répond à un problème différent : le CGNAT répare la joignabilité, SOCKS façonne la sortie.

FAQ

Le SSH inverse remplace-t-il le port forwarding FAI ? Oui pour la joignabilité : vous initiez en sortant, le CGNAT cesse de bloquer votre flux.

Le VNC en clair est-il acceptable avec ce schéma ? Seulement si les connexions internes restent en loopback et que SSH porte les sauts risqués—n’exposez jamais du VNC brut sur 0.0.0.0.

Et le MTU ? Les grosses trames se figent encore—suivez le guide MTU avant d’accuser le code du tunnel.

Pourquoi une Mac mini ProxyMac reste pertinente une fois le CGNAT maîtrisé

Une Apple Silicon M4 dédiée à HK / JP / KR / SG / US vous donne des écouteurs IPv4 stables, un CPU prévisible pour les terminaux SSH et les outils macOS natifs pour les binômes QA qui refusent les clones VNC Linux. Le modèle de location ProxyMac permet d’aligner la zone d’atterrissage du tunnel sur la même géographie que vous facturez aux clients—capturez le couple dans Confluence à côté des tarifs, recyclez la mini après le pilote, et liez les articles d’aide depuis votre modèle de ticket SOC pour que l’astreinte suivante hérite des faits plutôt que du folklore.