Lecture : 14 minutes · Niveau : avancé · Mise à jour : avril 2026
Tutoriel pas-à-pas pour optimiser une connexion satellite (Starlink, OneWeb) en environnement PME : contourner le CGNAT pour exposer des services internes, déployer Cloudflare Tunnel et Tailscale, configurer QoS pour prioriser visio et VoIP, activer IPv6, mesurer et améliorer la latence applicative. Lab : votre kit Starlink installé selon Starlink Mini installation PME.
Pourquoi optimiser plutôt que se contenter du setup par défaut. Un kit Starlink fonctionne dès l’installation, mais le setup par défaut convient à un usage particulier basique. Pour une PME qui veut héberger des services internes, faire de la VoIP critique, et offrir des sessions de visio fluides à tous les employés simultanément, plusieurs ajustements sont nécessaires. Le CGNAT bloque l’hébergement par défaut, l’absence de QoS provoque des coupures vidéo quand quelqu’un upload une grosse archive, IPv6 désactivé prive la PME de routes plus directes vers Cloudflare et Google. Ce tutoriel guide ces optimisations qui transforment un Starlink « OK » en une connexion vraiment professionnelle.
Approche pragmatique recommandée. Toutes les optimisations de ce tutoriel ne sont pas nécessaires pour chaque PME. Une boutique avec 5 employés bureautique peut se contenter du Starlink stock. Une PME avec serveurs internes accessibles publiquement, équipe terrain en télétravail, et besoins voix/vidéo critiques bénéficie de toutes les optimisations. Mesurer d’abord les vrais besoins, puis appliquer progressivement les optimisations pertinentes — l’effort marginal de chaque section est faible mais cumulé peut surcharger inutilement.
Voir aussi → Internet par satellite pour PME : guide complet, Redondance multi-WAN satellite + fibre + 4G.
Sommaire
- Comprendre le CGNAT et ses implications
- Cloudflare Tunnel : exposer un service web
- Tailscale : VPN mesh zero-trust
- Headscale : alternative self-hosted
- Activer IPv6 (sortie native)
- Mesurer la latence applicative réelle
- QoS et priorisation des flux critiques
- Optimiser TCP pour satellite (BBR)
- Cache local DNS pour gain perçu
- Monitoring connexion 24/7
- FAQ
1. Comprendre le CGNAT et ses implications
CGNAT (Carrier-Grade NAT) = l’opérateur Starlink met votre connexion derrière un NAT à grande échelle. Vous ne recevez pas d’IP publique IPv4 dédiée.
Conséquences pratiques :
❌ Pas de port forwarding « classique » : impossible d’exposer un serveur web/SSH/MQTT public sur votre Starlink directement
❌ Certaines applications P2P (jeux, anciens VPN) ne fonctionnent pas
❌ DNS dynamique (DynDNS) inutile
✅ La navigation web sortante fonctionne normalement
✅ Les applications cloud (Office 365, Google Workspace, Slack) fonctionnent
✅ Le client VPN sortant (OpenVPN, WireGuard, Cisco AnyConnect) fonctionne
Solutions pour exposer un service depuis Starlink :
1. Cloudflare Tunnel (recommandé pour HTTP/HTTPS)
2. Tailscale (recommandé pour SSH, RDP, accès interne PME)
3. ngrok (rapide pour démo)
4. VPS reverse-proxy (contrôle total)
5. IP publique payante (plan Starlink Business avec option)
2. Cloudflare Tunnel : exposer un service web
Cloudflare Tunnel = tunnel sortant depuis votre serveur vers Cloudflare, qui expose le service publiquement avec votre domaine. Gratuit pour usage standard.
Pré-requis : domaine sur Cloudflare (gratuit aussi, transfert NS).
Installation cloudflared sur Raspberry Pi / serveur PME :
# Linux (Debian/Ubuntu/Raspbian)
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb
# Authentification
cloudflared tunnel login
# Ouvre URL dans navigateur, sélectionner domaine
Créer un tunnel :
cloudflared tunnel create pme-starlink
# Génère un UUID + fichier credentials JSON
cloudflared tunnel list
Configurer routes dans ~/.cloudflared/config.yml :
tunnel: <UUID>
credentials-file: /home/user/.cloudflared/<UUID>.json
ingress:
- hostname: portail.pme.com
service: http://localhost:8080
- hostname: nextcloud.pme.com
service: http://localhost:8081
- service: http_status:404
Pointer DNS sur Cloudflare :
cloudflared tunnel route dns pme-starlink portail.pme.com
cloudflared tunnel route dns pme-starlink nextcloud.pme.com
Lancer en service :
sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared
→ https://portail.pme.com est désormais accessible depuis n’importe où, malgré le CGNAT Starlink.
3. Tailscale : VPN mesh zero-trust
Tailscale crée un réseau privé chiffré entre vos appareils sans NAT traversal manuel. Idéal pour SSH, RDP, accès LAN PME.
Installation sur serveur PME (Raspberry Pi / VM) :
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# Ouvrir URL pour authentifier (Google, Microsoft, GitHub)
Activer subnet routing (accéder au LAN entier 192.168.1.0/24 via le serveur) :
sudo tailscale up --advertise-routes=192.168.1.0/24
Console Tailscale (admin.tailscale.com) : approuver la route subnet annoncée.
Sur les laptops/smartphones distants : installer Tailscale, login même compte. Tous les appareils peuvent se voir via IPs 100.x.y.z.
Test d’accès au LAN PME depuis l’extérieur :
ssh adminpme@192.168.1.20
# Fonctionne via le tunnel Tailscale, alors qu'on est en CGNAT
Tailscale Funnel (gratuit, exposer un service publiquement) :
sudo tailscale funnel 8080
# https://server-name.tailnet-name.ts.net → vers localhost:8080
4. Headscale : alternative self-hosted
Si on veut éviter le SaaS Tailscale, Headscale est l’alternative open-source compatible.
Setup Headscale sur VPS (avec IP publique) :
# Sur VPS Linux
sudo apt install -y headscale
sudo nano /etc/headscale/config.yaml
server_url: https://headscale.pme.com:443
listen_addr: 0.0.0.0:8080
db_type: sqlite3
db_path: /var/lib/headscale/db.sqlite
sudo systemctl enable --now headscale
headscale users create pme
headscale preauthkeys create -u pme --reusable -e 24h
Sur clients (Pi PME, laptops) : utiliser le client Tailscale officiel mais pointer vers Headscale :
sudo tailscale up --login-server=https://headscale.pme.com \
--authkey=tskey-pme-...
→ Réseau mesh complet sans dépendance à Tailscale.com.
5. Activer IPv6 (sortie native)
Starlink fournit nativement de l’IPv6 — souvent moins encombré que CGNAT IPv4 et avec IP publique unique côté IPv6.
Sur le routeur Starlink :
– App Starlink → Settings → Advanced → IPv6 : Enable
Sur le routeur dédié (pfSense/Mikrotik en bypass) :
– Activer DHCPv6 sur l’interface WAN
– Distribution prefix delegation aux clients LAN
– Vérifier ip a sur clients : adresse globale 2a0d… (Starlink range)
Test IPv6 :
curl -6 ifconfig.co
# 2a0d:b300:...
Avantages IPv6 :
– Pas de CGNAT pour les services accessibles en IPv6
– Latence parfois meilleure (route directe)
– Préparation futur (transitions opérateurs vers IPv6 only)
Limites :
– Tous les services Internet ne sont pas en IPv6 (mais le double-stack fonctionne)
– Côté entrant : Starlink ne donne pas d’adresse IPv6 publique fixe (varie)
6. Mesurer la latence applicative réelle
ping mesure ICMP. La latence applicative (TLS, DNS, HTTP) peut être différente.
Tests à faire :
# 1. Ping ICMP brut
ping -c 100 1.1.1.1
# 2. Latence DNS
dig @1.1.1.1 google.com | grep "Query time"
# 3. Latence TLS handshake + HTTP
curl -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | First byte: %{time_starttransfer}s | Total: %{time_total}s\n" \
-o /dev/null -s https://google.com
# 4. Test fluide (mtr - traceroute continu)
sudo apt install -y mtr-tiny
mtr -r -c 100 1.1.1.1
Sortie type :
HOST: pi Loss% Avg
1. 100.64.0.1 0.0% 15.2
2. starlink-gw 0.0% 18.4
3. cloudflare 0.0% 42.1
Interprétation :
– Loss > 1% : problème (obstruction, congestion)
– Avg > 100ms : configuration ou geographic
– Variabilité (jitter) > 20ms : congestion ou problème réseau
Outils continus :
– smokeping : graphique long terme latence
– Grafana + Prometheus : dashboard custom
7. QoS et priorisation des flux critiques
Si plusieurs activités saturent l’upload (visio + backup cloud), prioriser visio.
Sur Mikrotik (devant le routeur Starlink en bypass) :
/queue tree add name=video parent=global priority=1 max-limit=20M
/queue tree add name=voice parent=global priority=1 max-limit=2M
/queue tree add name=normal parent=global priority=4
/ip firewall mangle add chain=postrouting dst-port=443 protocol=udp \
action=mark-packet new-packet-mark=video
# Zoom utilise UDP 8801 - adapter selon visio cible
Sur OPNsense :
– System → Settings → Tunables → activer ALTQ
– Services → Traffic Shaper → Wizard → 1 LAN, 1 WAN, prioriser VoIP/Video
Sur Tailscale exit-node :
– N’inclure que le trafic critique dans Tailscale → reste passe direct sans bottleneck
Test impact QoS :
– Lancer iperf3 saturation upload
– En parallèle test Zoom call → doit rester fluide
8. Optimiser TCP pour satellite (BBR)
TCP BBR (Google, 2016) optimise le débit sur connexions à latence variable comme satellite.
Activer sur serveur Linux :
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# Vérifier
sudo sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr
Avantages BBR sur Starlink :
– Débit sustained meilleur (mesures publiques montrent +20-30% sur satellite)
– Récupération plus rapide après perte de paquet
Côté client Windows/Mac : modifications TCP plus complexes, généralement laisser par défaut. Les serveurs / Pi PME en bénéficient le plus.
9. Cache local DNS pour gain perçu
Chaque résolution DNS = aller-retour vers résolveur. Cache local = gain de latence.
Sur Pi PME : déployer Pi-hole (déjà vu dans Raspberry Pi serveur domestique) — Pi-hole cache les résolutions.
Alternative léger : dnsmasq :
sudo apt install -y dnsmasq
sudo nano /etc/dnsmasq.conf
cache-size=1000
no-resolv
server=1.1.1.1
server=9.9.9.9
sudo systemctl restart dnsmasq
Configurer le routeur PME pour distribuer ce DNS local.
Mesure impact :
# Avant : DNS distant
time dig +short google.com
# 0.8s
# Après : DNS cache local
time dig @192.168.1.20 +short google.com
# 0.02s
Bénéfice : chaque page web charge plus vite (multiples DNS lookups).
10. Monitoring connexion 24/7
Collecter métriques continues :
# uptime_monitor.py
import subprocess, time, json
from datetime import datetime
def ping_test(target="1.1.1.1"):
r = subprocess.run(["ping", "-c", "5", "-W", "2", target],
capture_output=True, text=True)
if r.returncode != 0:
return {"loss": 100, "avg": None}
# Parser sortie
last_line = r.stdout.strip().split("\n")[-1]
# rtt min/avg/max/mdev = 12.345/13.456/14.567/0.123 ms
parts = last_line.split("=")[1].split()[0].split("/")
return {"loss": 0, "avg": float(parts[1])}
while True:
result = ping_test()
result["ts"] = datetime.utcnow().isoformat()
with open("/var/log/starlink-uptime.jsonl", "a") as f:
f.write(json.dumps(result) + "\n")
time.sleep(60)
Dashboard Grafana : ingérer fichier JSONL via Telegraf → InfluxDB → graphique latence + uptime.
Alerting : si 5 ping consécutifs failed → email/WhatsApp via webhook Pushover, Gotify, ou n8n.
Service public : starlinkstatus.com affiche statut global Starlink — utile en cas de doute (panne globale vs locale).
FAQ
Cloudflare Tunnel est-il vraiment gratuit ?
Plan Free : tunnels illimités, jusqu’à 50 utilisateurs Zero Trust, gratuit pour usage perso/PME standard. Limites : pas de SLA, support communautaire. Plan Teams payant pour grosse organisation. Toujours vérifier les conditions actuelles sur cloudflare.com/products/zero-trust car la grille évolue.
Tailscale ou VPN classique (OpenVPN/WireGuard) ?
Tailscale plus simple à setup (zero-config NAT traversal), idéal PME. WireGuard pur si autonomie totale et expertise réseau. OpenVPN dépassé en 2026 pour cas standards.
Le CGNAT bloque-t-il les jeux en ligne ?
La majorité des jeux modernes fonctionnent (sortie initiée par le client). Quelques jeux P2P (anciens) ou hosting de serveurs propres ne fonctionnent pas. Cas spécifique : utiliser Tailscale pour héberger un serveur entre amis.
Starlink Business inclut-il l’IP publique ?
Sur certains plans Business avec option payante. Vérifier les conditions actuelles sur starlink.com → Business. Souvent : IP publique IPv4 = surcoût mensuel additionnel.
BBR fonctionne-t-il aussi côté client (Windows/Mac) ?
Limité. Linux et serveurs : oui via sysctl. Windows : Microsoft a sa propre congestion control adaptive. Mac : équivalent BBR partiellement disponible. Le bénéfice principal est sur le serveur qui sert le contenu.
Quel impact réel d’IPv6 sur la latence ?
Marginal mais positif. Souvent 5-15% latence plus basse vers services IPv6-natifs (Cloudflare, Google, Akamai) car routes plus directes. Pour services IPv4 only : aucun impact (fallback automatique).
Comment monitorer la consommation Starlink mensuelle ?
App Starlink → Statistics → Data Usage. Pour mesure indépendante : compter sur le routeur PME (Mikrotik queue stats, pfSense traffic graphs). Surveiller surtout pour Plans Mobile à quota.
Que faire si toute la connexion est saturée par un employé ?
Identifier via monitoring (qui consomme le plus). Solution : QoS par client/IP, limit de débit par IP, formation équipe. Pour cas extrêmes : VLAN séparé GUEST avec quota.
Articles liés (cluster Internet satellite)
- 👉 Internet par satellite pour PME : guide complet
- 👉 Starlink Mini installation pour PME : tutoriel
- 👉 Redondance multi-WAN : satellite + fibre + 4G
Voir aussi : Raspberry Pi serveur domestique, Sécurité IoT MQTT firmware.
Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.