Skip to content

Wiki fr ca

pjscruggs edited this page Nov 11, 2026 · 2 revisions

Raknetify2 · Français (Canada)

Langue

Partie multijoueur

Connexions réseau par RakNet pour les clients et les serveurs de Minecraft.

Télécharger · GitHub

Minecraft Raknetify2 Client / Serveur
Fabric mods/raknetify2-fabric-*.jar Client / Serveur
Forge mods/raknetify2-forge-*.jar Client / Serveur
NeoForge mods/raknetify2-neoforge-*.jar Client / Serveur
Spigot / Paper plugins/raknetify2-spigot-*.jar Serveur
Velocity plugins/raknetify2-velocity-*.jar Velocity
BungeeCord plugins/raknetify2-bungee-*.jar BungeeCord

Ajouter

  1. Partie multijoueur

  2. Ajouter

  3. Adresse du serveur

    Adresse du serveur
    RakNet · UDP raknet;play.example.com:25565
    TCP play.example.com:25565
  4. Terminé

  5. Rejoindre

F3 · Raknetify2

F3
RakNet · UDP Actif · MTU 1400
TCP Inactif

Velocity / BungeeCord

  1. Client · Raknetify2 → UDP → Velocity / BungeeCord · Raknetify2
  2. Velocity / BungeeCord → TCP → Serveur
Numéro de port · UDP Java
Fabric / Forge / NeoForge 1–65534 -Draknetify.fabric.portOverride=25570
Spigot / Paper ≥ 0.1.0-beta.1.431 1–65535 -Draknetify.spigot.portOverride=25570
Velocity 1–65534 -Draknetify.velocity.portOverride=25570
BungeeCord 1–65534 -Draknetify.bungee.portOverride=25570

Délai expiré

Adresse du serveur UDP
raknet;play.example.com:25580 play.example.com:25580 → NAT → 192.0.2.10:25570
Serveur · 192.0.2.10 25570/udp

config/raknetify2-compatibility.json

Serveur / Velocity / BungeeCord

JSON
① ② ③ {"mode":"ordered"}
① ∥ ② ∥ ③ {"mode":"multichannel"}

Simple Voice Chat

Serveur Raknetify2 · UDP 25565 Simple Voice Chat
Fabric / Forge / NeoForge config/raknetify2-voicechat.json · {"enabled":true} config/voicechat/voicechat-server.properties · port=-1
Spigot / Paper config/raknetify2-voicechat.json · {"enabled":true} plugins/voicechat/voicechat-server.properties · port=-1

Simple Voice Chat · Velocity / BungeeCord

PROXY protocol v2 · UDP

Adresse du serveur trustedProxies RakNet
192.0.2.10 · PROXY v2 / UDP ["192.0.2.10"] ✓
192.0.2.11 · PROXY v2 / UDP ["192.0.2.10"] ✗
Client → RakNet / UDP ["192.0.2.10"] ✗

config/raknetify2-proxy-protocol.json

{"trustedProxies":["192.0.2.10"]}

Minecraft ≥ 1.20.5 · /transfer

  1. Serveur A · Fabric / Forge / NeoForge · config/raknetify2-transfers.json

    {"destinations":[{"host":"play.example.com","tcpPort":25565,"udpPort":25570}]}
  2. Serveur B · play.example.com · server.properties → accepts-transfers=true

  3. Serveur A · /transfer play.example.com 25565 Alex → Client (Alex) → RakNet · play.example.com:25570

PacketOrdering

Minecraft
ui Options
entity Squelette
world_interaction Inventaire
effects Particules
chunk Blocs

PacketOrdering.java

Version incompatible!

Signaler un bug

Accueil

Raknetify2

Raknetify2 utilise RakNet sur UDP pour les parties multijoueurs de Minecraft. Il répartit les données entre plusieurs canaux, chacun avec son propre ordre de livraison. Si un paquet se perd, les autres canaux peuvent continuer à transmettre leurs données. Les interactions en jeu peuvent ainsi rester fluides pendant la retransmission des données manquantes ou le transfert de chunks.

Raknetify2 est un fork de Raknetify, créé par ishland. Il est maintenu séparément et prend en charge des versions plus récentes de Minecraft. Sa maintenance couvre le transport réseau, l’intégration aux différentes plateformes et les tests de compatibilité.

Premiers pas

  1. Vérifier la compatibilité de Minecraft et des mods.
  2. Choisir et installer la version à télécharger.
  3. Connectez-vous avec une adresse comme raknet;play.example.com.

Guides pour les serveurs

Les auteurs de mods peuvent utiliser l’interface d’ordonnancement des paquets pour déclarer les dépendances entre leurs messages personnalisés et le trafic de Minecraft.

Liens du projet

Raknetify2 est distribué sous licence MIT et conserve les mentions de droits d’auteur d’origine. Sa couche réseau s’appuie sur Raknetify et netty-raknet.

Installation

Téléchargez une version depuis la page des versions sur GitHub. Avant de l’installer, vérifiez la version de Minecraft et le chargeur de mods requis.

Type d’installation Fichier Dossier
Client ou serveur Fabric raknetify2-fabric-*.jar mods
Client ou serveur Forge raknetify2-forge-*.jar mods
Client ou serveur NeoForge raknetify2-neoforge-*.jar mods
Serveur Spigot ou Paper raknetify2-spigot-*.jar plugins
Serveur mandataire Velocity raknetify2-velocity-*.jar plugins
Serveur mandataire BungeeCord raknetify2-bungee-*.jar plugins

Fermez le client ou arrêtez le serveur avant de remplacer son fichier JAR. Retirez le JAR du Raknetify d’origine et tout ancien JAR de Raknetify2 de cette installation avant d’y ajouter le nouveau fichier.

