MTProto en puerto 443 con web en un mismo VPS

Para ejecutar un proxy MTProto y un sitio web en un mismo VPS a través del puerto 443, incluso cuando otros puertos están bloqueados, se configura un servidor frontend como Nginx Stream con el módulo ssl_preread para analizar el handshake TLS y redirigir el tráfico al servidor web o al backend MTProto, que operan en puertos locales como 8443 y 4433 respectivamente.

¿Por qué usar MTProto en el puerto 443 si ya lo ocupa un sitio web?

En un contexto de restricciones y bloqueos generalizados del tráfico de red, especialmente en regiones con censura activa, el uso de puertos estándar y de acceso público no es solo una comodidad, sino una necesidad crítica. El puerto 443, tradicionalmente utilizado para el tráfico HTTPS, es el menos susceptible a la filtración y los bloqueos, ya que la mayor parte del tráfico web cifrado pasa a través de él. Si tu proxy MTProto de Telegram funciona en un puerto no estándar, por ejemplo, 8888 o 9999, existe una alta probabilidad de que este puerto sea bloqueado por el proveedor de internet o un firewall estatal. Mover MTProto al puerto 443 aumenta significativamente su disponibilidad y resistencia a los bloqueos, ya que se "disfraza" de tráfico HTTPS normal.

El problema de los bloqueos y la importancia de los puertos estándar

Muchos proveedores y sistemas de filtrado estatales utilizan activamente la inspección profunda de paquetes (DPI) para identificar y bloquear el tráfico que no cumple con los protocolos estándar en puertos estándar. Por ejemplo, si se detecta tráfico en el puerto 443 que no es HTTPS, o tráfico en el puerto 80 que no es HTTP, esto puede ser una señal para el bloqueo. MTProto, aunque cifrado, tiene sus patrones característicos. Sin embargo, si funciona en el puerto 443, su tráfico se mezcla con un enorme volumen de tráfico HTTPS legítimo, lo que dificulta su identificación y bloqueo. Esto es especialmente relevante para el enmascaramiento del tráfico proxy.

Ahorro de recursos y enmascaramiento: proxy y sitio web en un mismo servidor

Ejecutar un proxy MTProto y un sitio web en un mismo VPS tiene un doble beneficio. Primero, es un ahorro de recursos. En lugar de alquilar dos VPS separados (uno para el sitio web, otro para el proxy), puedes usar un único servidor potente. Esto reduce los costos de alquiler y simplifica la gestión de la infraestructura. Segundo, aumenta el enmascaramiento de MTProto. Si en la misma dirección IP que el proxy funciona un sitio web completo, cuyo tráfico pasa por el mismo puerto 443, esto crea la apariencia de un servidor normal y legítimo. En caso de una inspección o análisis de tráfico, la presencia de un sitio web real de cobertura hace que el proxy sea menos visible y sospechoso. Esto es especialmente efectivo cuando el sitio web utiliza un certificado SSL de una autoridad de certificación conocida, como Let's Encrypt, lo que le da al tráfico aún más credibilidad.

Cómo funciona el enrutamiento SNI: un solo puerto 443 para dos servicios

La esencia del problema es que el puerto 443 solo puede ser ocupado por un proceso en el sistema operativo. Si quieres que tanto el servidor web (Nginx, Apache) como el proxy MTProto escuchen en este puerto, surge un conflicto. La solución radica en la tecnología Server Name Indication (SNI) y el uso de un proxy frontend que puede analizar la etapa inicial del handshake TLS sin descifrar todo el tráfico.

¿Qué es SNI y cómo ayuda en el enrutamiento?

SNI (Server Name Indication) es una extensión del protocolo TLS que permite al cliente (navegador, cliente de Telegram) especificar el nombre de host (nombre de dominio) del servidor al que intenta conectarse, incluso antes de que comience el handshake TLS completo. Esta información se transmite sin cifrar en el encabezado ClientHello. El servidor frontend, que escucha en el puerto 443, puede interceptar este encabezado, analizar el nombre SNI y, basándose en él, decidir a dónde redirigir el tráfico cifrado posterior: al backend del servidor web (por ejemplo, Nginx, Apache) o al backend del proxy MTProto.

De esta manera, para el cliente todo parece como si se estuviera conectando a un servidor HTTPS normal por nombre de dominio (para el sitio web) o a un proxy MTProto por dirección IP/nombre de dominio (para el proxy). El servidor frontend actúa como un despachador inteligente, dirigiendo el tráfico al servicio correcto, que se ejecuta en otro puerto, generalmente local. Este es un punto clave para implementar el esquema "MTProto puerto 443" junto con un sitio web.

