Sur cette page
À retenir
- Deux problèmes, des contrôles différentsUne liaison saturée et des connexions applicatives répétées nécessitent des observations et des protections différentes.
- Un proxy exige un backend protégéChanger l’adresse publique n’empêche pas l’accès direct à une origine qui reste exposée.
- Valider un parcours joueur completVérifiez l’authentification, le lobby, les changements de serveur et le jeu, pas seulement la réponse dans la liste des serveurs.
Identifier l’édition, le point d’entrée et le parcours réel
Dessinez le chemin utilisé par le joueur : nom public et port, éventuel point de protection, proxy de jeu, lobby et backends. Ajoutez le service de packs de ressources ou le panel s’ils partagent la machine ou le réseau. Notez le responsable de chaque composant. L’IP affichée dans un panel d’hébergement ne suffit pas à évaluer une protection.
Minecraft Java utilise normalement TCP pour le jeu ; Bedrock emploie un autre transport. Un port personnalisé, une passerelle entre éditions ou un service Query facultatif ajoutent leurs exigences. L’offre Java décrite par Peeryx n’inclut pas automatiquement Bedrock ni toutes les passerelles. Soumettez la topologie, les versions et les protocoles réels à une vérification de compatibilité.
Distinguer les floods réseau des bots et des connexions abusives
Un flood réseau peut épuiser la liaison ou le traitement des paquets avant que le logiciel de jeu puisse décider quoi que ce soit. Des tentatives répétées de connexion, de statut ou d’authentification peuvent plutôt consommer les ressources du proxy, du login ou du backend. Ces phénomènes peuvent coexister, mais un seul graphique de bande passante ne permet pas de les départager.
Comparez octets et paquets réseau, compteurs de connexions, journaux du proxy et état applicatif sur le même intervalle. Notez si le problème touche les nouveaux joueurs, les sessions déjà établies ou un seul backend. Un nombre de bots n’est pas une mesure de bande passante ; un faible débit ne prouve pas que le chemin dispose d’assez de capacité de traitement.
Un contrôle anti-bot applicatif ne récupère pas les paquets déjà perdus en amont. Inversement, réduire le volume en amont ne remplace pas la compatibilité des versions, l’authentification ou les contrôles d’admission du jeu. Choisissez la couche qui peut soulager le point limitant observé et testez les joueurs légitimes après chaque changement de politique.
Limiter l’accès direct aux backends avant de compter sur le proxy
Une nouvelle adresse de proxy publique ne rend pas l’ancienne adresse du backend inaccessible. Vérifiez l’exposition IPv4 et IPv6, les ports supplémentaires et les restrictions de l’hébergement mutualisé. Le chemin autorisé du proxy au backend doit être explicite ; le port public du jeu et l’administration sont des services distincts avec des responsables différents.
Limitez l’accès aux backends aux chemins nécessaires des proxies. La transmission de l’identité est un contrôle de confiance distinct, qui ne remplace pas les restrictions réseau. PaperMC et SpigotMC documentent tous deux l’isolation des backends derrière un proxy.
Préparez un relevé des sources de proxy autorisées, des destinations et ports des backends, du responsable des règles et du moyen de récupérer l’administration. Vérifiez le trafic autorisé et le refus d’un accès direct depuis un point de test externe autorisé. Ne remplacez pas le pare-feu existant par une commande générique copiée dans un article.
Vérifier séparément la transmission d’identité Velocity et BungeeCord
Le mode modern de Velocity exige des serveurs compatibles et une configuration de transmission cohérente. Le mode legacy compatible BungeeCord utilise un autre format. Choisissez le mécanisme pris en charge par vos versions ; les noms de modes ne sont pas interchangeables.
Rendez la chaîne de confiance visible dans le dossier de livraison : quel composant authentifie le joueur, lequel transmet son identité et quel backend l’accepte. Examinez les plugins utilisant l’adresse, l’UUID ou les permissions du joueur. Une connexion qui atteint le backend mais échoue à un contrôle d’identité ne prouve pas un blocage par l’Anti-DDoS.
Suivez la documentation actuelle du projet de proxy et protégez les secrets de transmission. Ne désactivez pas l’authentification des joueurs sur l’entrée publique pour faire réussir un test. La vérification Peeryx porte sur la livraison proposée ; ce guide ne promet pas la compatibilité avec toutes les chaînes de proxies.
Choisir la protection selon les adresses et le routage maîtrisés
Un point d’entrée Minecraft Java unique et un réseau d’hébergement annonçant de nombreux préfixes n’ont pas le même périmètre. Un service dédié au jeu s’étudie selon son origine et ses connexions. Le Transit IP protégé est un service réseau avec ses propres conditions d’adressage, de routage et de livraison. L’option gaming d’un transit et une offre de livraison de jeu sont deux achats distincts.
Si vous exploitez du matériel de filtrage compatible, des contrôles locaux peuvent former une couche supplémentaire. Ils nécessitent toujours de la capacité de transport en amont et un chemin réseau défini. Ne comptez pas une licence logicielle, une vitesse de port ou la capacité mutualisée d’un fournisseur comme une capacité réservée à un serveur de jeu.
Déplacer le point d’entrée avec un plan réversible
Relevez le nom public, l’adresse, le port d’écoute et le routage actuels. Déterminez si la livraison modifie le DNS, la destination d’un proxy ou la route réseau. Vérifiez les caches des clients et la façon de retirer l’ancien point d’entrée. Réduire le TTL DNS ne prouve pas que tous les joueurs ont déjà actualisé leur réponse.
Convenez de la fenêtre de validation, des observations et du responsable du retour arrière. Gardez une méthode approuvée pour restaurer le service précédent pendant les essais. Des proxies supplémentaires peuvent modifier la visibilité des sources, la latence et les dépendances de panne ; comparez des mesures depuis les réseaux des joueurs plutôt que promettre une amélioration universelle de latence.
Tester tout le parcours joueur
Utilisez des clients normaux depuis des réseaux externes représentatifs. Établissez une référence fonctionnelle, puis répétez la même séquence après la modification prévue. Testez les nouvelles connexions séparément des sessions existantes et notez heure, version, destination et résultat. Un ping ou une réponse dans la liste des serveurs reste une observation partielle.
| Étape | Preuve à relever | Ce qu’elle ne prouve pas |
|---|---|---|
| Nom et destination | Adresse et port utilisés par le client de test | Que le proxy atteint le bon backend |
| Connexion et authentification | Un nouveau joueur termine l’authentification | Que tous les backends ou toutes les versions fonctionnent |
| Lobby et changement de serveur | Le joueur rejoint chaque backend prévu | Que les autres backends ont la même politique |
| Jeu normal | Les actions restent utilisables avec une charge représentative | Un benchmark indépendant de capacité face aux attaques |
| Rétablissement convenu | Le parcours fonctionne après le changement de chemin choisi | La résistance à des pannes non testées de routeur, d’alimentation ou d’upstream |
Questions sur la protection Minecraft et les proxies
Masquer l’IP du backend suffit-il ?
Non. Les noms et adresses publiés peuvent changer alors que l’origine reste accessible directement. Vérifiez les restrictions d’accès et le chemin prévu par le proxy ; la discrétion n’est pas une politique de contrôle d’accès.
L’anti-bot remplace-t-il la protection DDoS réseau ?
Non. Ils répondent à des limites de ressources différentes. Identifiez où commencent les pertes ou l’épuisement du traitement, puis combinez les contrôles adaptés sans supposer qu’un seul couvre toutes les couches.
Qu’envoyer pour une vérification de compatibilité ?
L’édition et les versions, l’hébergeur, le point d’entrée public, la disposition du proxy et des backends, les protocoles, la charge habituelle et le symptôme exact. N’envoyez ni clé privée, ni mot de passe, ni secret de transmission.