Côté client, utilisez les dossiers de l’instance de Minecraft ou du modpack que vous lancez. Côté serveur ou serveur mandataire, utilisez les dossiers de l’installation correspondante. Si le chargeur n’a pas encore créé le dossier nécessaire, créez-le.

Connexion directe à un serveur

  1. Installez le mod client correspondant à votre chargeur de mods.
  2. Installez le mod serveur correspondant, ou le plugin Spigot/Paper si votre serveur le prend en charge.
  3. Suivez le guide de configuration du pare-feu et du routeur pour autoriser les connexions UDP au serveur.
  4. Redémarrez le client et le serveur.
  5. Choisissez « Ajouter » puis saisissez une adresse comme raknet;play.example.com ou raknet;play.example.com:25565.

Une adresse sans le préfixe raknet; utilise TCP.

Installer le mod sur votre client ne suffit pas à activer RakNet sur un serveur distant. L’administrateur du serveur doit y configurer un point d’accès RakNet. Pour rejoindre le serveur de quelqu’un d’autre, vous n’avez généralement aucune redirection de port entrant à configurer sur votre routeur.

Velocity et BungeeCord

Installez le plugin correspondant sur le serveur mandataire et le mod sur le client. Consultez le guide Velocity et BungeeCord pour configurer l’écoute du serveur mandataire, la transmission des informations de connexion aux serveurs de jeu, les restrictions d’accès et l’adresse à communiquer aux joueurs.

Utiliser un port d’écoute UDP distinct

Pour un serveur Minecraft auquel les joueurs se connectent directement, utilisez l’argument Java correspondant ci-dessous. Si vous administrez un serveur mandataire, consultez les paramètres d’écoute de Velocity et BungeeCord.

Plateforme Argument Java Ports acceptés
Serveur Fabric, Forge ou NeoForge -Draknetify.fabric.portOverride=25570 De 1 à 65534
Serveur Spigot ou Paper -Draknetify.spigot.portOverride=25570 De 1 à 65535

Forge et NeoForge utilisent le même code d’écoute que Fabric. Le nom de leur propriété contient donc aussi fabric. Remplacez 25570 par le port UDP voulu.

Spigot / Paper ≥ 0.1.0-beta.1.431

Ajoutez l’argument avant -jar dans la commande Java, ou dans le champ des arguments de la JVM chez votre hébergeur. Redémarrez le serveur et autorisez UDP sur le port choisi. Si le port public est également le 25570, connectez-vous avec raknet;play.example.com:25570. Si le routeur modifie le numéro de port, indiquez le port public dans l’adresse du serveur côté client. Le port TCP conserve sa valeur.

Sur Spigot/Paper, RakNet écoute en UDP sur la même adresse locale que le serveur Minecraft en TCP. Une valeur incorrecte ou un port UDP déjà occupé empêche le démarrage de RakNet. Le journal de démarrage indique l’adresse et le port d’écoute UDP. Pour réutiliser le numéro de port TCP, supprimez l’argument et redémarrez le serveur.

Un routeur ou un serveur mandataire UDP peut aussi exposer un autre port UDP public et le rediriger vers le port d’écoute existant, sans modifier les arguments Java du serveur.

Versions de développement

Dans GitHub Actions, ouvrez une exécution réussie de la branche main et téléchargez son archive sous Artifacts. GitHub exige un compte pour télécharger ces fichiers. Le tableau d’installation ci-dessus indique quel JAR choisir dans l’archive.

Velocity et BungeeCord

Velocity et BungeeCord servent d’intermédiaires entre les joueurs et les serveurs de jeu Minecraft. Installez Raknetify2 sur le serveur mandataire et sur chaque client qui utilisera RakNet.

Client Raknetify2 --UDP--> Velocity ou BungeeCord --TCP--> serveur de jeu

Pour ce type de connexion, les serveurs de jeu peuvent fonctionner sans Raknetify2. Ils doivent toutefois disposer des mods, des plugins et des mécanismes de transmission des informations de connexion requis par votre réseau. Raknetify2 ne convertit pas les protocoles entre versions de Minecraft et ne modifie pas la façon dont le serveur mandataire authentifie les comptes.

Installer le plugin sur le serveur mandataire

  1. Vérifiez que les connexions TCP ordinaires via votre serveur mandataire fonctionnent, y compris l’authentification et le passage d’un serveur de jeu à l’autre.
  2. Arrêtez le serveur mandataire et téléchargez le plugin correspondant sur la page des versions sur GitHub.
  3. Placez raknetify2-velocity-*-all.jar ou raknetify2-bungee-*-all.jar dans le dossier plugins du serveur mandataire. Retirez de ce dossier toute ancienne version du plugin Raknetify ou Raknetify2.
  4. Installez le mod Raknetify2 adapté à votre client en suivant le guide d’installation.
  5. Vérifiez les paramètres d’écoute ci-dessous, redémarrez le serveur mandataire et recherchez dans son journal d’éventuelles erreurs à l’ouverture du port RakNet.
  6. Autorisez le trafic UDP public vers le serveur mandataire et limitez l’accès aux ports de jeu des serveurs en suivant le guide de configuration du pare-feu et du routeur.

Utilisez des versions compatibles de Raknetify2 sur le client et le serveur mandataire. Consultez la page Compatibilité avant d’associer des versions différentes.

Velocity

Dans velocity.toml, le paramètre bind définit l’adresse et le port TCP sur lesquels Velocity écoute les connexions Minecraft. Raknetify2 utilise normalement le même numéro de port en UDP. Les entrées de la section [servers] désignent les serveurs de jeu. Laissez-y leurs adresses TCP. Consultez la documentation des paramètres de Velocity.

Pour utiliser un port UDP distinct, ajoutez cet argument de la JVM avant -jar dans la commande de démarrage de Velocity :

