BungeeCord IP Forwarding permet à un backend de recevoir l'IP réelle du joueur, l'UUID en ligne et les informations de profil, bien que la connexion TCP provienne du proxy. Pour cela, quatre valeurs doivent correspondre – et le port backend doit être protégé contre les connexions directes.
ip_forward: truen'est pas un pare-feu. Le format BungeeCord classique ne possède pas de secret de signature spécifique au proxy. Quiconque atteint un backend non protégé en mode hors ligne peut falsifier les données de forwarding et se faire passer pour un autre joueur.
Les quatre valeurs
| Emplacement | Fichier/Champ | Valeur normale |
|---|---|---|
| BungeeCord | config.yml → online_mode |
true |
| BungeeCord | config.yml → ip_forward |
true |
| Backend | server.properties → online-mode |
false |
| Backend | spigot.yml → settings.bungeecord |
true |
Pour les versions récentes de Paper, s'ajoute :
# config/paper-global.yml
proxies:
bungee-cord:
online-mode: true
Cette valeur Paper correspond au mode en ligne du proxy. Elle reste true, bien que server.properties sur le backend utilise online-mode=false.
Pourquoi une sauvegarde doit précéder la modification
Sans forwarding, le backend en mode hors ligne génère un UUID à partir du nom du joueur. Avec un forwarding correct, il reçoit l'UUID issu de l'authentification en ligne. Ces valeurs ne sont pas identiques. L'inventaire, l'Enderchest, les rangs ou les données d'économie peuvent alors sembler avoir disparu, bien qu'ils soient enregistrés sous l'ancien UUID.
Avant la modification :
- sauvegarde les mondes,
playerdata, les bases de données de permissions et de plugins ; - teste une restauration ;
- documente l'UUID ancienne et attendue pour un joueur test ;
- vérifie les outils de migration spécifiques aux plugins ;
- ne modifie jamais aveuglément des noms de fichiers sans connaître les références et le format des données.
Le guide existant sur le changement de version décrit un chemin de sauvegarde, de copie et de retour en arrière adapté.
Étape 1 : configurer le proxy
Arrête BungeeCord proprement et modifie le config.yml actuel :
online_mode: true
ip_forward: true
Laisse l'authentification publique active sur le proxy. Vérifie en parallèle le listener, servers et priorities avec la référence des champs de config.yml.
Étape 2 : configurer le backend
Arrête complètement chaque backend et modifie :
# server.properties
online-mode=false
# spigot.yml
settings:
bungeecord: true
Sur Paper, tu définis en plus la valeur proxies.bungee-cord.online-mode indiquée. Redémarre d'abord les backends, puis BungeeCord. Un rechargement partiel ne suffit pas pour ce changement d'identité.
Étape 3 : fermer le chemin backend
Autorise le port TCP du backend uniquement depuis le chemin proxy vérifié. Selon ta propre infrastructure, il peut s'agir du loopback, d'un vrai réseau privé/VPN ou d'une règle de pare-feu stricte. Dans les environnements conteneurisés, une IP interne seule ne suffit pas : une instance étrangère sur le même bridge ne doit pas pouvoir passer pour le proxy.
Sur game-serverhosting, le guard actif lie les backends BungeeCord pris en charge à l'instance proxy concrète et résout à nouveau sa source de conteneur actuelle. Un arrêt, une source manquante ou ambiguë restent en drop-only. Les chemins same-node, cross-node et external-backend ont été vérifiés avec une vraie connexion proxy ; l'accès direct indépendant est resté bloqué. Il s'agit d'une affirmation concernant ces chemins prouvés, et non d'une garantie pour des réseaux de fournisseurs externes quelconques.
Le guide de configuration complet situe ces variantes réseau.
Situer correctement BungeeGuard
BungeeGuard complète le format hérité par un token partagé. Utilise au moins la version 1.4.0. La page de sécurité du projet documente une divulgation de token pour les anciennes configurations BungeeCord ; après une mise à niveau, un token potentiellement concerné doit être régénéré sur le proxy et les backends.
- génère le token localement avec une entropie suffisante ;
- ne le copie jamais dans des tickets, journaux, captures d'écran ou Git ;
- mets à jour le proxy et tous les backends de manière coordonnée ;
- supprime l'ancien token uniquement après un test réussi ;
- en cas de version inconnue/ancienne, traite l'état comme non vérifié.
BungeeGuard est particulièrement utile sur un hébergement partagé, mais ne remplace pas une solution de pare-feu/réseau privé disponible en tant que première couche de protection.
Vérification : quatre signaux distincts
- Processus : le proxy et le backend sont entièrement démarrés.
- TCP : le proxy atteint le listener du backend.
- Rejoindre le lobby : un vrai joueur authentifié accède au backend via le proxy.
- Identité : le backend voit l'UUID en ligne et l'IP client attendues, et non l'UUID hors ligne ou seulement l'IP du proxy.
Vient ensuite le test négatif : une source indépendante ne doit pas pouvoir atteindre le port du backend. Un listener ouvert ou un ping réussi seul ne constitue pas une preuve de connexion.
Erreurs courantes
| Symptôme | Cause | Prochaine étape |
|---|---|---|
| tous les joueurs ont l'IP du proxy | ip_forward ou bungeecord désactivé |
vérifier les deux côtés, redémarrer entièrement |
| le joueur a un nouvel inventaire | le mode UUID a changé | conserver la sauvegarde, comparer les UUID, migrer spécifiquement selon le plugin |
If you wish to use IP forwarding... |
le backend attend le forwarding, le proxy ne l'envoie pas | vérifier la valeur du proxy et la config réellement démarrée |
| connexion directe possible sous un nom étranger | backend accessible publiquement | corriger immédiatement le pare-feu/réseau privé |
| le proxy n'atteint pas non plus le backend | l'autorisation a une source incorrecte/obsolète | réévaluer l'association proxy concrète, ne pas ouvrir largement |
| aucune connexion après mise à jour BungeeGuard | token incohérent | vérifier les versions corrigées, régénérer de manière coordonnée |
En l'absence de cible de démarrage, le guide de dépannage du serveur de repli aide. Les domaines continuent de pointer vers le proxy ; utilise pour cela le guide domaine/SRV.
Plugins et Crossplay
Les plugins de permissions, de bannissement et d'économie sont particulièrement sensibles aux UUID. Sauvegarde leurs données et vérifie si un composant proxy et backend est nécessaire. Le guide des plugins explique la séparation des plateformes.
Dans un réseau proxy, Geyser n'est installé que sur le proxy. L'UDP Bedrock et le TCP Java restent des chemins séparés ; key.pem est secret. Configure Geyser/Floodgate uniquement une fois que le forwarding Java et le chemin négatif sont au vert.
FAQ
ip_forward: true est-il une protection ?
Non. Cela permet seulement de transmettre l'IP, l'UUID et le profil au backend. Le format classique ne possède pas de secret de signature spécifique au proxy : quiconque atteint directement un backend non protégé en mode hors ligne peut falsifier ces données. La protection réside dans la limite réseau, pas dans le paramètre.
Pourquoi le backend a-t-il online-mode=false ?
Parce que l'authentification auprès de Mojang a déjà lieu sur le proxy — sinon, le backend l'exigerait une seconde fois et rejetterait chaque joueur. Sur Paper, proxies.bungee-cord.online-mode reste néanmoins true : cette valeur reflète le mode en ligne du proxy, pas celui du backend.
Pourquoi les joueurs ont-ils un inventaire vide après le changement ?
Parce que l'UUID a changé. Sans forwarding, un backend en mode hors ligne génère l'UUID à partir du nom du joueur, tandis qu'avec le forwarding, c'est le véritable UUID en ligne qui arrive. Les anciennes données ne sont pas perdues, elles se trouvent sous l'ancien UUID — c'est pourquoi une sauvegarde testée doit précéder la modification.
Ai-je besoin de BungeeGuard ?
Il complète le format hérité par un token partagé et est surtout utile sur un hébergement partagé, où tu ne peux pas définir ta propre règle de pare-feu. Utilise au moins la version 1.4.0 et régénère le token après une mise à niveau. Il ne remplace pas une solution de pare-feu ou de réseau privé disponible.
Où Geyser doit-il être installé dans un réseau proxy ?
Uniquement sur le proxy, pas en plus sur les backends. Bedrock fonctionne via UDP, Java via TCP — les deux chemins sont vérifiés séparément, et key.pem est secret. Configure le Crossplay uniquement une fois que le forwarding et le test négatif du côté Java sont au vert.