Dans cet exemple, nous allons voir comment configurer le routage serveur à l'aide des utilisateurs de service dans le panneau Remnawave.

Routage serveur

Certains utilisateurs ont pu constater que Remnawave vide automatiquement le tableau clients de la configuration du serveur. Ce n'est ni une erreur ni un bug ; le panneau efface automatiquement ces tableaux car certaines fonctionnalités du panneau nécessitent de s'assurer qu'il n'y a rien de superflu dans ce tableau.

Imaginons que nous disposons de deux serveurs : RU-001 et DE-001.

Les utilisateurs se connecteront au serveur RU-001 ; nous allons effectuer le routage du trafic et, à titre d'exemple, envoyer les sites .ru directement et tout le reste vers le serveur DE-001.

Pour résoudre cette tâche, nous devons créer un utilisateur de service par lequel nous effectuerons le routage.

Création du profil pour DE-001

Rendez-vous dans la section Config Profiles et créez un nouveau profil, que nous appellerons Bridge Profile.

{
    "log": {
        "loglevel": "warning"
    },
    "dns": {},
    "inbounds": [
        {
            "tag": "BRIDGE_DE_IN",
            "port": 9999,
            "listen": "0.0.0.0",
            "protocol": "shadowsocks",
            "settings": {
                "clients": [],
                "network": "tcp,udp"
            },
            "sniffing": {
                "enabled": true,
                "destOverride": ["http", "tls", "quic"]
            }
        }
    ],
    "outbounds": [
        {
            "tag": "DIRECT",
            "protocol": "freedom"
        },
        {
            "tag": "BLOCK",
            "protocol": "blackhole"
        }
    ],
    "routing": {
        "rules": []
    }
}

Sauvegardez la configuration mise à jour.

Rendez-vous dans la section Internal Squad (pour créer un nouveau squad, cliquez sur le signe plus en haut à droite). Dans ce squad, activez uniquement l'inbound BRIDGE_DE_IN fraîchement créé depuis le profil Bridge Profile.

Veillez également à activer cet inbound et ce profil dans la fiche du nœud — dans notre cas, le nœud DE-001.

Création de l'utilisateur de service

Rendez-vous dans la section Users et créez un utilisateur nommé bridge_user_001. Assurez-vous que cet utilisateur n'a aucune limite de trafic, et fixez la date d'expiration de l'abonnement aux alentours de 2099. (Nous ne voulons pas que le panneau désactive l'utilisateur parce qu'il a atteint la limite de trafic ou que son abonnement a expiré.)

N'oubliez pas d'activer le squad pour cet utilisateur — dans notre cas, activons le squad créé ci-dessus.

Une fois l'utilisateur créé avec succès, ouvrez sa fiche et dans le menu (bouton More Actions) cliquez sur la section Detailed Info.

Dans cette section, faites défiler jusqu'en bas et, selon le type d'inbound que vous avez, copiez les informations.

Protocole	Libellé dans le panneau
Shadowsocks	SS Password
VLESS	VLESS UUID
Trojan	Trojan Password

Vous devriez ainsi disposer d'un mot de passe de connexion.

Configuration du profil public

Vous disposez très probablement déjà d'un tel profil, utilisé par vos utilisateurs pour se connecter. La section inbounds n'a pas besoin d'être modifiée ; ce qui nous intéresse, c'est la section outbounds et routing.rules.

{
    "log": { "loglevel": "none" },
    "inbounds": [
        {
            "tag": "PUBLIC_RU_INBOUND",
            "port": 443,
            "listen": "0.0.0.0",
            "protocol": "vless",
            "settings": { "clients": [], "decryption": "none" },
            "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
            "streamSettings": {
                "network": "raw",
                "security": "reality",
                "realitySettings": {
                    "target": "USE OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE OWN KEY!",
                    "serverNames": ["REPLACE WITH OWN VALUES!"]
                }
            }
        }
    ],
    "outbounds": [
        { "protocol": "freedom", "tag": "DIRECT" },
        { "protocol": "blackhole", "tag": "BLOCK" }
    ],
    "routing": {
        "rules": [
            { "ip": ["geoip:private"], "outboundTag": "BLOCK" },
            {
                "domain": ["geosite:private"],
                "outboundTag": "BLOCK"
            },
            { "protocol": ["bittorrent"], "outboundTag": "BLOCK" }
        ]
    }
}

Notre tâche initiale est donc : les utilisateurs se connectent au serveur RU-001 via le protocole VLESS, puis nous redirigeons le trafic par routage.

Outbound

Nous devons d'abord construire l'outbound.