-Draknetify.velocity.portOverride=25570

Remplacez 25570 par le port de votre choix. Seul le port UDP de RakNet change. Velocity conserve son port TCP et les adresses des serveurs de jeu. Redémarrez Velocity après avoir modifié l’argument.

Configurez la transmission des informations des joueurs sur Velocity et sur chaque serveur de jeu. Si le logiciel du serveur de jeu le permet, utilisez le mode de transmission moderne et gardez sa clé secrète confidentielle. Les étapes propres à chaque logiciel figurent dans le guide de transmission des informations des joueurs de Velocity. Maintenez également les restrictions d’accès du pare-feu des serveurs de jeu.

BungeeCord

Dans le fichier config.yml de BungeeCord, la valeur host de chaque entrée de listeners définit l’adresse et le port TCP sur lesquels le serveur mandataire écoute les connexions Minecraft. Raknetify2 y ajoute normalement l’écoute en UDP sur le même numéro de port. La section servers contient les adresses TCP des serveurs de jeu. Ces paramètres sont décrits dans le guide de configuration de BungeeCord.

Pour utiliser un port UDP distinct, ajoutez cet argument de la JVM avant -jar dans la commande de démarrage de BungeeCord :

-Draknetify.bungee.portOverride=25570

Ce réglage s’applique à l’ensemble du processus du serveur mandataire. Si Minecraft écoute sur plusieurs adresses, vérifiez dans le journal de démarrage les adresses et ports réellement utilisés par RakNet avant d’ajouter des règles au pare-feu. Redémarrez BungeeCord après avoir modifié l’argument.

Conservez l’authentification des comptes sur le serveur mandataire. Pour les serveurs de jeu Spigot, le guide de transmission des adresses IP de BungeeCord associe ip_forward: true sur le serveur mandataire à settings.bungeecord: true sur le serveur de jeu. Ces réglages seuls n’empêchent pas les connexions directes au serveur de jeu. Limitez-en l’accès en suivant les instructions relatives au pare-feu.

Choisir l’adresse à communiquer aux joueurs

Sur les deux serveurs mandataires, le port de remplacement doit être compris entre 1 et 65534. Toute valeur incorrecte est ignorée. Vérifiez dans le journal de démarrage quel port UDP a été ouvert. Pour revenir au numéro de port de Minecraft, supprimez l’argument et redémarrez le serveur mandataire.

Les joueurs saisissent le nom d’hôte public du serveur mandataire et son port UDP, par exemple raknet;play.example.com:25570. Si un routeur modifie le numéro de port, indiquez son port UDP public dans l’adresse côté client. Une adresse sans le préfixe raknet; continue d’utiliser le port d’écoute TCP du serveur mandataire.

Attribuez des ports UDP distincts à Query, Geyser et aux autres services UDP. Changer le port TCP ne résout pas un conflit entre deux services UDP.

Simple Voice Chat et relais UDP supplémentaires

Sur Velocity et BungeeCord, Simple Voice Chat utilise son propre plugin de serveur mandataire et son propre port UDP. Consultez les instructions pour Simple Voice Chat derrière un serveur mandataire.

Si un relais UDP placé devant votre serveur mandataire Minecraft envoie des en-têtes PROXY protocol v2, configurez Raknetify2 en suivant le guide Redirection UDP et protocole PROXY. Velocity et BungeeCord seuls ne nécessitent pas cette configuration.

Vérifier la connexion

Faites un essai depuis l’extérieur de votre réseau local avec un client Raknetify2. Connectez-vous via le serveur mandataire, passez d’un de vos serveurs de jeu à l’autre et vérifiez que l’identité du joueur et ses permissions sont conservées.

  • Si la connexion TCP via le serveur mandataire fonctionne mais que RakNet expire sans réponse, vérifiez le port d’écoute UDP du serveur mandataire, le port public, les routes IPv4 et IPv6 et les règles du pare-feu.
  • Si les deux modes de transport échouent lorsque le serveur mandataire tente de joindre un serveur de jeu, vérifiez l’adresse TCP de ce serveur, ses règles d’accès et ses paramètres de transmission des informations des joueurs.
  • Si le serveur mandataire signale que le port UDP est occupé, vérifiez si Query, Geyser, un serveur mandataire vocal ou un autre processus l’utilise déjà.

Si vous signalez un problème, joignez les journaux du serveur mandataire et du serveur de jeu correspondant à la même tentative de connexion. Consultez la page Dépannage pour connaître les numéros de version à préciser.

Configuration du pare-feu et du routeur

Ce guide s’adresse aux administrateurs de serveurs. Pour utiliser Raknetify2, les paquets UDP doivent pouvoir atteindre le serveur ou le serveur mandataire qui accepte les connexions RakNet. Par défaut, il utilise le même numéro de port que Minecraft en TCP.

Si les joueurs sont sur le même réseau local, utilisez l’adresse locale du serveur et autorisez UDP dans le pare-feu de la machine qui l’héberge. Une redirection de port sur le routeur est nécessaire si le trafic provenant d’Internet doit traverser le NAT IPv4 de ce routeur.

Choisir la destination et le port

Connexion directe au serveur

Dirigez le trafic UDP public vers la machine qui héberge le serveur Minecraft équipé de Raknetify2. Le port de destination est le port d’écoute UDP de RakNet sur ce serveur. Autorisez ce port dans le pare-feu de la machine. Conservez la route TCP existante pour les connexions Minecraft ordinaires.

Par exemple, si Raknetify2 écoute sur le port UDP 25570, redirigez le port UDP public vers le port 25570 de l’adresse locale du serveur. Le port TCP du serveur peut rester à 25565. Pour choisir un autre port UDP, consultez les paramètres d’écoute d’un serveur direct.

Velocity ou BungeeCord

