Configuración de SSTP y NaiveProxy

01 / SSTP

servidor SSTP

SSTP requiere un nombre de host público, TCP 443 u otro puerto TCP disponible, certificado TLS, autenticación PPP y configuración IPv4 en el servidor. Las implementaciones de estilo RouterOS, SoftEther y Windows RRAS son adecuadas si proporcionan un servicio SSTP compatible.

Ejemplo de estilo RouterOS

/ip pool
add name=your-pool ranges=10.20.30.10-10.20.30.200

/ppp profile
add name=sstp-profile \
    local-address=10.20.30.1 \
    remote-address=your-pool \
    dns-server=1.1.1.1,8.8.8.8 \
    use-encryption=yes

/ppp secret
add name=username password="strong-password" service=sstp profile=sstp-profile

/interface sstp-server server
set enabled=yes \
    port=443 \
    certificate=your-certificate-name \
    authentication=mschap2 \
    default-profile=sstp-profile

Enlace de conexión

sstp://username:strong-password@yourdomain.com:443?name=Office&cc=DE&label=Work

Si es posible, utilice un certificado TLS público válido.
Abra el puerto TCP SSTP en el firewall.
Cree credenciales únicas para cada usuario o dispositivo.
Deje que el servidor PPP proporcione parámetros IP y DNS si su esquema lo admite.
Utilice restricciones de RADIUS o del servidor nativo para límites de vencimiento, contabilidad y sesiones simultáneas.

02 / VERIFICAR

Lista de verificación de diagnóstico SSTP

Síntoma	Que comprobar
TLS se cierra inmediatamente	Cadena de certificados, SNI/nombre de host, firewall, política TLS no compatible o proxy antes de SSTP.
Error de autenticación	Nombre de usuario y contraseña, método de autenticación PPP, estado de la cuenta, fecha de vencimiento del secreto y respuesta RADIUS.
Conectado pero sin tráfico	Rutas, NAT/enmascaramiento, DNS, reglas de reenvío en el firewall y el grupo de IP del servidor.
Desconexión al cambiar de red	Política de tiempo de espera del servidor y comportamiento de reconexión del cliente: al cambiar la red Wi-Fi/móvil a iOS, es posible que se vuelva a crear la ruta.

03 / NAIVEPROXY

NaiveProxy con Caddy

Un esquema NaiveProxy común utiliza Caddy con un ensamblaje al que se agrega proxy directo. La parte importante es HTTP CONNECT autenticado a través de TLS. La compilación exacta de Caddy y la sintaxis del complemento puede variar, por lo que el patrón de implementación que se muestra a continuación no es un copiado y pegado garantizado.

yourdomain.com {
    tls admin@yourdomain.com

    route {
        forward_proxy {
            basic_auth username strong-password
            hide_ip
            hide_via
            probe_resistance
        }

        respond 204
    }
}

naive+https://username:strong-password@yourdomain.com:443?sni=yourdomain.com&name=Office&cc=DE&label=Work

Esta opción suele elegirse para la finalización habitual de TLS en el proxy, certificados automáticos y autenticación básica simple.

04 / NAIVEPROXY

NaiveProxy con sing-box

Otra opción es ejecutar sing-box directamente desde Naive inbound. Esto es conveniente cuando un binario debe poseer tanto el escucha proxy como la lógica de enrutamiento.

{
  "log": { "level": "warn" },
  "inbounds": [
    {
      "type": "naive",
      "tag": "naive-in",
      "listen": "0.0.0.0",
      "listen_port": 443,
      "users": [
        { "username": "username", "password": "strong-password" }
      ],
      "tls": {
        "enabled": true,
        "server_name": "yourdomain.com",
        "certificate_path": "/etc/letsencrypt/live/yourdomain.com/fullchain.pem",
        "key_path": "/etc/letsencrypt/live/yourdomain.com/privkey.pem"
      }
    }
  ],
  "outbounds": [
    { "type": "direct", "tag": "direct" }
  ],
  "route": { "final": "direct" }
}

[Unit]
Description=sing-box naive proxy
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/sing-box run -c /etc/sing-box/config.json
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

05 / EXPANSIÓN

UDP sobre TCP para NaiveProxy

NaiveProxy está principalmente orientado a TCP. Si los usuarios necesitan tráfico similar a UDP a través de un perfil Naive, MONO VPN puede enrutar transmisiones UDP a un oyente TCP Naive separado. Agregar uot al enlace y ejecute un oyente compatible en ese puerto.

naive+https://username:strong-password@yourdomain.com:443?sni=yourdomain.com&uot=8443

{
  "log": { "level": "warn" },
  "inbounds": [
    {
      "type": "naive",
      "tag": "naive-uot-in",
      "listen": "0.0.0.0",
      "listen_port": 8443,
      "users": [
        { "username": "username", "password": "strong-password" }
      ],
      "tls": {
        "enabled": true,
        "server_name": "yourdomain.com",
        "certificate_path": "/etc/letsencrypt/live/yourdomain.com/fullchain.pem",
        "key_path": "/etc/letsencrypt/live/yourdomain.com/privkey.pem"
      }
    }
  ],
  "outbounds": [
    { "type": "direct", "tag": "direct" }
  ],
  "route": { "final": "direct" }
}

Abra el puerto TCP UoT solo cuando utilice este modo. Si uot está ausente, MONO VPN utiliza la rama NaiveProxy normal para el tráfico TCP y no se necesita un oyente adicional.

06 / OPERACIONES

Seguridad y operación

No publique contraseñas reales, credenciales de root ni claves compartidas de larga duración.
Emita credenciales únicas para cada usuario o dispositivo.
Recupera y rota datos cuando un usuario se va, se filtra un enlace o el acceso expira.
Actualice Caddy, sing-box, RouterOS, SoftEther o la pila VPN que elija.
Limite los puertos de administración por fuente de IP y separe la administración de los puertos VPN/proxy.

ufw allow 443/tcp
ufw allow 443/udp
ufw allow 8443/tcp

Abra sólo los puertos que coincidan con su diseño. UDP 443 es opcional y depende del uso de QUIC/HTTP3. TCP 8443 solo es necesario para el ejemplo de UDP sobre TCP.