{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "ADDRESS OF DE-001",
                "password": "PASSWORD FROM PREVIOUS STEP",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}

Valeur	Que saisir ?
address	IP ou nom de domaine pointant vers votre serveur, par exemple l'adresse IP du serveur `DE-001`
port	Port de l'inbound, dans notre cas le port de l'inbound `BRIDGE_DE_IN`
password	Mot de passe de l'utilisateur pour la connexion (les valeurs peuvent différer selon le protocole, voir ci-dessus)

Pour Shadowsocks — n'utilisez aucune autre méthode que chacha20-ietf-poly1305, car Remnawave ne supporte que cette méthode.

Routage

Exemple de règle qui envoie tout le trafic vers l'outbound indiqué ci-dessus.

{
    "inboundTag": ["PUBLIC_RU_INBOUND"],
    "outboundTag": "SS_OUTBOUND_TO_DE"
}

Exemple de règles qui envoient les sites RU directement (sortie directe depuis le nœud RU-001) et tout le reste vers DE-001.

      {
        "ip": [
          "geoip:ru"
        ],
        "outboundTag": "DIRECT"
      },
      {
        "domain": [
          "geosite:category-ru"
        ],
        "outboundTag": "DIRECT"
      }

Assemblons la configuration complète, qui ressemblera à ceci.

{
    "log": { "loglevel": "none" },
    "inbounds": [
        {
            "tag": "PUBLIC_RU_INBOUND",
            "port": 443,
            "listen": "0.0.0.0",
            "protocol": "vless",
            "settings": { "clients": [], "decryption": "none" },
            "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
            "streamSettings": {
                "network": "raw",
                "security": "reality",
                "realitySettings": {
                    "target": "USE OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE OWN KEY!",
                    "serverNames": ["REPLACE WITH OWN VALUES!"]
                }
            }
        }
    ],
    "outbounds": [
        { "protocol": "freedom", "tag": "DIRECT" },
        { "protocol": "blackhole", "tag": "BLOCK" },
        {
            "tag": "SS_OUTBOUND_TO_DE",
            "protocol": "shadowsocks",
            "settings": {
                "servers": [
                    {
                        "address": "ADDRESS OF DE-001",
                        "password": "PASSWORD FROM PREVIOUS STEP",
                        "port": 9999,
                        "level": 0,
                        "method": "chacha20-ietf-poly1305"
                    }
                ]
            }
        }
    ],
    "routing": {
        "rules": [
            { "ip": ["geoip:private"], "outboundTag": "BLOCK" },
            { "domain": ["geosite:private"], "outboundTag": "BLOCK" },
            { "protocol": ["bittorrent"], "outboundTag": "BLOCK" },
            { "ip": ["geoip:ru"], "outboundTag": "DIRECT" },
            { "domain": ["geosite:category-ru"], "outboundTag": "DIRECT" },
            {
                "inboundTag": ["PUBLIC_RU_INBOUND"],
                "outboundTag": "SS_OUTBOUND_TO_DE"
            }
        ]
    }
}

Nous avons ajouté notre outbound SS_OUTBOUND_TO_DE dans le tableau outbounds, et les règles dans le tableau rules de l'objet routing.

Les règles dans Xray fonctionnent par ordre de priorité. Nos règles peuvent être interprétées approximativement comme suit :

Si l'adresse IP appartient à geoip:private — BLOCK (envoyé à l'outbound BLOCK, qui est un blackhole et bloque la connexion).
Si le domaine appartient à la catégorie geosite:private — même traitement.
Idem pour le trafic bittorrent.
Si l'adresse IP appartient à geoip:ru — envoyé vers l'Outbound DIRECT, le trafic sort donc depuis notre serveur RU-001.
Si le domaine appartient à la catégorie geosite:category-ru — également envoyé vers DIRECT.
Si le trafic provient de l'inbound PUBLIC_RU_INBOUND — on l'envoie vers l'outbound SS_OUTBOUND_TO_DE (et il rejoint ensuite notre serveur DE-001).

Conclusion

Dans cet exemple, nous avons obtenu le schéma suivant :

L'utilisateur se connecte au serveur RU-001 à l'aide du protocole VLESS
Le trafic est soumis aux règles :
- Les sites (ou IP) russes — sortent directement (DIRECT)
- Tout le reste du trafic — est envoyé via le protocole shadowsocks vers l'autre serveur DE-001

Il est également possible d'utiliser VLESS comme protocole de transit ; la différence principale se situera uniquement dans notre outbound.

Création du profil pour DE-001​

Création de l'utilisateur de service​

Configuration du profil public​

Outbound​

Routage​