Dirigez le trafic UDP public vers la machine qui exécute Velocity ou BungeeCord avec le plugin Raknetify2. La destination de la redirection est le port d’écoute UDP de RakNet sur le serveur mandataire. Conservez la route TCP publique existante vers le serveur mandataire pour les connexions Minecraft ordinaires.

Le serveur mandataire se connecte aux serveurs de jeu Minecraft en TCP. Installer Raknetify2 sur le serveur mandataire ne nécessite pas d’ouvrir aux joueurs les ports de jeu UDP des serveurs situés derrière lui.

Connexion Accès à autoriser
Des joueurs vers le serveur mandataire Accès UDP public au port d’écoute de RakNet, en plus de l’accès TCP public existant
Du serveur mandataire vers les serveurs de jeu Ports TCP de Minecraft sur les serveurs de jeu, accessibles uniquement depuis les machines hébergeant les serveurs mandataires prévus
Des joueurs directement vers les ports des serveurs de jeu Maintenir cet accès bloqué, y compris en IPv6

Si le serveur mandataire et les serveurs de jeu tournent directement sur une machine dédiée que vous administrez, vous pouvez faire écouter les serveurs de jeu sur des adresses de bouclage et configurer le serveur mandataire pour les y joindre. S’ils tournent sur plusieurs machines, limitez l’accès TCP aux seuls serveurs mandataires au moyen d’un pare-feu ou d’un réseau privé isolé. Pour les conteneurs et les hébergements gérés, appliquez des restrictions équivalentes adaptées à votre réseau. Consultez le guide de sécurisation des serveurs de jeu de Velocity et le guide du pare-feu de BungeeCord.

La transmission des informations des joueurs et les restrictions du pare-feu se complètent. Une connexion directe à un serveur de jeu peut contourner les contrôles d’authentification du serveur mandataire. Pour installer le plugin, configurer la transmission des informations ou modifier le port UDP, consultez le guide Velocity et BungeeCord.

Ports publics et ports locaux

Si le routeur effectue une traduction de ports, le port public peut différer du port d’écoute :

Paramètre Port à utiliser
Adresse du serveur saisie dans le client Port UDP public
Port externe de la règle de redirection sur le routeur Port UDP public
Port interne de la règle de redirection sur le routeur Port d’écoute UDP de RakNet
Port local de la règle du pare-feu de la machine Port d’écoute UDP de RakNet

Redirection de port en IPv4

Pour héberger un serveur derrière un routeur IPv4 :

  1. Relevez l’adresse IPv4 locale de la machine qui accepte les connexions RakNet. Réservez cette adresse dans la configuration DHCP ou attribuez-lui une adresse statique appropriée pour que la règle de redirection continue de désigner la même machine.
  2. Ajoutez une règle de redirection UDP pour le port public que les joueurs utiliseront.
  3. Indiquez comme destination l’adresse locale de cette machine et le port d’écoute UDP de RakNet.
  4. Dans le pare-feu de la machine, autorisez le trafic UDP entrant sur le port d’écoute.

Par exemple, si le serveur écoute sur le port UDP 25565, la règle peut utiliser le port public 25565, l’adresse de destination 192.168.1.100 et le port de destination 25565. Remplacez l’adresse de l’exemple par l’adresse locale réelle de votre serveur.

Conservez la règle TCP existante pour les connexions Minecraft ordinaires. Une règle de redirection limitée à TCP ne transmet pas les paquets UDP.

Si la redirection échoue toujours

Vérifiez si un autre routeur ou votre fournisseur d’accès effectue une traduction d’adresses (NAT) en amont de votre routeur. Si vous administrez deux routeurs en série, configurez la redirection sur chacun d’eux. Si votre fournisseur utilise un NAT partagé entre abonnés (CGNAT), demandez-lui une adresse IPv4 publique, ou utilisez un hébergement ou un tunnel capable de recevoir du trafic UDP. Les règles de votre routeur ne permettent pas de configurer le NAT du fournisseur. Le guide de redirection de port de TP-Link explique pourquoi il faut une adresse publique côté WAN.

Règles du pare-feu IPv6

Autorisez le port UDP choisi dans le pare-feu IPv6 du routeur et dans celui de la machine. Utilisez comme destination l’adresse IPv6 de la machine qui accepte les connexions RakNet.

Vérifiez que le nom d’hôte renvoie bien à l’adresse IPv6 de cette machine. Si elle change, mettez à jour l’enregistrement DNS et les règles du pare-feu qui désignent cette adresse.

Lorsqu’un nom d’hôte publie des adresses IPv4 et IPv6, chacune doit permettre de joindre le serveur. Si certains joueurs arrivent à se connecter et d’autres non, vérifiez les règles des deux protocoles.

Si la redirection IPv4 modifie le numéro de port, vérifiez que le port saisi par les joueurs permet également de joindre le service en IPv6. La traduction de port IPv4 ne configure pas la route IPv6.

Hébergeurs et tunnels

L’hébergeur ou le fournisseur du tunnel doit prendre en charge UDP sur l’adresse et le port publics communiqués aux joueurs. Vérifiez les ports qu’il vous a attribués et les règles de son pare-feu réseau, ainsi que le pare-feu du serveur.

Si un autre serveur mandataire UDP transmet les adresses des clients au moyen de PROXY protocol v2, suivez le guide Redirection UDP et protocole PROXY et réservez l’accès au port d’écoute UDP de destination à ce serveur mandataire de confiance.

Vérifier la connexion

Depuis l’extérieur du réseau local du serveur, connectez-vous avec un client Raknetify2 à jour et une adresse comme raknet;play.example.com:25565. Indiquez dans cette adresse le port UDP public.

