Fast reverse proxy : comment j’expose un service derrière un NAT sans toucher au routeur

Sommaire

1. Qu’est-ce que FRP (Fast Reverse Proxy) ?
2. FRP vs ngrok : pourquoi j’ai choisi FRP
3. Architecture : comprendre frps et frpc
4. Installer le serveur FRP (frps) sur un VPS
5. Configurer le client FRP (frpc) derrière le NAT
6. Cas d’usage concrets en production
7. Sécuriser FRP : bonnes pratiques
8. Checklist de déploiement
9. FAQ

Introduction

Tu as un serveur ou un service derrière un NAT – pas d’IP publique, pas moyen d’ouvrir un port sur le routeur du client. Situation classique en infogérance Linux. FRP (Fast Reverse Proxy) résout ce problème proprement : un binaire côté serveur (frps) sur un VPS avec IP publique, un binaire côté client (frpc) derrière le NAT, et tu exposes SSH, HTTP ou n’importe quel service TCP/UDP en quelques minutes. C’est open source, léger, et bien plus flexible qu’un tunnel SSH classique. J’utilise FRP en production pour accéder à des machines clientes sans VPN, et j’ai packagé mes scripts d’installation dans un dépôt GitLab prêt à cloner. Voici comment le mettre en place.

Qu’est-ce que FRP (Fast Reverse Proxy) ?

FRP est un outil open source écrit en Go qui permet d’exposer des services locaux derrière un NAT ou un firewall vers Internet, via un serveur intermédiaire. Le projet compte plus de 85 000 étoiles sur GitHub – c’est l’un des outils de tunneling les plus utilisés au monde.

Concrètement, FRP fonctionne avec deux composants :

• frps (server) : tourne sur un VPS avec IP publique, reçoit les connexions entrantes
• frpc (client) : tourne sur la machine derrière le NAT, initie la connexion sortante vers frps

Le client établit un tunnel persistant vers le serveur. Quand quelqu’un se connecte au VPS sur un port exposé, le trafic est redirigé vers le service local via le tunnel. Pas besoin d’ouvrir de port sur le routeur, pas besoin de VPN.

FRP vs ngrok : pourquoi j’ai choisi FRP

Ngrok est populaire pour le développement local, mais en production, ses limites deviennent vite bloquantes : URLs aléatoires sur le plan gratuit, limites de connexions, dépendance à un service tiers. FRP est une alternative à ngrok auto-hébergée qui offre un contrôle total.

En hébergement VPS, j’utilise FRP quand j’ai besoin d’accéder à des machines clientes sans déployer un VPN complet. C’est plus léger, plus rapide à mettre en place, et le client n’a rien à configurer sur son routeur.

Architecture : comprendre frps et frpc

Voici comment FRP fonctionne dans un scénario typique :

┌──────────────┐         ┌──────────────────┐         ┌──────────────────┐
│  Utilisateur │────────▶│  VPS (frps)      │◀────────│  Machine NAT     │
│  (Internet)  │  port   │  IP publique     │  tunnel │  (frpc)          │
│              │  exposé │  203.0.113.10    │  sortant│  192.168.1.50    │
└──────────────┘         └──────────────────┘         └──────────────────┘
                          Port 7000 (contrôle)
                          Port 6000 → SSH local :22
                          Port 6080 → HTTP local :80

Le client frpc initie une connexion sortante (port 7000 par défaut) vers le serveur frps. Cette connexion reste ouverte et sert de tunnel. Quand un utilisateur se connecte au VPS sur le port 6000, le trafic est acheminé vers le port 22 de la machine derrière le NAT.

Installer le serveur FRP (frps) sur un VPS

J’ai créé un script d’installation automatique que j’utilise pour mes tests. Le code source est disponible sur mon dépôt GitLab.

Installation rapide avec mon script

git clone https://gitlab.com/babidi34/frp-tools.git
cd frp-tools
chmod +x setup_frp_server.sh
sudo ./setup_frp_server.sh

Le script fait tout automatiquement :

• Télécharge le binaire frps depuis les releases GitHub
• Génère un token d’authentification avec OpenSSL
• Configure la plage de ports autorisée (6000-6100 par défaut)
• Active le dashboard de monitoring
• Crée un service systemd pour le démarrage automatique

Configuration manuelle (frps.toml)

Si tu préfères configurer manuellement, voici un fichier de configuration type :

# /etc/frp/frps.toml
bindPort = 7000

# Authentification par token
auth.method = "token"
auth.token = "ton_token_securise_genere_par_openssl"

# Dashboard web
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "un_mot_de_passe_fort"

# Restriction des ports exposés
allowPorts = [
  { start = 6000, end = 6100 }
]

# Logs
log.to = "/var/log/frps.log"
log.level = "info"
log.maxDays = 7

Démarrer le service

sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps

Configurer le client FRP (frpc) derrière le NAT

Côté client, l’installation est tout aussi simple avec mon script :

git clone https://gitlab.com/babidi34/frp-tools.git
cd frp-tools
chmod +x setup_frp_client.sh
sudo ./setup_frp_client.sh

Le script te demande l’IP du serveur, le token, et les ports à exposer (SSH, HTTP, HTTPS).

Configuration manuelle (frpc.toml)

# /etc/frp/frpc.toml
serverAddr = "203.0.113.10"
serverPort = 7000

auth.method = "token"
auth.token = "ton_token_securise_genere_par_openssl"

# Tunnel SSH
[[proxies]]
name = "ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000

# Tunnel HTTP
[[proxies]]
name = "web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 80
remotePort = 6080

# Tunnel HTTPS
[[proxies]]
name = "web-ssl"
type = "tcp"
localIP = "127.0.0.1"
localPort = 443
remotePort = 6443

Tester la connexion

# Depuis n'importe quelle machine avec accès Internet
ssh -p 6000 user@203.0.113.10

# Le trafic arrive sur la machine derrière le NAT, port 22

Host machine-client
    HostName 203.0.113.10
    Port 6000
    User admin

Cas d’usage concrets en production

Sécuriser FRP : bonnes pratiques

FRP est puissant, mais mal configuré il peut devenir un vecteur d’attaque. Voici les mesures que j’applique systématiquement dans mes déploiements chez Linux-Man :

1. Token fort et unique

# Générer un token de 64 caractères
openssl rand -hex 32

2. Restreindre les ports autorisés

Dans frps.toml, limite la plage de ports que les clients peuvent utiliser :

allowPorts = [
  { start = 6000, end = 6100 }
]

3. Activer TLS

# frps.toml
transport.tls.force = true

# frpc.toml
transport.tls.enable = true

4. Firewall côté serveur

# UFW : n'ouvrir que les ports nécessaires
sudo ufw allow 7000/tcp    # Port de contrôle FRP
sudo ufw allow 6000:6100/tcp  # Plage de ports exposés
sudo ufw allow 7500/tcp    # Dashboard (restreindre par IP si possible)

5. Monitoring et logs

# Vérifier les connexions actives
curl -s http://admin:password@localhost:7500/api/proxy/tcp | jq

# Suivre les logs en temps réel
journalctl -u frps -f

Checklist de déploiement FRP

Erreurs fréquentes et solutions

Questions fréquentes