In diesem Beispiel betrachten wir, wie man das Server-Routing mithilfe von Dienstbenutzern im Remnawave-Panel konfigurieren kann.

Server-Routing

Einige Benutzer sind möglicherweise auf das Problem gestoßen, dass Remnawave das clients-Array automatisch aus der Serverkonfiguration löscht. Dies ist kein Fehler oder Bug — das Panel löscht diese Arrays automatisch, da das Panel für die korrekte Funktion bestimmter Funktionen sicherstellen muss, dass dieses Array nichts Überflüssiges enthält.

Stellen wir uns vor, wir haben zwei Server. Wir nennen sie: RU-001, DE-001.

Benutzer werden sich mit dem Server RU-001 verbinden, wir werden Traffic-Routing durchführen, und als Beispiel — .ru-Websites direkt senden und alles andere zum Server DE-001.

Zur Lösung dieser Aufgabe müssen wir einen Dienstbenutzer erstellen, über den wir das Routing durchführen werden.

Erstellen eines Profils für DE-001

Gehen Sie zum Abschnitt Config Profiles und erstellen Sie ein neues Profil, wir nennen es 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": []
    }
}

Speichern Sie die aktualisierte Konfiguration.

Gehen Sie zum Abschnitt Internal Squad (Um einen neuen Squad zu erstellen, klicken Sie auf das Plus-Symbol in der oberen rechten Ecke). Aktivieren Sie in diesem Squad nur den neu erstellten Inbound BRIDGE_DE_IN aus dem Bridge Profile.

Stellen Sie außerdem sicher, dass dieser Inbound und das Profil in der Node-Karte aktiviert sind. In unserem Fall — für den Node DE-001.

Erstellen eines Dienstbenutzers

Gehen Sie zum Abschnitt Users und erstellen Sie einen Benutzer mit dem Namen bridge_user_001. Stellen Sie sicher, dass für diesen Benutzer keine Traffic-Limits gesetzt sind, und setzen Sie das Ablaufdatum des Abonnements auf irgendwo um das Jahr 2099. (Schließlich möchten wir nicht, dass das Panel den Benutzer deaktiviert, weil er das Traffic-Limit erreicht hat oder weil sein Abonnement abgelaufen ist?)

Vergessen Sie nicht, einen Squad für diesen Benutzer zu aktivieren. In unserem Fall — aktivieren Sie den oben erstellten Squad für diesen Benutzer.

Nachdem der Benutzer erfolgreich erstellt wurde, öffnen Sie seine Karte und klicken Sie im Menü (Schaltfläche More Actions) auf den Abschnitt Detailed Info.

Scrollen Sie in diesem Abschnitt ganz nach unten und kopieren Sie die relevanten Informationen je nach Typ Ihres Inbounds.

Protokoll	Bezeichnung im Panel
Shadowsocks	SS Password
VLESS	VLESS UUID
Trojan	Trojan Password

Insgesamt sollten wir das Verbindungspasswort zur Hand haben.

Konfigurieren des öffentlichen Profils

Höchstwahrscheinlich haben Sie bereits ein solches Profil, über das sich Benutzer verbinden. Der inbounds-Abschnitt muss nicht angetastet werden — uns interessieren der outbounds-Abschnitt und 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" }
        ]
    }
}

Die ursprüngliche Aufgabe lautet also — Benutzer verbinden sich über das VLESS-Protokoll mit dem Server RU-001, und dann leiten wir den Traffic durch Routing weiter.

Outbound

Zunächst müssen wir den outbound zusammenstellen.

{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "ADDRESS OF DE-001",
                "password": "ПАРОЛЬ С ПРОШЛОГО ШАГА",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}

Wert	Was eingeben?
address	IP oder Domainname, der auf Ihren Server zeigt, z. B. die IP-Adresse des Servers `DE-001`
port	Der Inbound-Port, in unserem Fall der Port des Inbounds `BRIDGE_DE_IN`
password	Das Verbindungspasswort des Benutzers (je nach Protokoll können verschiedene Werte gelten — siehe oben)

Für Shadowsocks — verwenden Sie keine anderen Methoden als chacha20-ietf-poly1305, da Remnawave nur diese Methode unterstützt.

Routing

Ein Beispielregel, die den gesamten Traffic in den oben angegebenen Outbound leitet.

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

Beispielregeln, die RU-Websites direkt senden (direkt aus dem Node RU-001, und alles andere zu DE-001)

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

Wir stellen die vollständige Konfiguration zusammen, sie wird so aussehen.

{
    "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": "ПАРОЛЬ С ПРОШЛОГО ШАГА",
                        "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"
            }
        ]
    }
}

Entsprechend haben wir unseren Outbound SS_OUTBOUND_TO_DE zum outbounds-Array hinzugefügt und die Regeln zum Array im rules-Objekt (das sich im routing-Objekt befindet).

Regeln in Xray funktionieren nach dem Prioritätsprinzip. Unsere Regeln können ungefähr so interpretiert werden:

Wenn die IP-Adresse zu geoip:private gehört — BLOCK (wird an den BLOCK-outbound gesendet, der selbst ein blackhole ist (wird blockiert)).
Wenn die Domain zur Kategorie geosite:private gehört — gleiche Aktion.
Dasselbe gilt für bittorrent-Traffic.
Wenn die IP-Adresse zu geoip:ru gehört — senden an den DIRECT-Outbound, sodass der Traffic von unserem RU-001-Server ausgeht.
Wenn die Domain zur Kategorie geosite:category-ru gehört — ebenfalls an DIRECT senden.
Wenn Traffic vom Inbound PUBLIC_RU_INBOUND kommt — senden wir ihn an den Outbound SS_OUTBOUND_TO_DE (von dort geht er zu unserem Server DE-001).

Fazit

In diesem Beispiel haben wir folgendes Schema erhalten:

Der Benutzer verbindet sich über das VLESS-Protokoll mit dem Server RU-001
Traffic unterliegt den Regeln:
- RU-Websites (oder IPs) — gehen direkt zum Ausgang (DIRECT)
- Gesamter restlicher Traffic — wird über das shadowsocks-Protokoll an einen anderen Server gesendet — DE-001

VLESS kann ebenfalls als Transit-Protokoll verwendet werden — der Hauptunterschied liegt in der outbound-Konfiguration.

Erstellen eines Profils für DE-001​

Erstellen eines Dienstbenutzers​

Konfigurieren des öffentlichen Profils​

Outbound​

Routing​