Vérifiez le trajet avec une véritable connexion RakNet. Une analyse UDP restée sans réponse peut donner un résultat indéterminé, car un service opérationnel peut ignorer une requête qu’il ne reconnaît pas. La documentation de Nmap sur l’analyse UDP explique ce comportement.

Une connexion TCP réussie confirme uniquement que le trajet TCP fonctionne. Si la connexion RakNet expire sans réponse, vérifiez le port d’écoute, la destination de la redirection, le port UDP et les règles du pare-feu en suivant le guide de dépannage.

Compatibilité

Vérifiez la compatibilité de la version que vous téléchargez. La branche de développement peut déjà prendre en charge des versions ou des configurations encore absentes des versions distribuées.

Versions de Minecraft et de Java

Versions de Minecraft et de Java · English

La version de Java indiquée par Raknetify2 est un minimum. Minecraft ou le chargeur de mods peut exiger une version plus récente. Choisissez une version de Java qui répond aux trois exigences.

Versions du client et du serveur

Dans la mesure du possible, utilisez la même version de Raknetify2 sur le client et sur le serveur ou le serveur mandataire auquel il se connecte. Avant d’associer des versions différentes, consultez les notes de version. Pour chiffrer la connexion RakNet, les deux extrémités doivent prendre en charge le protocole de chiffrement authentifié. Le Raknetify d’origine et les versions de Raknetify2 antérieures à ce protocole ne peuvent pas établir ce type de connexion chiffrée avec des installations à jour.

Raknetify2 transporte les données du protocole de jeu de Minecraft. Pour relier des versions différentes de Minecraft, il faut un dispositif de traduction de protocole compatible.

Autres mods

Autres mods · English

Si vous rencontrez un problème dans un modpack plus important, suivez le guide de dépannage. Indiquez dans votre signalement les versions exactes de tous les mods.

Mode ordonné

Mode ordonné

En temps normal, les canaux de Raknetify2 sont indépendants. Lorsqu’un canal attend des données manquantes, les autres continuent à transmettre leurs paquets. En mode ordonné, tous les paquets Minecraft passent par un seul canal. La perte d’un paquet bloque donc tous les paquets suivants dans le même sens jusqu’à sa retransmission. Ce mode préserve l’ordre attendu par certains logiciels antitriche, mais le trafic de jeu sans rapport avec le paquet perdu doit lui aussi attendre.

Activer le mode ordonné

  1. Installez une version de Raknetify2 prenant en charge le mode ordonné sur le serveur ou le serveur mandataire qui accepte les connexions RakNet ainsi que sur chaque client RakNet.

  2. Dans le répertoire de travail de ce serveur ou de ce serveur mandataire, créez le fichier config/raknetify2-compatibility.json. Si le dossier config n’existe pas, créez-le.

  3. Ajoutez le contenu suivant :

    {"mode": "ordered"}
  4. Redémarrez le serveur ou le serveur mandataire.

Les clients adoptent automatiquement le réglage du serveur. Les joueurs peuvent conserver leur adresse de serveur RakNet et n’ont aucun fichier de configuration à créer.

Dans chaque sens, tous les paquets Minecraft empruntent un même canal fiable et ordonné, y compris les délimiteurs de groupes de paquets et les paquets de changement de monde.

Configuration avec un serveur mandataire

Lorsque les joueurs se connectent par Velocity ou BungeeCord, configurez le mode ordonné sur le serveur mandataire, même si le logiciel antitriche fonctionne sur un serveur de jeu.

Le réglage reste en vigueur lorsqu’un joueur passe d’un serveur de jeu à l’autre. En mode ordonné, le serveur mandataire transmet les demandes de maintien de connexion du serveur de jeu au client du joueur au lieu d’y répondre lui-même.

Vérifier le réglage

Lors de la première connexion RakNet, la console affiche :

Raknetify2 compatibility: ordered (updated clients required, genuine acknowledgements)

Si les deux extrémités s’accordent sur ce mode, le journal affiche aussi ordered compatibility negotiated, suivi de l’adresse de l’autre extrémité.

Gardez les contrôles antitriche actifs et vérifiez le fonctionnement de votre propre installation.

Clients anciens

Un client RakNet qui ne prend pas en charge le mode ordonné ne peut pas rejoindre un serveur qui l’exige. Mettez Raknetify2 à jour sur ce client ou connectez-vous avec l’adresse et le port TCP habituels du serveur ou du serveur mandataire, sans le préfixe raknet;.

Revenir au mode multicanal

Remplacez le contenu du fichier par :

{"mode": "multichannel"}

Redémarrez ensuite le serveur ou le serveur mandataire. Vous pouvez également supprimer le fichier puis redémarrer pour rétablir le mode multicanal.

Problèmes de configuration

Le fichier doit contenir un seul paramètre nommé mode, dont la valeur doit être "ordered" ou "multichannel". Respectez les majuscules et les minuscules.

Si la configuration est incorrecte ou illisible, les connexions RakNet sont refusées. Corrigez le fichier et redémarrez le processus.

Si la console indique toujours multichannel, vérifiez que le fichier se trouve bien sous le répertoire de travail du serveur ou du serveur mandataire qui accepte la connexion RakNet, puis redémarrez ce processus.

Transferts automatiques

Les serveurs Fabric, Forge et NeoForge peuvent choisir RakNet lorsqu’ils transfèrent un client compatible vers une destination configurée. Ils utilisent pour cela les transferts intégrés à Minecraft depuis Java Edition 1.20.5. Vérifiez que votre version de Raknetify2 prend en charge la version de Minecraft et le chargeur de mods de chaque côté.

Installez Raknetify2 sur le serveur à l’origine du transfert et sur le client. Le serveur de destination doit disposer d’un port d’écoute RakNet compatible et accepter les demandes de transfert entrantes de Minecraft.

