Enrutamiento del lado del servidor

Solo para demostración | No listo para producción

Esta guía está diseñada únicamente como demostración del enrutamiento del lado del servidor. No asumas que copiar estos ejemplos producirá una configuración completamente funcional en producción. No cubre todas las capacidades de Xray-core, ni se garantiza que funcione perfectamente en todos los entornos.

Para obtener detalles completos sobre la sintaxis de configuración y el comportamiento, consulta la documentación oficial de Xray.

Algunos usuarios pueden haber notado que Remnawave borra automáticamente el array clients de la configuración del Node. Esto no es un error, sino un comportamiento intencionado. Remnawave lo borra para garantizar que solo se conserven las configuraciones necesarias para que ciertas funciones operen correctamente.

En esta guía, configuraremos el enrutamiento de tráfico del lado del servidor usando dos Nodes: RU y DE. Los usuarios se conectarán al Node RU. Desde allí, el tráfico se enrutará de la siguiente manera:

El tráfico hacia sitios web .ru se enviará directamente a través del Node RU.
Todo el demás tráfico se enrutará a través del Node DE.

Para lograr esto, crearemos un usuario de servicio que facilitará el enrutamiento del tráfico.

Como resultado, el "flujo" de tráfico podría verse así:

El usuario abre google.com.
La solicitud llega primero al Node RU.
El Node RU aplica las reglas de enrutamiento. Dado que google.com no es un dominio .ru, el tráfico se enruta al Node DE.
El Node DE completa la conexión a google.com.

Este tipo de configuración de enrutamiento del lado del servidor se conoce habitualmente como "puente".

Crear un perfil de configuración para DE

Ve a la sección de Perfiles de configuración y crea un nuevo Perfil de configuración, p. ej. 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": []
    }
}

No olvides asignar el perfil y crear un Squad interno

Asigna el Perfil de configuración recién creado al Node DE. Selecciona el Inbound BRIDGE_DE_IN.

Crea un nuevo Squad interno, llamémoslo Bridge Squad. Habilita el Inbound que creamos anteriormente — BRIDGE_DE_IN.

Crear un usuario de servicio

Para que nuestro puente funcione, necesitaremos crear un usuario. Llamémoslo bridge_user.

No olvides eliminar los límites de tráfico y extender la fecha de vencimiento

Como se trata de un usuario de servicio, evidentemente no queremos que su suscripción expire ni esté limitada por el uso de tráfico. Establece Data Limit en 0 y Expiry Date en el año 2099.

A continuación, asigna el Squad correspondiente a este usuario. En nuestro caso, es Bridge Squad.

Una vez creado el usuario de servicio, necesitaremos obtener su contraseña. Abre la tarjeta del usuario, haz clic en el botón More Actions y luego en Detailed Info. Allí deberías ver la sección Connection Information.

Dependiendo del protocolo del Inbound (Shadowsocks en nuestro caso), copia el valor apropiado:

Protocolo	Valor de información de conexión
Trojan	Contraseña de Trojan
VLESS	UUID de VLESS
Shadowsocks	Contraseña de SS

Configurar un perfil público

Lo más probable es que ya tengas un Perfil de configuración al que se conectan tus usuarios. Si no es así, consulta esta guía.

En este paso, no nos interesan los "inbounds" — en su lugar, modificaremos los arrays "outbounds", "routing" y "rules" de ese perfil.

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

Primero necesitamos modificar el array 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"
            }
        ]
    }
}

Campo	Valor
`address`	La dirección IP o nombre de dominio de tu servidor del Node `DE`.
`port`	El puerto del Inbound, en nuestro caso el puerto de `BRIDGE_DE_IN`.
`password`	La contraseña del usuario de servicio. Depende del protocolo que estés usando; consulta el paso anterior.
`method`	Método de cifrado. Para Shadowsocks en Remnawave, usa siempre `chacha20-ietf-poly1305`.

Enrutamiento y reglas

A continuación, modifica las reglas de enrutamiento según tus necesidades.

A continuación se muestra el ejemplo de una regla que hace que el Node RU sea el nodo de salida para IPs y sitios web rusos, mientras que el resto del tráfico se envía al Node DE.

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

A continuación se muestra el ejemplo de una regla que enruta todo el tráfico al Outbound SS_OUTBOUND_TO_DE.

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

El perfil de configuración público completo podría verse así:

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"
            }
        ]
    }
}

tip

Las reglas de enrutamiento de Xray se procesan en orden, de arriba a abajo.
Así es como funcionan las reglas en nuestro ejemplo:

IPs privadas (geoip:private) → BLOCK
El tráfico que coincide con esta regla se envía al Outbound BLOCK, que es un protocolo blackhole (completamente bloqueado).
Dominios privados (geosite:private) → BLOCK
Igual que el anterior, pero para nombres de dominio.
Tráfico BitTorrent (bittorrent) → BLOCK
Todo el tráfico BitTorrent es bloqueado.
IPs rusas (geoip:ru) → DIRECT
El tráfico que coincide con esta regla se envía al Outbound DIRECT, que es un protocolo freedom (el Node RU actúa como nodo de salida).
Dominios rusos (geosite:category-ru) → DIRECT
El tráfico hacia dominios rusos también sale directamente desde el Node RU.
Sin coincidencia de regla (el resto del tráfico) → SS_OUTBOUND_TO_DE
Cualquier tráfico restante que llegue al PUBLIC_RU_INBOUND se enruta al Node DE a través del Outbound Shadowsocks que creamos anteriormente.

No tienes que usar Shadowsocks como protocolo de tránsito — puedes usar VLESS en su lugar. Solo asegúrate de actualizar tu configuración en consecuencia.

Crear un perfil de configuración para DE​

Crear un usuario de servicio​

Configurar un perfil público​

Outbounds​

Enrutamiento y reglas​

Crear un perfil de configuración para DE

Crear un usuario de servicio

Configurar un perfil público

Outbounds

Enrutamiento y reglas