Avant de commencer
Préparez la liste des services, protocoles, adresses et ports, l’emplacement de l’origine et les routes de retour. Identifiez qui administre chaque équipement et qui peut autoriser l’annonce des adresses. Conservez les configurations actuelles et prévoyez une maintenance avec un accès de secours avant de modifier un tunnel ou un routage.
Le reverse proxy : un relais adapté au protocole
Un proxy reçoit des échanges et les relaie vers un service en aval. Un reverse proxy HTTP peut traiter les requêtes web, tandis qu’un relais TCP ou UDP répond à d’autres besoins. Les paramètres, états de connexion et limites sont propres au protocole et à l’implémentation. Un proxy HTTP ne transporte pas automatiquement tout le trafic d’un jeu.
Pour FiveM, distinguez les endpoints de connexion, les fichiers et le jeu. Vérifiez les adresses annoncées et les services restant directs. Faites préciser la conservation de l’adresse du client, les informations transmises à l’origine et les règles de confiance adaptées à votre version.
GRE : transporter du trafic dans un tunnel
GRE encapsule des paquets entre deux endpoints. Il peut servir à transporter du trafic déjà filtré vers une infrastructure distante, mais l’encapsulation ne filtre pas ce trafic par elle-même. GRE n’apporte pas non plus, à lui seul, le chiffrement ou l’authentification d’un VPN sécurisé.
Vérifiez que les équipements et réseaux autorisent GRE. En IPv4, GRE utilise un numéro de protocole IP, pas simplement un port TCP ou UDP à ouvrir. L’encapsulation ajoute des en-têtes : il faut adapter et tester la MTU effective, les routes et les retours. Une connexion qui fonctionne avec de petits paquets peut encore rencontrer un problème avec des paquets plus grands.
BGP : annoncer des routes avec une autorisation
BGP échange des informations de routage entre systèmes autonomes. Une architecture de protection peut s’en servir pour orienter du trafic vers un réseau de mitigation, puis vers la destination prévue. BGP ne remplace ni le filtrage ni la sécurité de l’application.
Il faut un accord de routage, des ressources autorisées et les prérequis du fournisseur. L’annonce d’un préfixe tiers exige une autorisation réelle. Les tailles de préfixe acceptées, les filtres et les procédures de validation varient selon les opérateurs. Ne supposez pas qu’une simple adresse de VPS donne le droit ou la possibilité d’annoncer un préfixe sur internet.
Documenter le trajet aller et retour
Dessinez le chemin d’un client jusqu’à l’application et celui de la réponse. Relevez les changements d’adresse, la terminaison des connexions et les éléments qui gardent un état. Une route de retour incohérente peut créer des échecs même lorsque le trajet aller paraît correct.
Identifiez aussi les chemins de contournement : anciennes adresses, DNS secondaires, fichiers, voix ou outils d’administration. Avant de restreindre l’origine, vérifiez les sources légitimes et les services nécessaires. Une protection distante ne dispense pas de contrôler l’exposition directe de la destination.
Valider avec de petits tests coordonnés
Testez le protocole réel avec une connexion normale, puis les fichiers et fonctions essentielles. Contrôlez les journaux, les routes et les erreurs de fragmentation ou de délai si elles apparaissent. Une page web disponible ne valide pas un tunnel de jeu ; un tunnel actif ne prouve pas qu’une application écoute.
Faites les changements un par un, avec une configuration de retour arrière. Toute charge de test doit être coordonnée et limitée. Ne modifiez pas simultanément DNS, proxy, tunnel et pare-feu : vous perdriez la possibilité d’identifier la cause d’un échec.
Choisir selon les ressources que vous contrôlez
Pour une application HTTP, commencez par étudier le proxy et les restrictions de l’origine. Pour un jeu TCP ou UDP, faites préciser le relais ou le tunnel compatible. Pour une infrastructure possédant des préfixes autorisés et des compétences réseau, étudiez un routage BGP documenté.
Comparez les responsabilités, la disponibilité réelle, les limites de trafic et le tarif du périmètre choisi. Une architecture combinant plusieurs mécanismes peut être pertinente, mais chaque couche ajoute des réglages et des points à surveiller. Gardez une description simple que votre équipe et votre fournisseur peuvent vérifier ensemble.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Application web | Étudier un proxy HTTP avec les paramètres de confiance et l’accès à l’origine adaptés à l’application. |
| Trafic de jeu distant | Confirmer les besoins TCP/UDP, le tunnel ou le relais, la MTU et le trajet de retour. |
| Préfixes réseau autorisés | Étudier BGP avec le fournisseur, les autorisations d’annonce, les filtres et une procédure de bascule. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.