Cette configuration concerne les transferts envoyés par les trois chargeurs de mods ci-dessus. Les plugins Spigot/Paper, Velocity et BungeeCord ne lisent pas ce fichier de transferts.

Configurer le serveur à l’origine du transfert

Dans le répertoire du serveur à l’origine du transfert, créez le fichier config/raknetify2-transfers.json :

{
  "destinations": [
    {
      "host": "play.example.com",
      "tcpPort": 25565,
      "udpPort": 25570
    }
  ]
}

Remplacez le nom d’hôte et les ports de l’exemple par ceux de votre destination, puis redémarrez le serveur à l’origine du transfert. Ajoutez les autres destinations dans le même tableau.

Champ Signification
host Nom d’hôte ou adresse IP de destination, sans préfixe de transport ni port
tcpPort Port de destination dans la demande de transfert initiale
udpPort Port RakNet public auquel le client transféré doit se connecter

Les numéros des ports TCP et UDP peuvent être identiques. Si un routeur modifie le port UDP, indiquez le port public dans ce fichier. Écrivez les ports sous forme de nombres JSON.

Adressez les demandes de transfert au nom d’hôte et au port TCP habituels de la destination. Raknetify2 vérifie si le client annonce la prise en charge des transferts automatiques. Si c’est le cas et que la destination correspond à une entrée du fichier, il choisit le port UDP configuré. Pour les autres clients ou les destinations sans correspondance, la demande conserve son adresse initiale.

La recherche porte sur le nom d’hôte et le port TCP de la demande de transfert. Elle tient compte des écritures équivalentes d’une adresse IPv6 et ignore la casse du nom d’hôte ainsi que le point final du nom DNS. Aucune résolution DNS n’est effectuée. Deux noms d’hôte qui renvoient à la même adresse nécessitent donc deux entrées. Les caractères génériques ne sont pas pris en charge.

Configurer la destination

Si la destination utilise le fichier server.properties de Minecraft, indiquez-y accepts-transfers=true et redémarrez-la. Un serveur mandataire de destination peut disposer de son propre réglage de transfert. Par défaut, Minecraft refuse les transferts entrants même si les joueurs peuvent se connecter directement.

Le port d’écoute RakNet de la destination, la redirection UDP publique et le pare-feu de la machine doivent déjà être configurés. Le fichier de transferts du serveur d’origine sert à choisir l’adresse transmise au client.

Si le nom d’hôte publie les deux types d’adresse, vérifiez les trajets IPv4 et IPv6 jusqu’à la destination. Testez d’abord une connexion RakNet directe à cette destination avant de chercher la cause d’un problème de transfert automatique.

Maintenez les contrôles d’authentification et d’accès de la destination. La configuration des transferts n’accorde aucun droit d’accès aux joueurs et ne remplace pas l’authentification du serveur.

Erreurs de configuration et désactivation

Un champ manquant ou inconnu, un port incorrect ou une destination en double provoque une erreur de configuration au démarrage. Consultez le journal du serveur pour identifier l’erreur, corrigez le JSON, puis redémarrez.

Pour désactiver la sélection automatique, supprimez le fichier de configuration ou indiquez-y {"destinations": []}, puis redémarrez le serveur à l’origine des transferts. Ses demandes de transfert conserveront leurs adresses initiales.

Redirection UDP et protocole PROXY

Un serveur mandataire UDP peut relayer le trafic RakNet et conserver l’adresse d’origine du client grâce au protocole PROXY v2. Activez cette fonction lorsqu’un serveur mandataire UDP en amont envoie les en-têtes de ce protocole à votre port d’écoute. Une simple redirection de port sur un routeur ne la nécessite pas.

Sur le serveur ou le serveur mandataire Minecraft qui reçoit le trafic UDP redirigé, créez le fichier config/raknetify2-proxy-protocol.json :

{
  "trustedProxies": ["192.0.2.10"]
}

Remplacez l’exemple par l’adresse IP source réelle du serveur mandataire UDP ou par une plage d’adresses en notation CIDR que vous contrôlez. L’adresse doit correspondre à celle que voit le destinataire après toute traduction d’adresses intermédiaire. Saisissez directement une adresse IPv4 ou IPv6. Les noms d’hôte DNS sont refusés. Redémarrez le serveur ou le serveur mandataire de destination.

Configurez le serveur mandataire qui relaie les paquets pour qu’il envoie les en-têtes du protocole PROXY v2 en UDP. Raknetify2 n’accepte les adresses des clients transmises que si elles proviennent des sources indiquées. Lorsque cette configuration est activée, les connexions RakNet directes dépourvues de ces en-têtes sont refusées. La configuration de l’écoute TCP est conservée.

Serveurs mandataires de confiance et contrôle d’accès

Chaque serveur mandataire de la liste est autorisé à fournir les adresses des clients. Dans le pare-feu du serveur de destination, limitez l’accès au port UDP au seul serveur mandataire prévu. Indiquez les plages d’adresses de confiance les plus restreintes possibles pour votre réseau.

Le fichier doit contenir uniquement la propriété trustedProxies, avec au moins une entrée. Un tableau vide est une erreur. Un fichier incorrect empêche RakNet d’ouvrir son port d’écoute.

Pour rétablir les connexions UDP directes, supprimez le fichier et redémarrez le service d’écoute. Adaptez en même temps la configuration du serveur mandataire en amont et les règles du pare-feu au nouveau trajet.

Si les connexions échouent après l’activation, vérifiez l’adresse source réelle du serveur mandataire telle que la voit le serveur de destination, la plage d’adresses de confiance et l’envoi des en-têtes du protocole PROXY v2 pour UDP par le serveur mandataire.

Pour installer un serveur mandataire Minecraft et configurer ses serveurs de jeu, consultez Velocity et BungeeCord.

Simple Voice Chat

