MTProxy en puerto 443 con Nginx: Configuración oculta para Telegram

Configuración Sigilosa de MTProxy en Nginx Puerto 443 para Telegram

Este artículo aborda un desafío crítico para administradores de sistemas y desarrolladores: desplegar MTProxy de Telegram en el puerto HTTPS estándar 443 sin interrumpir los servicios web existentes gestionados por Nginx. Esta configuración mejora significativamente la resistencia del proxy contra la detección y el bloqueo al camuflar su tráfico como tráfico web regular. La complejidad principal reside en la capacidad de Nginx para enrutar correctamente las solicitudes, distinguiendo entre sitios HTTP/HTTPS de destino y MTProxy mientras utiliza el mismo puerto. Esta guía detalla el mecanismo operativo del módulo stream de Nginx y su integración con mtprotoproxy para crear una solución robusta y discreta.

Cómo Funciona Nginx Stream para la Multiplexación

Para que MTProxy y Nginx coexistan con éxito en el puerto 443, es esencial un mecanismo de enrutamiento inteligente. El módulo stream de Nginx, que opera en la capa TCP/UDP, permite el análisis de los datos iniciales de conexión antes del procesamiento completo de la capa de aplicación. Un aspecto clave es que el campo Server Name Indication (SNI) en un mensaje TLS ClientHello se transmite en texto plano, incluso para conexiones cifradas. Esto permite a Nginx leer el nombre de host solicitado sin descifrar todo el flujo SSL.

La solución propuesta emplea la siguiente lógica:

Reasignación de Puerto para Hosts HTTPS: Todos los hosts virtuales HTTPS de Nginx existentes que anteriormente escuchaban en el puerto 443 se mueven a un puerto interno, como el 4443. Esto libera el puerto 443 para un manejador centralizado.
Nginx Stream como Enrutador Central: Se configura un servidor stream de Nginx en el puerto 443 ahora disponible. Este servidor utiliza la directiva ssl_preread on para extraer el SNI de las conexiones SSL entrantes.
Enrutamiento Dinámico: Basado en el SNI extraído, Nginx stream toma una decisión:

* Si el SNI coincide con el nombre de dominio elegido para MTProxy (por ejemplo, myprovider.ru), la conexión se reenvía a MTProxy (que escuchará en un puerto local, como el 7788).

* Si el SNI coincide con cualquier otro nombre de dominio, la conexión se redirige de nuevo a Nginx, pero al puerto interno 4443, donde será procesada por los hosts virtuales HTTPS estándar.

Preservación de la IP Real: Para un registro preciso, análisis de tráfico y el correcto funcionamiento de las aplicaciones detrás de Nginx, se utiliza proxy_protocol. Esto permite que la dirección IP real del cliente se pase a lo largo de la cadena de proxy.

Este enfoque permite que MTProxy se camufle como tráfico HTTPS regular, utilizando el mismo puerto que el servidor web. Esto aumenta significativamente su resistencia contra la detección y el bloqueo, haciendo que su tráfico sea indistinguible de las conexiones web estándar.

Configuración de Nginx para la Coexistencia

El primer paso es modificar la configuración de todos los hosts virtuales HTTPS de Nginx existentes. Debe cambiar el puerto en el que escuchan de 443 a uno interno, por ejemplo, 127.0.0.1:4443. Esto asegura que Nginx procesará estas solicitudes después de que el módulo stream las redirija.

Ejemplo de modificación del bloque server:

server {
  server_name mywebsite.ru;
  listen 127.0.0.1:4443 ssl http2 proxy_protocol;
  set_real_ip_from 127.0.0.1;    # Trust localhost as the PROXY Protocol source
  real_ip_header proxy_protocol; # Extract IP from PROXY Protocol header
  real_ip_recursive on;          # Apply recursively for correct IP determination
  # ... other directives for your server block ...
  ssl_certificate /etc/letsencrypt/live/mywebsite.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mywebsite.ru/privkey.pem;
  # ... other SSL/TLS settings ...
}

La directiva proxy_protocol en listen instruye a Nginx para que espere una cabecera del Protocolo PROXY. set_real_ip_from y real_ip_header son cruciales para que Nginx identifique y transmita correctamente la dirección IP real del cliente, en lugar de la IP del host local (127.0.0.1) que será utilizada por Nginx Stream. Sin estas configuraciones, todas las solicitudes a sus sitios parecerían originarse desde 127.0.0.1, lo que podría interrumpir la funcionalidad de la aplicación, el registro y los sistemas de seguridad.

El siguiente paso es crear un nuevo archivo de configuración para el módulo stream de Nginx. Se recomienda colocarlo en /etc/nginx/conf.d/stream.conf o en otra ubicación adecuada que asegure que Nginx lo cargue.

