XRay en Google Cloud Run: evadiendo bloqueos de subredes

Desplegar XRay en Google Cloud Run para evadir bloqueos de subredes

Bloquear subredes enteras de proveedores facilita el DPI, pero genera daños colaterales masivos. En vez de detección sofisticada, los proveedores optan por prohibiciones generales en rangos /16 y /8, congelando conexiones tras 16 KB o eliminando TLS por completo. El análisis revela impactos en cientos de ASNs, bloqueando millones de IPs. Las soluciones incluyen desplegar en subredes no bloqueadas de grandes proveedores o usar domain fronting.

Realidad y alternativas simples

XTLS-Reality es excesivo sin sondas activas: VLESS con un certificado autofirmado y suplantación de dominio logra el mismo efecto. Funciona incluso con CDNs que admiten certificados personalizados. Para bloqueos de TLS, usa gRPC para VLESS o XHTTP con multiplexación.

Despliegue en Google Compute Engine

Lanza una instancia e2-micro (0.25 vCPU, 1 GB RAM) en Compute Engine:

• Elige la región más barata.
• Usa un disco estándar sin copias de seguridad.
• Permite tráfico HTTP/HTTPS.
• Quédate con IPv4 efímera.

Instala XRay y configura VLESS Enc con Reality Seed para frustrar el análisis de tamaño de paquetes. SNI google.com pasa sin problemas porque la IP pertenece al AS de Google.

Optimización de costos con Cloud Run: Contenedores a demanda

Pasa a serverless con Cloud Run para reducir gastos:

• Ve a Cloud Run > Servicios > Desplegar servicio web.
• Imagen: docker.io/teddysun/xray.
• Región: Tier 1, la más cercana.
• Puerto del contenedor: 8080.
• Recursos: 128 MB RAM, 1 CPU (mínimo para >1 conexión).
• Escalado: 0–1 instancia, facturación por solicitud.
• Ingress: todo, timeout 3600s, concurrencia 100+.

Montar la configuración

Crea un secreto en Secret Manager con tu config.json y móntalo como /etc/xray/config.json.

Configuración de muestra para XHTTP (sniffing desactivado):

{
  "log": {
    "loglevel": "info"
  },
  "inbounds": [
    {
      "port": 8080,
      "protocol": "vless",
      "tag": "pxy",
      "settings": {
        "clients": [
          {
            "id": "4c3fe585-ac09-41df-b284-70d3fbe27773",
            "email": "user1"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/secreturlxx"
        }
      },
      "sniffing": {
        "enabled": false
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

En el cliente: XHTTP con XMUX (maxConnections=1, maxConcurrency=0). El arranque del contenedor toma 1–2 segundos.

Domain Fronting en la infraestructura de Google

Conectar a google.com resuelve a una IP de Google, pero Host apunta a tu *.run.app: las solicitudes se enrutan internamente dentro del AS. Los certificados se emiten correctamente para cualquier servicio de Google (HTTPS/QUIC). No es suplantación como Reality: el tráfico fluye por la infraestructura real de Google.

La config del cliente usa server=google.com, SNI=google.com, Host=xxxxxxxxx.run.app.

Limitaciones y escalado

• Requiere tarjeta extranjera y verificación de residencia.
• Costoso: opción de emergencia para 1–2 usuarios.
• Prueba: $200 por 3 meses.

Para cargas >1 conexión, despliega un proxy como praveenkarunarathne/Google-Cloud-Run-Proxy con env V2RAY_SERVER_IP=tu_VPS.

| Parámetro | Compute Engine | Cloud Run |

|-----------|----------------|-----------|

| Arranque | Siempre activo | A demanda (0–1 instancia) |

| Precio | Fijo/hora | Por solicitud |

| Escalado | Manual | Automático |

| Latencia | Baja | 1–2s |

Conclusiones clave

• Bloqueos de subredes /16–/8 afectan >225 millones de IPs: evítalos vía AS de Google.
• XHTTP en Cloud Run se lleva bien con balanceadores de carga; Reality Seed protege paquetes.
• Domain fronting enruta por infra de Google sin bloqueos.
• Recursos mínimos: 128 MB/1 CPU para unos pocos clientes.
• Config en Secret Manager, sniffing apagado para velocidad.

— Editorial Team