Sur Fabric, Forge, NeoForge, Spigot et Paper, Raknetify2 peut partager son port d’écoute UDP avec Simple Voice Chat sur le serveur.

Installez Simple Voice Chat sur le serveur et sur chaque client qui souhaite utiliser le chat vocal. Pour les autres réglages, suivez le guide de configuration du serveur de Simple Voice Chat.

Placez le fichier de Raknetify2 dans le dossier config situé à la racine du serveur, y compris sur Spigot/Paper. Le fichier propre à Simple Voice Chat reste à l’emplacement indiqué ci-dessous pour votre plateforme.

Partager le port de jeu

  1. Dans le répertoire du serveur, créez le fichier config/raknetify2-voicechat.json avec le contenu suivant :

    {"enabled": true}
  2. Dans la configuration serveur de Simple Voice Chat, indiquez port=-1. Sur un serveur moddé, le fichier se trouve dans config/voicechat/voicechat-server.properties. Sur Spigot/Paper, il se trouve dans plugins/voicechat/voicechat-server.properties.

  3. Laissez bind_address vide si une seule adresse d’écoute RakNet correspond. Si le serveur écoute sur plusieurs adresses pour ce même port UDP, indiquez l’adresse locale de celle que vous souhaitez partager.

  4. Redémarrez le serveur et exécutez /voicechat test <PLAYERNAME> pour un joueur connecté.

Si RakNet utilise un autre port que Minecraft, indiquez explicitement ce port UDP local dans le paramètre vocal port à la place de -1. Par exemple, si RakNet écoute sur le port UDP local 25570, indiquez port=25570.

Renseignez voice_host si les clients doivent utiliser une adresse ou un port public différent. Si votre routeur redirige le port UDP public 25580 vers le port UDP local 25570, indiquez port=25570 et voice_host=play.example.com:25580. L’adresse publique se règle dans voice_host. Le paramètre bind_address sélectionne l’adresse d’écoute locale.

Raknetify2 fournit le socket UDP partagé par l’intermédiaire de l’API de Simple Voice Chat. Simple Voice Chat se charge de l’authentification et du chiffrement des conversations vocales. Les joueurs peuvent utiliser le chat vocal que leur connexion de jeu passe par TCP ou par RakNet.

Autres services UDP et serveurs mandataires

Réservez des ports UDP distincts à Query et à Geyser. Le partage du socket est prévu uniquement pour Simple Voice Chat.

Le partage du socket ne s’applique pas au serveur mandataire vocal sur Velocity ou BungeeCord. Suivez le guide de configuration du serveur mandataire de Simple Voice Chat et attribuez au serveur mandataire vocal son propre port UDP. Avec le plugin de serveur mandataire vocal officiel, toute valeur publique de remplacement de voice_host doit être définie dans la configuration vocale du serveur mandataire. Ce plugin ignore les réglages voice_host des serveurs de jeu.

Pour un tunnel UDP générique, renseignez voice_host avec le nom d’hôte public et le port UDP qui renvoient vers ce serveur.

Désactiver le partage ou résoudre un conflit de sockets

Si le journal indique No RakNet listener matches the voice bind address and port, vérifiez que RakNet a démarré et que le port et l’adresse d’écoute du service vocal correspondent bien à ceux de RakNet sur la machine.

Si le journal indique Multiple RakNet listeners match the voice bind address, choisissez une des adresses locales correspondantes dans bind_address, puis redémarrez.

Un seul plugin Simple Voice Chat peut fournir le socket UDP utilisé par le service vocal. Si le journal de démarrage signale qu’un autre plugin fournit déjà le socket, choisissez l’intégration que vous souhaitez utiliser.

Pour désactiver le partage dans Raknetify2, indiquez {"enabled": false} dans son fichier de configuration vocale ou supprimez ce fichier. Attribuez un port UDP distinct à Simple Voice Chat, adaptez les règles de pare-feu ou de redirection, puis redémarrez le serveur.

Dépannage

La connexion TCP fonctionne, mais le délai expire avec RakNet

Vérifiez les points suivants dans l’ordre :

  1. Le client utilise le mod Raknetify2 adapté à son chargeur et à sa version de Minecraft.
  2. Raknetify2 est installé sur le serveur ou le serveur mandataire qui accepte la connexion et a démarré sans erreur d’ouverture du port d’écoute.
  3. L’adresse commence par raknet; et utilise le port UDP public.
  4. L’hébergeur, le routeur et le pare-feu de la machine autorisent tous UDP sur ce port.
  5. Les adresses IPv4 et IPv6 associées au nom d’hôte désignent la bonne machine et les règles du pare-feu permettent d’y accéder.

Une connexion TCP réussie confirme uniquement que le trajet TCP fonctionne. Suivez le guide de configuration du pare-feu et du routeur pour vérifier la redirection UDP et l’accès IPv6. Si le protocole PROXY est activé, les clients doivent passer par un serveur mandataire déclaré de confiance pour atteindre le port d’écoute.

Adresse déjà utilisée

Vérifiez si un autre processus utilise le port UDP. Query, Geyser et les autres services UDP doivent disposer de leurs propres ports. Simple Voice Chat peut utiliser le partage du port de jeu.

Vous pouvez choisir un autre port UDP local dans les paramètres d’écoute d’un serveur direct ou dans les paramètres de Velocity et BungeeCord. Vérifiez la version minimale requise pour ce réglage sur Spigot/Paper. Changer uniquement le port public du routeur ne résout pas le conflit de sockets sur la machine.

La connexion directe fonctionne, mais les transferts échouent

Connectez-vous directement à la destination avec son adresse préfixée par raknet;. Si cette connexion échoue, réglez d’abord le problème d’écoute ou de routage à destination.