Esquema de interacción: frontend, backends y certificados

Un esquema típico es el siguiente:

El Cliente (navegador o cliente de Telegram) inicia una conexión TLS a tu VPS en el puerto 443.
El Proxy frontend (Nginx Stream o SNIProxy) intercepta esta conexión.
El proxy frontend analiza el encabezado ClientHello, extrayendo el nombre SNI.
- Si el nombre SNI coincide con el dominio de tu sitio web (por ejemplo, mysite.com), el frontend redirige el tráfico a un puerto local donde escucha tu servidor web (Nginx/Apache), por ejemplo, a 127.0.0.1:8443.
- Si el nombre SNI está ausente (lo cual es característico de MTProto si el cliente se conecta por IP) o coincide con un dominio especial que puedes asignar para MTProto (por ejemplo, proxy.mysite.com), el frontend redirige el tráfico a un puerto local donde escucha el proxy MTProto, por ejemplo, a 127.0.0.1:4433.
El Servidor backend (servidor web o proxy MTProto) recibe el tráfico, lo procesa y responde al cliente.

Es importante que el servidor web en 127.0.0.1:8443 tenga su propio certificado SSL para mysite.com, y el proxy MTProto en 127.0.0.1:4433 no requiere su propio certificado SSL, ya que el handshake TLS se maneja en el lado del frontend, y MTProto utiliza su propio protocolo de cifrado. Sin embargo, para una mayor credibilidad y resistencia a los bloqueos, MTProto puede configurarse con una capa TLS ficticia que utilice un certificado de un sitio web real. Esto hace que el tráfico MTProto sea indistinguible del HTTPS normal a nivel del handshake TLS.

¿Buscas un servidor fiable para tus proyectos?

VPS desde 10 $/mes y servidores dedicados desde 9 $/mes con NVMe, protección DDoS y soporte 24/7.

Ver ofertas →

Elegir un frontend para el enrutamiento SNI: Nginx Stream vs. SNIProxy

Para implementar el enrutamiento SNI en el puerto 443, tienes dos opciones principales: Nginx Stream con el módulo ssl_preread o el SNIProxy especializado. Ambas soluciones son efectivas, pero tienen sus propias características y áreas de aplicación.

Nginx Stream con el módulo ssl_preread: flexibilidad y rendimiento

Nginx, conocido por su rendimiento y flexibilidad como servidor web y proxy inverso, también puede actuar como proxy TCP/UDP a través de su módulo Stream. Con la adición del módulo ssl_preread, Nginx Stream se convierte en una potente herramienta para el enrutamiento SNI. Este módulo permite a Nginx analizar el nombre SNI del ClientHello de TLS sin descifrar todo el tráfico TLS. Esto significa que Nginx funciona a nivel de TCP, simplemente redirigiendo los bytes cifrados al backend correcto basándose en el SNI.

Ventajas de Nginx Stream:

Versatilidad: Si Nginx ya se utiliza en tu VPS para el servidor web, su módulo Stream permite centralizar la gestión del proxy.
Rendimiento: Nginx es conocido por su capacidad para manejar un gran número de conexiones simultáneas con una sobrecarga mínima.
Flexibilidad: Amplias opciones de configuración, incluyendo balanceo de carga, tiempos de espera, límites de conexión y otras configuraciones avanzadas.
Descarga de SSL/TLS: Aunque para el enrutamiento SNI Nginx no descifra el tráfico, puede configurarse para la descarga de SSL para el tráfico web, si es necesario.

Desventajas:

Requiere compilar Nginx con el módulo --with-stream_ssl_preread_module, si no está incluido por defecto en tu compilación (a menudo incluido en distribuciones modernas).
La configuración puede ser más compleja para principiantes en comparación con proxies simples.

SNIProxy: una solución ligera para tareas específicas

SNIProxy es un servidor proxy especializado diseñado específicamente para el enrutamiento SNI. Es mucho más ligero que Nginx y no tiene una funcionalidad tan amplia, pero cumple perfectamente su tarea principal: analizar el SNI y redirigir el tráfico. Es una solución ideal si solo necesitas enrutamiento SNI y no quieres usar Nginx para otros fines o prefieres soluciones minimalistas.

Ventajas de SNIProxy:

Ligereza: Consume significativamente menos recursos del sistema en comparación con Nginx.
Simplicidad: La configuración de SNIProxy suele ser más sencilla y directa.
Especialización: Optimizado para su tarea, lo que puede ser una ventaja en algunos escenarios.

Desventajas:

Menos funciones adicionales en comparación con Nginx (sin balanceo de carga, registros avanzados, etc.).
Menos común, lo que puede dificultar la búsqueda de soluciones listas para usar o el soporte de la comunidad.

Para la mayoría de los usuarios, especialmente aquellos que ya utilizan Nginx para el servidor web, Nginx Stream es la opción preferida debido a su versatilidad y rendimiento. Sin embargo, si buscas una solución lo más ligera y sencilla posible exclusivamente para el enrutamiento SNI, SNIProxy también será una excelente opción.

Elección rápida

¿Buscas un servidor que simplemente funcione?

Valebyte VPS: NVMe, soporte 24/7, despliegue en 60 segundos.

Ver planes VPS

Configuración paso a paso de Nginx Stream para MTProto y un sitio web

Veamos la configuración detallada paso a paso de Nginx Stream para la operación conjunta de un proxy MTProto y un sitio web en un mismo VPS, utilizando el puerto 443. Esta configuración permitirá que tu VPS sirva de manera eficiente a ambos servicios, aumentando su resistencia a los bloqueos y el ahorro de recursos.

Preparación del VPS: instalación de Nginx y Let's Encrypt

En primer lugar, asegúrate de que tu VPS de Valebyte.com esté listo para funcionar. Necesitarás una instalación limpia de Ubuntu Server (por ejemplo, 22.04 LTS) o Debian. Para empezar, actualizaremos el sistema e instalaremos los paquetes necesarios:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx certbot python3-certbot-nginx

Asegúrate de que Nginx esté instalado con el módulo stream_ssl_preread. En la mayoría de las distribuciones modernas, está incluido por defecto. Puedes verificarlo así:

nginx -V 2>&1 | grep --color stream_ssl_preread_module

Si la salida contiene --with-stream_ssl_preread_module, todo está en orden. Si no, tendrás que compilar Nginx desde el código fuente o encontrar un paquete con este módulo.

Para nuestro sitio web, necesitaremos un nombre de dominio (por ejemplo, mywebsite.com). Asegúrate de que el registro A de tu dominio apunte a la dirección IP de tu VPS.

Configuración de Nginx Stream para el enrutamiento SNI

Ahora procedamos con la configuración de Nginx. Abre el archivo /etc/nginx/nginx.conf y añade la sección stream fuera de la sección http. Si la sección stream ya existe, úsala.

# Añade esto al principio del archivo, después de la directiva 'user nginx;' o 'user www-data;'

stream {
    map $ssl_preread_server_name $name {
        hostnames;

        # Dominio de tu sitio web
        mywebsite.com           web;
        www.mywebsite.com       web;

        # Dominio para MTProto (opcional, si no usas IP)
        proxy.mywebsite.com     mtproto;

        # Si SNI no se proporciona o no coincide con ninguno de los dominios,
        # por defecto, dirigimos a MTProto. Esto es importante, ya que Telegram
        # a menudo no envía SNI al conectarse por IP.
        default                 mtproto;
    }

    upstream web_backend {
        server 127.0.0.1:8443; # Puerto local para el tráfico HTTPS del sitio web
    }

    upstream mtproto_backend {
        server 127.0.0.1:4433; # Puerto local para el proxy MTProto
    }

    server {
        listen 443 reuseport;
        listen [::]:443 reuseport; # Para IPv6

        ssl_preread on;
        proxy_pass $name_backend;
        proxy_timeout 30s;
        proxy_connect_timeout 5s;
    }
}

# ... el resto de nginx.conf (sección http, etc.)

Explicaciones de la configuración:

map $ssl_preread_server_name $name: Esta directiva crea una variable $name, cuyo valor depende del nombre SNI obtenido del handshake TLS.
hostnames;: Habilita el soporte para la coincidencia por nombres de dominio.
mywebsite.com web;: Si el nombre SNI es mywebsite.com, la variable $name toma el valor web.
default mtproto;: Si el nombre SNI no se encuentra o no coincide con ninguno de los listados, el tráfico irá a mtproto. Esto es crítico para MTProto, ya que muchos clientes se conectan por IP y no transmiten SNI, o MTProto por su naturaleza puede no usarlo.
upstream web_backend: Define un grupo de servidores para el tráfico web. En nuestro caso, es el puerto local 8443.
upstream mtproto_backend: Define un grupo de servidores para MTProto. Es el puerto local 4433.
listen 443 reuseport;: Nginx escucha en el puerto 443. La directiva reuseport permite que varios procesos escuchen en el mismo puerto, lo que puede ser útil para el rendimiento, pero en este caso, el puerto en sí es clave.
ssl_preread on;: Habilita el módulo ssl_preread, que permite a Nginx analizar el SNI.
proxy_pass $name_backend;: La directiva más importante. Redirige el tráfico al upstream correspondiente según el valor de la variable $name.