stream {
    log_format stream '$remote_addr [$time_local] host=$ssl_preread_server_name '
                      'prot=$protocol status=$status out=$bytes_sent in=$bytes_received';

    # Optional: enable logging for debugging
    #access_log /var/log/nginx/stream_access.log stream;
    #error_log /var/log/nginx/stream_error.log;

    map $ssl_preread_server_name $backend_name {
        myprovider.ru      tg_proxy;    # Traffic for the selected MTProxy domain
        default            nginx_https; # All other HTTPS traffic
    }

    upstream nginx_https {
        server 127.0.0.1:4443; # Redirect to Nginx's internal port
    }

    upstream tg_proxy {
        server 127.0.0.1:7788; # Redirect to MTProxy's local port
    }

    server {
        listen 443 reuseport; # Listen on the main 443 port
        proxy_pass $backend_name;
        ssl_preread on;       # Enable SNI reading to determine hostname
        proxy_protocol on;    # Enable PROXY Protocol to pass the real IP
    }
}

En este bloque, map se utiliza para asociar el SNI ($ssl_preread_server_name) con un nombre de backend. $backend_name será tg_proxy o nginx_https dependiendo del dominio solicitado. La directiva upstream define dónde se reenviará el tráfico para cada backend. listen 443 reuseport permite que múltiples procesos de Nginx escuchen en el mismo puerto, mejorando el rendimiento y la tolerancia a fallos. ssl_preread on es una directiva crucial que permite a Nginx obtener el SNI sin descifrar todo el tráfico SSL.

Si su instalación actual de Nginx no soporta el módulo stream (por ejemplo, es una compilación mínima), deberá instalarlo. En Debian/Ubuntu, esto se hace con el comando:

sudo apt install nginx-full

Después de realizar todos los cambios, debe verificar la configuración de Nginx y reiniciarlo:

nginx -t && sudo systemctl restart nginx

Usar systemctl restart en lugar de service nginx restart es el enfoque más moderno y preferido en sistemas basados en systemd.

Instalación y Configuración de MTProxy

Para implementar MTProxy en esta configuración, utilizaremos la implementación en Python altamente eficiente mtprotoproxy de alexbers, que se integra bien con proxy_protocol de Nginx y soporta el modo de camuflaje TLS requerido.

El proceso de instalación implica clonar el repositorio y cambiar a la rama adecuada:

(cd /opt || sudo mkdir /opt && sudo chown $(whoami):$(whoami) /opt) && cd /opt
git clone https://github.com/alexbers/mtprotoproxy.git
cd mtprotoproxy
# Important: At the time of writing, stable operation with this configuration is achieved on the master branch
git checkout master

A continuación, genere una clave secreta para MTProxy. Esta clave secreta será utilizada por los clientes de Telegram para la autenticación y debe ser única:

head -c 16 /dev/urandom | xxd -ps

El valor hexadecimal resultante de 32 caracteres debe guardarse. Ahora, necesita crear o editar el archivo config.py en el directorio mtprotoproxy:

# /opt/mtprotoproxy/config.py
PORT = 7788 # Local port to which Nginx Stream will redirect traffic
LISTEN_ADDR_IPV4 = "127.0.0.1" # Bind to localhost for security
LISTEN_ADDR_IPV6 = None # Disable IPv6 if not needed or configured

# Dictionary of users and their secrets. Multiple can be created for different groups.
USERS = {
    "tg_user_1":  "YOUR_GENERATED_SECRET_HERE",
    # "tg_user_2": "0123456789abcdef0123456789abcdef", # Example of an additional secret
}

# MTProxy operating modes
MODES = {
    "classic": False, # Classic mode, easily detectable
    "secure": False,  # Improved mode, but not optimal for masquerading
    "tls": True       # TLS masquerading mode, most resistant to detection
}

# Domain for TLS mode. MTProxy will check its availability on startup.
# Use the domain you selected in the Nginx Stream configuration.
TLS_DOMAIN = "myprovider.ru" # Domain that will be used for MTProxy
PROXY_PROTOCOL = True # Mandatory setting for working with Nginx Stream
# AD_TAG = "GET_YOUR_AD_TAG_FROM_@MTProxybot" # Optional: for advertising tag

Las configuraciones clave aquí incluyen: LISTEN_ADDR_IPV4 = "127.0.0.1" asegura que MTProxy solo sea accesible a través de Nginx en el mismo servidor, mejorando la seguridad. MODES = {"tls": True} activa el modo de camuflaje TLS, haciendo que el tráfico de MTProxy sea indistinguible del HTTPS regular. TLS_DOMAIN debe coincidir con el nombre de dominio especificado en la directiva map de Nginx Stream para que Nginx identifique y reenvíe el tráfico correctamente. Finalmente, PROXY_PROTOCOL = True permite a MTProxy recibir la dirección IP real del cliente de Nginx, lo cual es crucial para un funcionamiento y registro adecuados.

