CreateYourVPN Academy
Curso: cómo funciona todo

Acceso de emergencia: cuando la red lo bloquea todo

El acceso de emergencia (OLCRTC) en CreateYourVPN: un canal de reserva disfrazado de videollamada para redes con listas blancas — qué le cuesta a tus servidores, qué se activa solo con Pro y qué contarles a tus usuarios por adelantado.

Todo lo anterior daba por hecho una cosa: que la red sigue dejando pasar a tus servidores. Una ruta elige un servidor, un inbound hace que la conexión parezca una visita HTTPS normal, el multisalto estira el camino por varios países — pero todo eso necesita que el tráfico llegue a salir del dispositivo.

Y no siempre sale. La red pasa a una lista blanca: funciona una lista corta de servicios permitidos y todo lo demás — tu VPN incluida — sencillamente no pasa. El acceso de emergencia (OLCRTC) está pensado exactamente para esas horas.

Qué es — y qué no es

El acceso de emergencia es un canal de reserva, no un segundo protocolo. La conexión normal sigue siendo la misma de siempre: VLESS + Reality sobre tus propios servidores. El acceso de emergencia reutiliza esos mismos servidores, pero envuelve el tráfico dentro de una videollamada en un servicio que la red restringida todavía permite — desde fuera parece una videoconferencia corriente.

De ahí salen tres consecuencias, y conviene conocer las tres antes de prometer nada:

  • Lo inicia el usuario a mano, solo cuando nada más funciona. No hay conmutación automática: la conexión normal no «salta» sola a la de emergencia.
  • Es lento. Unos 14 Mbit/s de bajada, menos de un megabit de subida, 175–235 ms de latencia. Cómodo para leer y ver vídeo, inútil para subir archivos, videollamadas y juegos.
  • Es temporal. Una sesión dura hasta 12 horas y se detiene sola; el usuario puede tener una a la vez; para continuar, inicia una nueva.

La función es experimental. Depende de que el servicio de vídeo externo sea accesible desde la red restringida, así que no funciona en todos los países ni en todas las redes. Preséntalo a tus usuarios como un seguro contra bloqueos duros, no como una capacidad garantizada.

Cómo se ve desde el lado del usuario

  1. Crea una videollamada nueva en un servicio compatible — Yandex Telemost, WB Stream o Jitsi Meet.
  2. Entrega su enlace: lo pega en el bloque Acceso de emergencia de su panel, o lo envía por correo a una dirección personal de solicitud. Ambas vías hacen lo mismo — y la del correo sigue funcionando cuando tu escaparate ya está bloqueado.
  3. Uno de tus servidores entra en esa llamada como invitado. Aproximadamente un minuto después el usuario recibe un enlace de conexión que empieza por olcrtc:// y un código QR.
  4. Lo importa en olcbox, el cliente de emergencia, y se conecta.

Las dos cosas que el usuario necesita — la aplicación y la dirección de solicitud — tienen que estar en su poder antes del bloqueo. Bajo una lista blanca, las tiendas de aplicaciones y las páginas de descarga suelen estar inaccesibles, y el panel donde se muestra la dirección quizá tampoco abra. Quien se entera del acceso de emergencia durante el bloqueo se ha enterado tarde.

Qué hace falta por tu parte

  • Una suscripción Pro — 0,99 € al mes. Es el nivel con el que viene el acceso de emergencia; Max también lo incluye, junto con todo lo demás (lección 13).
  • Una ruta de emergencia. Los servidores de las rutas marcadas como de emergencia forman el grupo en el que aterrizan las sesiones. Con tu primera suscripción el sistema marca una por ti — la ruta con más inbounds en funcionamiento — y de paso sube el interruptor del clúster.
  • Los servidores. Participan por defecto, y el runtime se instala y se actualiza en segundo plano: no hay que entrar por SSH.

Es decir, en el caso habitual no hay nada que configurar: te suscribes y el acceso de emergencia funciona. Los interruptores manuales están ahí para cuando los necesites: qué rutas componen el grupo, cuántas sesiones aguanta cada servidor y si conviene dejar alguno fuera.

En qué se diferencia de una ruta normal

  • El usuario no elige país. Ni siquiera ve el grupo — la intención geográfica la expresas tú marcando qué rutas son de emergencia. Puedes marcar varias: el grupo las une, y si en una no hay servidor adecuado, la sesión se va a otra.
  • Las rutas multisalto no participan. Para las sesiones de emergencia solo se usan rutas directas.
  • Una sesión cuesta CPU de verdad. Empaquetar el tráfico en un flujo de vídeo consumió en la medición cerca del 15% de un núcleo y 31 MB de memoria (sesión de vídeo a ~5 Mbit/s) — mucho más que un usuario de VPN adicional. La referencia son 3 sesiones por núcleo: 3 en un servidor de un núcleo, 6–7 con dos, 12–14 con cuatro.

El campo «Máx. sesiones simultáneas» vacío significa sin límite. En un servidor flojo eso es una trampa: las sesiones de emergencia se comerán la CPU que te pagan tus clientes normales. En máquinas de un solo núcleo pon el número de forma explícita.

Cuáles de tus usuarios podrán usarlo

Los requisitos son más estrictos de lo que parecen — y de ahí salen las preguntas al soporte:

  • Correo verificado. Los usuarios que creaste a mano sin dirección de correo no podrán solicitarlo en absoluto.
  • Cuenta activa. Las cuentas pausadas, caducadas, con el límite de tráfico agotado y a la espera del primer pago (todos los que se registraron solos y aún no han pagado) reciben un rechazo.

La queja que oirás suena así: «lo pedí y no pasó nada». Empieza por el estado de la cuenta y el enlace de la llamada; para la vía del correo, comprueba que lo envió desde la dirección de su cuenta y que el mensaje solo llevaba el enlace.

Para recordar

  • El acceso de emergencia es un salvavidas para redes con listas blancas, no un segundo protocolo ni un sustituto de la conexión normal.
  • El tráfico va por tus propios servidores, disfrazado de una videollamada que crea el propio usuario.
  • Lento, hasta 12 horas, una sesión por usuario, arranque manual.
  • Con Pro se activa solo: una ruta queda marcada como de emergencia, el interruptor del clúster sube y los servidores participan por defecto.
  • Una sesión ≈ 15% de un núcleo de CPU — en servidores flojos fija la capacidad de forma explícita.
  • El usuario necesita correo verificado, cuenta activa y el cliente instalado con antelación.

Siguiente

El acceso de emergencia trata de qué hacer cuando se rompe la red. La siguiente lección va de la otra mitad: cómo nota el sistema que se han roto tus servidores.

On this page