Si les connexions directes fonctionnent, vérifiez que la destination accepte les transferts entrants. Un serveur Minecraft qui utilise server.properties doit y définir accepts-transfers=true. Une connexion directe ne permet pas de valider ce réglage.

Comparez ensuite le nom d’hôte et le port TCP de la demande de transfert aux valeurs du fichier config/raknetify2-transfers.json du serveur d’origine. Vérifiez que le fichier a été chargé après un redémarrage et que le client prend en charge les transferts RakNet automatiques. Consultez la page Transferts automatiques.

Erreurs de chiffrement ou de protocole

Vérifiez les versions de Raknetify2 aux deux extrémités de la connexion. Lorsqu’une version modifie le protocole chiffré, mettez à jour à la fois le client et le serveur ou le serveur mandataire. Conservez les paramètres d’authentification du serveur pendant le diagnostic.

Problèmes propres à un mod

Notez l’action qui déclenche le problème, par exemple ouvrir un inventaire, recevoir un pack de ressources, changer de monde ou faire apparaître une entité. Si possible, comparez le résultat de la même action en TCP et en RakNet sur une installation de test distincte.

Certains messages personnalisés dépendent de l’ordre des paquets de Minecraft. Les auteurs de mods peuvent déclarer ces dépendances à l’aide de l’interface d’ordonnancement des paquets.

Signaler un bug

Ouvrez un ticket dans l’outil de suivi des problèmes de Raknetify2 en indiquant les éléments suivants :

  • Versions de Minecraft, de Java, du chargeur de mods et de Raknetify2 aux deux extrémités.
  • Versions des logiciels des serveurs de jeu et des serveurs mandataires, y compris tout relais UDP.
  • Autres mods installés et leurs versions.
  • Étapes permettant de reproduire le problème et résultat attendu.
  • Résultat des mêmes étapes en TCP.
  • Extraits pertinents des journaux du client, du serveur et du serveur mandataire pour la même tentative.

Avant de publier vos journaux, retirez les jetons d’accès, les mots de passe et toute autre information privée. Conservez les messages d’exception et les traces de pile nécessaires au diagnostic.

Intégration avec d’autres mods

Avec Raknetify2, un mod peut préciser quelles données de Minecraft doivent rester ordonnées par rapport à ses messages personnalisés. Utilisez cette possibilité si le traitement d’un message nécessite une entité, un chunk, un inventaire ou un autre élément de l’état du jeu établi par des paquets antérieurs.

Groupes d’ordonnancement

Groupe Trafic associé
ui Menus et interactions indépendants du monde
entity Apparition, suppression et déplacement d’entités
world_interaction Inventaires et autres interactions dépendantes du monde
effects Sons et particules
chunk Mises à jour du terrain, des blocs et de l’éclairage

Chaque groupe conserve une livraison fiable et ordonnée sur son canal. L’ordre relatif des paquets de groupes différents peut changer à la réception. Choisissez le groupe en fonction des données dont votre message dépend.

Intégration facultative avec Fabric

Déclarez un fournisseur au point d’entrée raknetify:packet_channels du fichier fabric.mod.json de votre mod. Le fournisseur implémente Consumer<BiConsumer<String, String>> avec les types du JDK. Il reçoit une fonction d’enregistrement qui accepte l’identifiant d’un message personnalisé et un groupe d’ordonnancement.

Intégrez cette entrée dans vos métadonnées existantes en remplaçant le nom de classe par le nom complet de votre classe de fournisseur, paquet compris :

{
  "entrypoints": {
    "raknetify:packet_channels": [
      "com.example.mod.OrderingProvider"
    ]
  }
}

Conservez le reste de votre fichier fabric.mod.json, y compris les points d’entrée déjà définis. L’exemple illustre seulement la partie à intégrer.

Par exemple, une extension qui gère les déplacements des entités peut enregistrer example:entity_path dans le groupe entity. La documentation de l’API PacketOrdering présente l’implémentation du fournisseur.

En l’absence de Raknetify2, Fabric n’appelle pas ce point d’entrée. Les fournisseurs doivent déclarer les identifiants et les groupes pendant l’initialisation, sans présumer qu’un autre mod a déjà terminé la sienne.

Fonctionnement de l’enregistrement

Les mods Forge et NeoForge ainsi que les plugins de serveur ou de serveur mandataire peuvent appeler PacketOrdering.register(identifier, group) pendant leur initialisation si Raknetify2 est disponible. La classe est com.ishland.raknetify.api.PacketOrdering. Enregistrez vos déclarations avant d’accepter les connexions des joueurs. Si l’intégration est facultative, veillez à ce que votre code ne charge aucune classe de Raknetify2 en son absence.

Les déclarations s’appliquent aux nouvelles connexions. Les connexions existantes conservent les règles reçues à leur ouverture. Vous pouvez répéter une déclaration identique. Associer un même identifiant à deux groupes différents est refusé.

Les identifiants de messages doivent utiliser un espace de noms personnalisé valide. L’espace de noms minecraft est réservé. La limite est de 128 déclarations pour l’ensemble d’un point de connexion, y compris les règles intégrées et les déclarations d’autres mods. Un identifiant peut compter jusqu’à 255 caractères ASCII et doit respecter la syntaxe des identifiants avec espace de noms de l’API.

Les deux extrémités RakNet à jour échangent leurs déclarations à l’ouverture de la connexion. Si le serveur ou le serveur mandataire n’a aucune règle locale pour un message, il peut utiliser celle déclarée par l’autre extrémité. Les règles locales sont prioritaires et les déclarations reçues sont valables uniquement pour cette connexion.

Serveurs mandataires UDP

Consultez la page Redirection UDP et protocole PROXY pour les relais UDP et la transmission des adresses des clients.

Pour configurer un serveur mandataire Minecraft, consultez Velocity et BungeeCord.

English (US)

Clone this wiki locally