Verificación e Inicio Automatizado

Después de configurar Nginx y MTProxy, es esencial verificar a fondo la funcionalidad de todo el sistema.

Verificación de la Funcionalidad de MTProxy y Nginx

Inicio Manual de MTProxy: Navegue al directorio /opt/mtprotoproxy e inicie MTProxy manualmente para una verificación inicial:

```bash

python3 mtprotoproxy.py

```

Debería aparecer una línea con los parámetros de conexión del proxy en la consola, por ejemplo:

```

tg_user_1: tg://proxy?server=YOUR_VM_IP&port=7788&secret=LONG_SECRET

```

Nota Importante: La clave secreta mostrada aquí tendrá un prefijo ee y contendrá el TLS_DOMAIN codificado especificado en config.py. Esto es parte del mecanismo de camuflaje TLS. Copie este enlace.

Prueba con un Cliente de Telegram:

* En el enlace copiado, cambie el puerto de 7788 a 443.

* Envíe el enlace resultante a sus "Mensajes Guardados" en Telegram.

* Haga clic en el enlace y seleccione "Conectar".

* Si todo está configurado correctamente, Telegram debería conectarse con éxito a través del proxy. Para una verificación adicional, puede enviar el comando /ping a cualquier bot (por ejemplo, @MTProxybot) — debería devolverse un mensaje con el ping actual del proxy.

Verificación del Camuflaje HTTPS: Para confirmar que MTProxy se camufla correctamente como un sitio web regular, realice la siguiente verificación:

* Agregue la siguiente línea a su archivo hosts local (para Linux/macOS, es /etc/hosts; para Windows, es %SystemRoot%\System32\drivers\etc\hosts):

```

YOUR_VM_IP myprovider.ru

```

* Reemplace YOUR_VM_IP con la dirección IP real de su servidor.

* Abra https://myprovider.ru en su navegador.

* Si todo funciona correctamente, debería ver el contenido de myprovider.ru (el sitio web de su proveedor o cualquier otro dominio que haya especificado en TLS_DOMAIN). Esto confirma que Nginx Stream redirigió la solicitud a MTProxy, y MTProxy, al reconocerla como tráfico no-Telegram, la proxy de forma transparente al recurso web original, demostrando un camuflaje TLS exitoso.

* No olvide eliminar la línea agregada de su archivo hosts después de la verificación.

Configuración de MTProxy como Servicio Systemd

Para asegurar que MTProxy se inicie automáticamente al arrancar el sistema y funcione de forma continua, se recomienda configurarlo como un servicio systemd.

Detenga el MTProxy que se ejecuta manualmente (Ctrl+C).
Cree un archivo de unidad systemd en /etc/systemd/system/mtprotoproxy.service:

```ini

[Unit]

Description=MTProto Proxy

After=network.target

[Service]

Type=simple

User=nobody

Group=nogroup

WorkingDirectory=/opt/mtprotoproxy

ExecStart=/usr/bin/python3 /opt/mtprotoproxy/mtprotoproxy.py

Restart=always

RestartSec=3

[Install]

WantedBy=multi-user.target

```

Aquí, User=nobody y Group=nogroup mejoran la seguridad al ejecutar el servicio con privilegios mínimos. WorkingDirectory apunta al directorio donde se encuentra el script mtprotoproxy.py.

Recargue la configuración de systemd, habilite el servicio e inícielo:

```bash

sudo systemctl daemon-reload

sudo systemctl enable mtprotoproxy.service

sudo systemctl start mtprotoproxy.service

```

Verifique el estado del servicio:

```bash

systemctl status mtprotoproxy.service

```

La salida debería indicar que el servicio está active (running).

Ver Registros: Para depuración o monitoreo, use:

```bash

journalctl -u mtprotoproxy.service -e

```

Esta configuración integral le permite usar MTProxy de Telegram en el puerto 443, camuflándolo eficazmente como tráfico HTTPS regular, mientras preserva la funcionalidad completa de los sitios web existentes en el mismo servidor.

Puntos Clave:

El uso de ssl_preread en Nginx Stream permite el enrutamiento de tráfico basado en SNI sin descifrado, lo cual es crítico para separar el tráfico de MTProxy y HTTPS en un solo puerto.
La configuración de proxy_protocol tanto en Nginx como en MTProxy asegura la transmisión de la dirección IP real del cliente, lo cual es vital para el registro y la seguridad.
MTProxy se configura en modo tls: True con TLS_DOMAIN especificado, haciendo que el tráfico del proxy sea indistinguible de una conexión HTTPS regular a ese dominio.
Vincular MTProxy a 127.0.0.1 mejora la seguridad al restringir el acceso externo directo.
El servicio systemd asegura el inicio automático y el monitoreo de MTProxy, garantizando su funcionamiento continuo.