Configuración del servidor MTProto (mtg)

Para MTProto, usaremos mtg (Telegram MTProto Proxy). Instálalo si aún no lo has hecho:

sudo apt install -y snapd
sudo snap install mtg-proxy

Ahora inicia mtg en el puerto local 4433. Es importante que MTProto escuche solo en la interfaz local (127.0.0.1), ya que Nginx Stream le hará proxy al tráfico. Crea un secreto e inicia:

SECRET=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)
sudo mtg-proxy.mtg run -p 127.0.0.1:4433 -s $SECRET --tag your_ad_tag

Reemplaza your_ad_tag por tu etiqueta publicitaria, si la tienes. Anota el SECRET generado, lo necesitarás para conectar a los clientes. Para que mtg se inicie automáticamente al reiniciar, es mejor crear un servicio systemd. Crea el archivo /etc/systemd/system/mtg-proxy.service:

[Unit]
Description=MTProto Proxy
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/snap/bin/mtg-proxy.mtg run -p 127.0.0.1:4433 -s YOUR_SECRET_HERE --tag YOUR_AD_TAG_HERE
Restart=on-failure

[Install]
WantedBy=multi-user.target

No olvides reemplazar YOUR_SECRET_HERE y YOUR_AD_TAG_HERE con tus valores. Luego:

sudo systemctl daemon-reload
sudo systemctl enable mtg-proxy.service
sudo systemctl start mtg-proxy.service
sudo systemctl status mtg-proxy.service

Asegúrate de que MTProto esté funcionando y escuchando en 127.0.0.1:4433.

Configuración del servidor web (Nginx HTTP)

Ahora configuraremos Nginx como servidor web, que escuchará en el puerto local 8443.

Crea un nuevo archivo de configuración para tu sitio web, por ejemplo, /etc/nginx/sites-available/mywebsite.com:

server {
    listen 127.0.0.1:8443 ssl http2;
    listen [::1]:8443 ssl http2; # Para IPv6

    server_name mywebsite.com www.mywebsite.com;

    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    root /var/www/mywebsite.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    # Configuraciones adicionales de registro, caché, etc.
}

Crea el directorio para tu sitio web y un archivo de prueba:

sudo mkdir -p /var/www/mywebsite.com
echo "Hello from mywebsite.com!" | sudo tee /var/www/mywebsite.com/index.html

Habilita el sitio web y verifica la configuración de Nginx:

sudo ln -s /etc/nginx/sites-available/mywebsite.com /etc/nginx/sites-enabled/
sudo nginx -t

Si no hay errores, reinicia Nginx:

sudo systemctl restart nginx

Obtención y gestión de certificados SSL de Let's Encrypt

Para tu sitio web mywebsite.com, se necesita un certificado SSL válido. Usaremos Certbot con Let's Encrypt. Dado que Nginx Stream ya ha ocupado el puerto 443, Certbot no podrá usar su método estándar --nginx o --standalone en el puerto 443. En su lugar, podemos deshabilitar temporalmente Nginx Stream o usar el método --webroot si ya tienes un servidor web funcionando en el puerto 80 (que Certbot puede usar para la validación). O, la forma más sencilla: modificar temporalmente Nginx Stream para que haga proxy de las solicitudes de Certbot al puerto 80.

Método 1: Uso de --webroot

Si ya tienes Nginx HTTP funcionando en el puerto 80 (lo cual es común para Certbot) para redirigir HTTP a HTTPS, puedes usar --webroot. Para ello, asegúrate de que tu Nginx HTTP escuche en el puerto 80 y tenga la directiva location /.well-known/acme-challenge/. Si no, añádelo temporalmente a Nginx HTTP en el puerto 80:

server {
    listen 80;
    listen [::]:80;
    server_name mywebsite.com www.mywebsite.com;

    location /.well-known/acme-challenge/ {
        root /var/www/mywebsite.com; # O cualquier otra ruta accesible
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Reinicia Nginx, luego:

sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com

Después de obtener los certificados, Certbot los configurará automáticamente para tu Nginx HTTP. Si utilizas la configuración de Nginx Stream como se describe anteriormente, Certbot no podrá actualizar automáticamente los certificados para el servidor web, ya que este escucha en el puerto 8443. Deberás especificar manualmente las rutas a los certificados en la configuración de mywebsite.com, como se muestra arriba.

Método 2: Deshabilitar temporalmente Nginx Stream y usar --nginx (menos conveniente)

Comenta o elimina la sección stream de nginx.conf.
Reinicia Nginx: sudo systemctl restart nginx.

Obtén el certificado para mywebsite.com, configurando Nginx para HTTP en el puerto 80 (configuración temporal):

server {
            listen 80;
            server_name mywebsite.com www.mywebsite.com;
            location / {
                return 301 https://$host$request_uri;
            }
        }

Reinicia Nginx.

Ejecuta Certbot: sudo certbot --nginx -d mywebsite.com -d www.mywebsite.com.
Después de obtener los certificados con éxito, restaura la configuración de Nginx Stream en nginx.conf y la configuración del servidor web en el puerto 8443.
Reinicia Nginx.

Actualización automática de certificados:

Certbot crea automáticamente una tarea cron para la renovación de certificados. Asegúrate de que funcione:

sudo systemctl status certbot.timer

Si los certificados se actualizan, Nginx debería cargarlos. Si usas Nginx HTTP en el puerto 8443, después de que Certbot actualice los certificados, tendrás que reiniciar Nginx para que cargue los nuevos certificados:

sudo systemctl reload nginx

Añade este comando al script de actualización de Certbot si no lo hace automáticamente.

Configuración de SNIProxy para MTProto y un sitio web (opción alternativa)

Si prefieres SNIProxy en lugar de Nginx Stream, aquí te explicamos cómo configurarlo. SNIProxy es una solución más ligera y especializada.

Instalación y configuración básica de SNIProxy

Instala SNIProxy desde los repositorios:

sudo apt update
sudo apt install -y sniproxy

El archivo de configuración principal de SNIProxy se encuentra en /etc/sniproxy.conf. Ábrelo y configúralo de la siguiente manera:

# /etc/sniproxy.conf

user sniproxy
pidfile /var/run/sniproxy.pid

# Registro (opcional)
accesslog {
    filename /var/log/sniproxy/access.log
    # format "%t %h %p %s %T" # Ejemplo de formato
}
errorlog {
    filename /var/log/sniproxy/error.log
    # level error # Nivel de registro
}

# Escuchamos conexiones entrantes en el puerto 443
listener 443 {
    proto tls
    table {
        # Enrutamiento para tu sitio web
        mywebsite.com 127.0.0.1:8443
        www.mywebsite.com 127.0.0.1:8443

        # Enrutamiento para MTProto (si se usa un dominio)
        proxy.mywebsite.com 127.0.0.1:4433

        # Regla por defecto para MTProto, si SNI está ausente o no coincide
        .* 127.0.0.1:4433
    }
}

Explicaciones de la configuración:

user sniproxy: El usuario bajo el cual se ejecutará SNIProxy.
listener 443 { proto tls ... }: SNIProxy escuchará el puerto TCP 443, esperando tráfico TLS.
table { ... }: Define las reglas de enrutamiento basadas en SNI.
mywebsite.com 127.0.0.1:8443: Si el nombre SNI es mywebsite.com, el tráfico se redirige al puerto local 8443 (donde escucha tu Nginx HTTP).
.* 127.0.0.1:4433: Esta es la regla por defecto. Si el nombre SNI no coincide con ninguno de los listados (o está ausente), el tráfico se redirige al puerto local 4433 (donde escucha MTProto).

Después de configurar el archivo, reinicia SNIProxy:

sudo systemctl restart sniproxy
sudo systemctl enable sniproxy
sudo systemctl status sniproxy

Asegúrate de que SNIProxy esté funcionando sin errores. Después de esto, tus Nginx HTTP (en 127.0.0.1:8443) y MTProto (en 127.0.0.1:4433) recibirán tráfico a través de SNIProxy en el puerto 443.

Parámetros adicionales y matices

SNIProxy, a diferencia de Nginx Stream, no ofrece tantas configuraciones finas, pero para el enrutamiento SNI básico suele ser suficiente. Asegúrate de que tus backends (Nginx HTTP y MTProto) estén configurados para escuchar solo en interfaces locales (127.0.0.1 o [::1]) en sus puertos dedicados (8443 y 4433 respectivamente) para evitar conflictos y aumentar la seguridad.

Además, al usar SNIProxy, Certbot funcionará sin problemas, ya que SNIProxy no interfiere con el proceso de obtención de certificados (Certbot generalmente usa el puerto 80 para la validación, y SNIProxy escucha en el 443).

Diagnóstico y solución de problemas comunes

Configurar el enrutamiento SNI puede ser complicado, y los errores ocurren. Es importante saber cómo diagnosticar problemas para solucionarlos rápidamente.

Verificación del funcionamiento del enrutamiento SNI

Para asegurarte de que el enrutamiento SNI funciona correctamente, realiza las siguientes comprobaciones:

Verificación de la accesibilidad del sitio web: Abre tu dominio https://mywebsite.com en un navegador. Si el sitio se carga y muestra el candado HTTPS, significa que el tráfico se enruta correctamente a tu servidor web. También puedes usar curl:
```
curl -v https://mywebsite.com
        
```
Busca en la salida información sobre el handshake TLS y el contenido de la página.
Verificación de la accesibilidad de MTProto: Intenta conectarte a tu proxy MTProto usando un cliente de Telegram. Si la conexión se establece y puedes enviar/recibir mensajes, significa que MTProto funciona.
Para una verificación más técnica, puedes usar openssl s_client. Si configuraste MTProto con una capa TLS ficticia que imita tu sitio web, puedes intentar conectarte a él especificando el SNI de tu sitio web:
```
openssl s_client -connect TU_IP:443 -servername mywebsite.com
        
```
Si el enrutamiento SNI funciona, deberías recibir una respuesta de tu servidor web. Si no especificas -servername o especificas algo diferente, deberías recibir "basura" o un tiempo de espera, lo que significaría que el tráfico fue a MTProto. MTProto no habla TLS, por lo que openssl no podrá establecer una conexión con él.
Verificación de los puertos en escucha: Asegúrate de que Nginx (o SNIProxy) escuche en el puerto 443, y que tu servidor web y MTProto escuchen solo en puertos locales (por ejemplo, 8443 y 4433) en 127.0.0.1.
```
sudo ss -tulpn | grep 443
        sudo ss -tulpn | grep 8443
        sudo ss -tulpn | grep 4433
        
```
La salida debería mostrar que Nginx (o sniproxy) escucha en *:443, y nginx (para el sitio web) y mtg-proxy escuchan en 127.0.0.1:8443 y 127.0.0.1:4433 respectivamente.
Verificación de los registros: Examina los registros de Nginx (/var/log/nginx/access.log, error.log) y MTProto (si configuraste el registro o usas systemctl status mtg-proxy.service). Los errores en los registros pueden indicar la fuente del problema.

Errores de configuración frecuentes y sus soluciones

Nginx Stream no se inicia o arroja errores:
- Problema: nginx -t arroja errores de sintaxis, o Nginx no se inicia.
- Solución: Revisa cuidadosamente la sintaxis de nginx.conf, especialmente la sección stream. Asegúrate de que todos los corchetes estén cerrados, las directivas estén escritas correctamente y no haya errores tipográficos. Verifica que Nginx esté compilado con el módulo stream_ssl_preread.
El sitio web no es accesible por HTTPS:
- Problema: El navegador muestra un error "ERR_CONNECTION_REFUSED" o "ERR_SSL_PROTOCOL_ERROR".
- Solución:
  - Asegúrate de que Nginx HTTP escuche en el puerto local correcto (por ejemplo, 127.0.0.1:8443) y tenga certificados SSL correctos.
  - Verifica que Nginx Stream esté enrutando correctamente el tráfico para tu dominio a web_backend (mywebsite.com web; en map).
  - Asegúrate de que Certbot haya obtenido y renovado con éxito los certificados para mywebsite.com, y que Nginx HTTP utilice las rutas actualizadas a ellos.
MTProto no se conecta:
- Problema: El cliente de Telegram no puede conectarse al proxy.
- Solución:
  - Verifica que mtg-proxy esté funcionando y escuchando en 127.0.0.1:4433.
  - Asegúrate de que el secreto del proxy en el cliente de Telegram coincida con el secreto con el que se inició mtg-proxy.
  - Verifica que Nginx Stream esté enrutando correctamente el tráfico por defecto (o por nombre SNI para el proxy) a mtproto_backend (default mtproto;).
  - Asegúrate de que no haya firewalls (por ejemplo, UFW) bloqueando las conexiones entrantes al puerto 443 o las salientes a los puertos locales.
Errores "bind: Address already in use":
- Problema: Al iniciar Nginx o SNIProxy, ves un error que indica que el puerto 443 ya está en uso.
- Solución: Solo un proceso puede escuchar en la interfaz externa en el puerto 443. Asegúrate de que solo Nginx Stream O SNIProxy estén funcionando. Si cambias entre ellos, detén el servicio anterior antes de iniciar el nuevo. También asegúrate de que tu servidor web (Nginx HTTP) escuche solo en la interfaz local (127.0.0.1:8443), y no en 0.0.0.0:443.

Elección rápida

¿Buscas un servidor que simplemente funcione?

Valebyte VPS: NVMe, soporte 24/7, despliegue en 60 segundos.

Ver planes VPS

Optimización y seguridad: cómo elegir un VPS para proxy y web

La elección del VPS adecuado para alojar simultáneamente un proxy MTProto y un sitio web es fundamental para el rendimiento y la fiabilidad. Valebyte.com ofrece diversas tarifas que pueden adaptarse a esta tarea.

Requisitos de recursos para una carga combinada

La carga en el VPS dependerá del número de usuarios simultáneos de MTProto proxy y del tráfico de tu sitio web. A continuación, se presenta una tabla orientativa de requisitos de recursos:

Para 50 conexiones MTProto simultáneas y un tráfico web moderado, son suficientes 4 vCPU, 8 GB de RAM y un disco NVMe de 80 GB.

Usuarios MTProto simultáneos	vCPU	RAM (GB)	Disco (GB, tipo)	Puerto de red	Precio estimado Valebyte.com ($/mes, 2024)
Hasta 10	1-2	2-4	40-60 NVMe/SSD	1 Gbps	Desde 5.99$
10-50	2-4	4-8	60-80 NVMe/SSD	1 Gbps	Desde 9.99$
50-150	4-6	8-16	80-160 NVMe	1-10 Gbps	Desde 19.99$
150-300+	6-8+	16-32+	160-320+ NVMe	10 Gbps	Desde 39.99$

Notas importantes:

CPU: El proxy MTProto y Nginx (especialmente con SSL) pueden consumir mucha CPU. Elige un VPS con un número suficiente de núcleos.
RAM: Nginx, los servidores web (PHP-FPM, aplicaciones Python) y el propio MTProto consumen RAM. 4 GB es un buen comienzo, pero para una mayor carga se necesitará más.
Disco: Los discos NVMe son significativamente más rápidos que los SSD, lo cual es crítico para la velocidad de carga del sitio web y la capacidad de respuesta general del sistema. Para MTProto, el disco en sí no es tan importante, pero para el servidor web, sí lo es.
Red: Un puerto de red de alta velocidad (1 Gbps o 10 Gbps) con tráfico ilimitado o un límite alto es necesario para el proxy, ya que los usuarios lo utilizarán activamente.

Aumento de la seguridad de tu configuración

La seguridad de un servidor VPS combinado requiere una atención especial:

Firewall (UFW/iptables): Configura UFW o iptables para permitir solo los puertos necesarios. Permite las conexiones entrantes solo en el 443 (para Nginx/SNIProxy) y el 22 (para SSH, pero mejor con restricción por IP).
```
sudo ufw default deny incoming
        sudo ufw default allow outgoing
        sudo ufw allow 22/tcp # Solo para tu IP, si es posible
        sudo ufw allow 443/tcp
        sudo ufw enable
        
```
Uso de puertos locales: Asegúrate de que MTProto y el servidor web escuchen solo en 127.0.0.1. Esto evita el acceso directo a ellos desde el exterior, obligando a todo el tráfico a pasar por el proxy frontend.
Actualización de software: Actualiza regularmente el sistema operativo y todo el software instalado (Nginx, Certbot, mtg-proxy) para obtener las últimas correcciones de seguridad.
Contraseñas seguras y claves SSH: Utiliza contraseñas complejas y, si es posible, solo claves SSH para acceder al servidor. Deshabilita el inicio de sesión con contraseña para root.
Fail2ban: Instala y configura Fail2ban para proteger SSH de ataques de fuerza bruta.
SSL/TLS: Mantén los certificados SSL de tu sitio web actualizados y utiliza protocolos TLS modernos (TLSv1.2, TLSv1.3) con cifrados fuertes.

Preguntas frecuentes

Aquí encontrarás respuestas a las preguntas más comunes sobre la operación conjunta de MTProto y un sitio web en un mismo VPS a través del puerto 443.

¿Se puede usar Nginx Stream para otros protocolos además de MTProto?

Sí, Nginx Stream es muy flexible. Puede enrutar cualquier tráfico TCP/UDP basándose en diversos criterios, incluyendo SNI para TLS, o simplemente por dirección IP/puerto. Por ejemplo, puedes configurarlo para enrutar tráfico a otros servicios VPN (como OpenVPN, WireGuard), servidores de juegos o bases de datos, siempre que utilicen TLS y transmitan SNI. Lo principal es que Nginx Stream pueda determinar a dónde redirigir el tráfico sin descifrarlo por completo.

¿Cómo actualizar los certificados SSL de Let's Encrypt si el puerto 443 está ocupado por Nginx Stream?

Si el puerto 443 está constantemente ocupado por Nginx Stream, Certbot no podrá usar el método --nginx o --standalone para la validación. La mejor manera es usar el método --webroot. Para ello, asegúrate de que tu servidor web Nginx (que escucha en el puerto 80 para redirigir HTTP a HTTPS) tenga acceso al directorio que Certbot utiliza para archivos temporales (por ejemplo, /var/www/mywebsite.com para .well-known/acme-challenge/). Ejecuta Certbot con el comando: sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com. Después de la actualización, Certbot reiniciará automáticamente Nginx para aplicar los nuevos certificados.

¿Afectará el funcionamiento de MTProto al rendimiento de mi sitio web?

Sí, cualquier carga adicional en el VPS afectará al rendimiento. El proxy MTProto, especialmente con un gran número de usuarios activos (más de 50-100), puede consumir importantes recursos de CPU y ancho de banda de red. Tu sitio web también consumirá CPU y RAM. Es importante elegir correctamente un plan de VPS con suficiente vCPU (a partir de 4 núcleos), RAM (a partir de 8 GB) y un disco NVMe de alta velocidad. Monitoriza regularmente el uso de recursos (CPU, RAM, red) con herramientas como htop, iftop o Grafana/Prometheus, para escalar el VPS a tiempo si es necesario.

¿Se necesita un certificado SSL para el proxy MTProto?

El proxy MTProto en sí no requiere un certificado SSL en el sentido tradicional de TLS, ya que utiliza su propio protocolo de cifrado. Sin embargo, para aumentar el enmascaramiento y evitar bloqueos, algunas implementaciones de MTProto (por ejemplo, mtg) admiten el llamado "fake TLS" o "TLS-wrap", que permite a MTProto imitar el handshake TLS de un sitio web real, utilizando su certificado. Esto hace que el tráfico MTProto sea aún más indistinguible del HTTPS normal a nivel del handshake inicial. En nuestro esquema, Nginx Stream maneja el primer handshake TLS y enruta el tráfico, por lo que el backend de MTProto puede funcionar sin su propio certificado SSL.

¿Qué ventajas ofrece Valebyte.com para alojar esta configuración?

Valebyte.com ofrece potentes VPS con rápidos discos NVMe y canales de red de alta velocidad (hasta 10 Gbps), lo que es ideal para aplicaciones que consumen muchos recursos, como un proxy MTProto y un servidor web. Nuestras tarifas comienzan desde 5.99 $ al mes para una configuración suficiente para un proyecto pequeño, y se escalan fácilmente a soluciones más potentes con más de 8 vCPU y más de 32 GB de RAM para grandes cargas. Proporcionamos una infraestructura fiable que permite gestionar eficazmente el tráfico y garantizar el funcionamiento estable de tus servicios 24/7.

Conclusiones

El uso del enrutamiento SNI en el puerto 443 para alojar conjuntamente un proxy MTProto y un sitio web en un mismo VPS es una solución eficaz y económica para eludir bloqueos y optimizar la infraestructura. Nginx Stream con el módulo ssl_preread o SNIProxy permiten dividir el tráfico de forma elegante, dirigiéndolo a los backends locales correspondientes. Esta configuración no solo reduce los costes, sino que también aumenta el enmascaramiento de MTProto, haciendo que su tráfico sea indistinguible del HTTPS normal.

SSD NVMe

¿Listo para lanzar tu VPS?

VPS NVMe con activación en 60 segundos: acceso root completo, más de 20 ubicaciones, pago con tarjeta o criptomonedas.

Elegir plan