Aller au contenu principal

Routage côté serveur

Démonstration uniquement | Pas prêt pour la production

Ce guide est conçu uniquement comme une démonstration du routage côté serveur. Ne supposez pas que copier ces exemples produira une configuration entièrement fonctionnelle en production. Il ne couvre pas toutes les capacités de Xray-core et ne garantit pas un fonctionnement parfait dans tous les environnements.

Pour tous les détails sur la syntaxe de configuration et le comportement, consultez la documentation officielle Xray.

Certains utilisateurs ont peut-être remarqué que Remnawave efface automatiquement le tableau clients de la configuration du Node. Ce n'est pas un bug, mais un comportement intentionnel. Remnawave l'efface pour s'assurer que seules les configurations nécessaires sont conservées pour que certaines fonctionnalités fonctionnent correctement.

Dans ce guide, nous allons configurer le routage du trafic côté serveur en utilisant deux Nodes : RU et DE. Les utilisateurs se connecteront au Node RU. De là, le trafic sera acheminé comme suit :

  • Le trafic vers les sites web .ru sera acheminé directement via le Node RU.
  • Tout le reste du trafic sera acheminé via le Node DE.

Pour y parvenir, nous allons créer un utilisateur de service qui facilitera le routage du trafic.

Le « flux » du trafic pourrait ressembler à ceci :

  1. L'utilisateur ouvre google.com.
  2. La requête atteint d'abord le Node RU.
  3. Le Node RU applique les règles de routage. Comme google.com n'est pas un domaine .ru, le trafic est acheminé vers le Node DE.
  4. Le Node DE complète la connexion à google.com.

Ce type de configuration de routage côté serveur est souvent appelé « pont ».

Créer un profil de configuration pour DE​

Accédez à la section Profils de configuration et créez un nouveau profil de configuration, par exemple DE Bridge Profile.

DE 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": []
    }
}
N'oubliez pas d'attribuer le profil et de créer un Squad interne

Attribuez le profil de configuration nouvellement créé au Node DE. Sélectionnez l'Inbound BRIDGE_DE_IN.

Créez un nouveau Squad interne, appelons-le Bridge Squad. Activez l'Inbound que nous avons créé précédemment — BRIDGE_DE_IN.

Créer un utilisateur de service​

Pour que notre pont fonctionne, nous devrons créer un utilisateur. Appelons-le bridge_user.

N'oubliez pas de supprimer les limites de trafic et de prolonger la date d'expiration

Comme il s'agit d'un utilisateur de service, nous ne voulons évidemment pas que son abonnement expire ou soit limité par l'utilisation du trafic. Définissez Data Limit sur 0 et Expiry Date sur l'année 2099.

Ensuite, attribuez le Squad approprié à cet utilisateur. Dans notre cas, c'est Bridge Squad.

Une fois l'utilisateur de service créé, nous devrons obtenir son mot de passe. Ouvrez la fiche utilisateur, cliquez sur le bouton More Actions, puis sur Detailed Info. Vous devriez y voir la section Connection Information.

Selon le protocole de l'Inbound (Shadowsocks dans notre cas), copiez la valeur appropriée :

ProtocoleValeur des informations de connexion
TrojanMot de passe Trojan
VLESSUUID VLESS
ShadowsocksMot de passe SS

Configurer un profil public​

Vous avez probablement déjà un profil de configuration auquel vos utilisateurs se connectent. Sinon, consultez ce guide.

Pour cette étape, nous ne nous intéressons pas aux "inbounds" — nous allons plutôt modifier les tableaux "outbounds", "routing" et "rules" de ce profil.

Public Profile Example
{
    "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 YOUR OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE YOUR OWN KEY!",
                    "serverNames": ["USE YOUR 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"
            }
        ]
    }
}

Outbounds​

Nous devons d'abord modifier le tableau outbounds.

outbounds
{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "DE NODE ADDRESS",
                "password": "PASSWORD FROM PREVIOUS STEP",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}
ChampValeur
addressL'adresse IP ou le nom de domaine de votre serveur Node DE.
portLe port de l'Inbound, dans notre cas le port de BRIDGE_DE_IN.
passwordLe mot de passe de l'utilisateur de service. Dépend du protocole utilisé ; voir l'étape précédente.
methodMéthode de chiffrement. Pour Shadowsocks dans Remnawave, utilisez toujours chacha20-ietf-poly1305.

Routage et règles​

Ensuite, modifiez les règles de routage selon vos besoins.

Voici l'exemple d'une règle qui fait du Node RU un nœud de sortie pour les IPs et les sites russes, tandis que le reste du trafic est envoyé vers le Node DE.

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

Voici l'exemple d'une règle qui achemine tout le trafic vers l'Outbound SS_OUTBOUND_TO_DE.

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

Le profil de configuration public complet pourrait ressembler à ceci :

Complete Public Config Profile Example
{
    "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 YOUR OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE YOUR OWN KEY!",
                    "serverNames": ["USE YOUR OWN VALUES!"]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "DIRECT"
        },
        {
            "protocol": "blackhole",
            "tag": "BLOCK"
        },
        {
            "tag": "SS_OUTBOUND_TO_DE",
            "protocol": "shadowsocks",
            "settings": {
                "servers": [
                    {
                        "address": "DE NODE ADDRESS",
                        "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"
            }
        ]
    }
}
astuce

Les règles de routage Xray sont traitées dans l'ordre, de haut en bas.
Voici comment fonctionnent les règles de notre exemple :

  1. IPs privées (geoip:private) → BLOCK
    Le trafic correspondant à cette règle est envoyé vers l'Outbound BLOCK, qui est un protocole blackhole (complètement bloqué).

  2. Domaines privés (geosite:private) → BLOCK
    Identique à ce qui précède, mais pour les noms de domaine.

  3. Trafic BitTorrent (bittorrent) → BLOCK
    Tout le trafic BitTorrent est bloqué.

  4. IPs russes (geoip:ru) → DIRECT
    Le trafic correspondant à cette règle est envoyé vers l'Outbound DIRECT, qui est un protocole freedom (le Node RU agit en tant que nœud de sortie).

  5. Domaines russes (geosite:category-ru) → DIRECT
    Le trafic vers les domaines russes sort également directement depuis le Node RU.

  6. Aucune règle ne correspond (le reste du trafic) → SS_OUTBOUND_TO_DE
    Tout trafic restant arrivant au PUBLIC_RU_INBOUND est acheminé vers le Node DE via l'Outbound Shadowsocks créé précédemment.

Vous n'êtes pas obligé d'utiliser Shadowsocks comme protocole de transit — vous pouvez utiliser VLESS à la place. Assurez-vous simplement de mettre à jour votre configuration en conséquence.