Cómo activar el acceso de emergencia
Configura el acceso de emergencia (OLCRTC) para tus usuarios: suscripción Pro, una ruta de emergencia y el runtime por servidor, paso a paso y en el orden correcto.
Esta página es para ti, el propietario del servicio. Explica cómo activar el acceso de emergencia para que tus usuarios puedan contar con él. Para los usuarios hay páginas aparte: Acceso de emergencia — cómo funciona y qué hacer durante un bloqueo — e Instalación del cliente de emergencia — dónde descargar la aplicación y cómo instalarla.
El acceso de emergencia (OLCRTC) es un canal de reserva para redes con listas blancas donde la conexión normal no pasa en absoluto. El tráfico sigue circulando por tus propios servidores, pero disfrazado de videollamada en un servicio permitido. No es un segundo protocolo ni un sustituto del principal: es más lento, está pensado para sesiones cortas, lo inicia el usuario manualmente y solo cuando todo lo demás ha dejado de funcionar.
La función se despliega por etapas. Aunque tengas todos los interruptores activados, puede que el runtime de emergencia aún no esté instalado en tus servidores y que el arranque de sesiones todavía no esté activo: el acceso se abre de forma gradual. Si un servidor tarda mucho en llegar a «en buen estado» después de activarlo, lo más probable es que el despliegue simplemente aún no haya llegado hasta ti.
Tampoco funciona en todas las redes ni en todos los países, y depende de que un servicio de vídeo externo sea accesible (y, para la vía del correo, también de que el correo llegue). No lo prometas como una capacidad garantizada: preséntalo como un seguro frente a bloqueos duros.
Qué necesitas
- una suscripción Pro (o Max, que incluye todo lo de Pro);
- al menos una ruta marcada como de emergencia;
- al menos un servidor de una ruta de emergencia con el runtime activado;
- usuarios con correo verificado y una cuenta activa (ver la sección de límites más abajo).
Orden de las operaciones
Hay dos interruptores, en dos sitios distintos.
| Qué activas | Dónde está | Cómo se llama |
|---|---|---|
| Ruta | ajustes de la ruta (al editarla) | «Ruta de emergencia (OLCRTC)» |
| Servidor | panel del servidor, botón «Editar» | «Ejecutar OLCRTC en este servidor» |
El clúster no tiene un interruptor propio: el acceso de emergencia del clúster está activado mientras al menos una de sus rutas esté marcada.
Con tu primera suscripción Pro el sistema marca por ti como de emergencia la ruta con más inbounds en funcionamiento, y el acceso de emergencia del clúster se activa enseguida. Los servidores participan por defecto y el runtime se despliega solo. Por eso, la mayoría de las veces los pasos de abajo son una comprobación y no una secuencia obligatoria: recórrelos si quieres elegir otras rutas, fijar una capacidad o dejar fuera un servidor concreto.
Contrata Pro. Ve a Facturación → bloque de suscripción. Sin un Pro activo, los interruptores de emergencia no se muestran siquiera: en su lugar, la página del clúster muestra una tarjeta «Acceso de emergencia (OLCRTC)» con un botón «Mejorar plan».
Marca una ruta como de emergencia, en los ajustes de la propia ruta. Abre la ruta para editarla y activa «Ruta de emergencia (OLCRTC)».
El interruptor solo aparece al editar una ruta existente. El formulario de creación de rutas no lo tiene: crea primero la ruta y luego abre sus ajustes y márcala como de emergencia.
Los servidores de esa ruta entran en el grupo de emergencia. Puedes marcar varias rutas: el grupo las une todas y, si una ruta no tiene ningún servidor adecuado, la conexión va a un servidor de otra. Las rutas marcadas reciben una etiqueta emergencia (OLCRTC) en la lista de rutas.
En cuanto marcas la primera ruta, el acceso de emergencia del clúster se activa solo: no hay que activar nada más.
Permite las sesiones en los servidores. Haz clic en un servidor para abrir su panel, busca el bloque Runtime de emergencia (OLCRTC), pulsa «Editar», activa «Ejecutar OLCRTC en este servidor» y pulsa «Guardar».
El runtime se instala y se actualiza solo, en segundo plano: no hace falta entrar en el servidor. Hasta que esté instalado e informe, el estado se muestra como «en mal estado»; es normal, espera a «en buen estado · N/M activas».
El bloque solo aparece en el modo de interfaz normal: el modo simplificado Single no lo tiene.
Define la capacidad. En el mismo bloque: Máx. de sesiones simultáneas. Puedes dejarlo vacío, pero es mejor no hacerlo: mira la sección siguiente.
Cuéntaselo a tus usuarios. El acceso de emergencia no sirve de nada si la gente se entera cuando ya está bloqueada: el cliente hay que instalarlo con antelación. Envíalos a Acceso de emergencia y a Instalación del cliente, y pídeles que recorran el proceso una vez mientras internet todavía funciona con normalidad.
Cuántas sesiones aguanta un servidor
Una sesión de emergencia no es «un usuario de VPN más»: sale bastante más cara, porque el servidor empaqueta el tráfico dentro de un flujo de vídeo, y eso cuesta tiempo de CPU.
Medido en una sesión real (vídeo Full HD, unos 5 Mbit/s), una sesión ocupa aproximadamente el 15 % de un núcleo y 31 MB de memoria. La memoria apenas importa; el límite real es la CPU.
| Núcleos del servidor | Capacidad razonable |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
No subas de estas cifras ni siquiera en un servidor dedicado: cuatro sesiones en un solo núcleo ya son alrededor del 60 % del mismo, más la carga de fondo. Y ten en cuenta que la medición se hizo viendo vídeo (~5 Mbit/s); si un usuario satura el túnel, una sesión puede costar bastante más.
Un campo de capacidad vacío significa «sin límite». La única protección que queda es la automatización que deja de colocar sesiones nuevas en un servidor muy sobrecargado. Pero reacciona con retraso y, en un servidor débil, para entonces tus usuarios normales ya estarán sufriendo. En servidores de un solo núcleo, define la capacidad de forma explícita.
El balanceo ayuda hasta cierto punto: si la ruta usa el algoritmo «Menor carga por tráfico» (el predeterminado), un servidor con alto uso de CPU informa de menos ancho de banda libre y los usuarios normales nuevos se dirigen a servidores menos cargados. Pero eso es una corrección basada en la CPU global, no en el número de sesiones de emergencia, y llega con varios minutos de retraso: no sustituye a una capacidad explícita.
Qué muestra la interfaz
En el bloque Runtime de emergencia (OLCRTC) de cada servidor:
- Función: si se pueden ejecutar sesiones en este servidor;
- Capacidad: tu límite de sesiones simultáneas («sin definir» = sin límite);
- Runtime: el estado, «en buen estado · N/M activas», «en mal estado» o «aún no informa».
Justo después de activarlo, espera «en mal estado»: es normal, el servidor todavía está instalando el runtime y aún no ha informado. Si se queda así mucho tiempo, comprueba que el servidor esté accesible en general. «Aún no informa» solo aparece un instante mientras carga la página.
Límites que conviene conocer de antemano
Una sesión vive hasta 12 horas y luego se detiene sola. No se puede prolongar: el usuario crea una llamada nueva y vuelve a solicitar la conexión.
Una sesión por usuario. Una segunda solicitud no crea una segunda sesión: en el área personal aparece «La sesión ya está activa» y un segundo correo se queda sin respuesta; conviene explicárselo a los usuarios de antemano para que no parezca una avería.
La velocidad de internet es menor que con una conexión por Xray.
El servicio de vídeo debe ser accesible desde el país del servidor. Quien entra en la llamada es tu servidor, así que lo que cuenta es dónde está el servidor, no dónde está el usuario. Por ejemplo, en Letonia Yandex y Wildberries están bloqueados: a través de un servidor letón, Telemost y WB Stream no se levantarán. Tenlo en cuenta al elegir en qué servidores activas el acceso de emergencia.
Los requisitos para los usuarios son más estrictos de lo que parecen. Hace falta un correo verificado: los usuarios que creaste manualmente sin correo no pueden solicitar acceso. La cuenta también debe estar activa: se rechazan las cuentas en pausa, caducadas, con el límite agotado y a la espera del primer pago (on_hold, es decir, todos los que se registraron por su cuenta y aún no han pagado). El correo debe superar la comprobación de autenticidad del remitente y contener solo el enlace de la llamada.
En el área personal cada rechazo se muestra con su motivo; a un correo se responde siempre que podamos reconocer al remitente como usuario tuyo (un remitente no autenticado o desconocido no recibe respuesta). Si alguien se queja de que «lo solicité y no pasó nada», empieza por el estado de la cuenta y por el enlace de llamada que usó; para la vía del correo, comprueba también que lo envió desde la dirección de su cuenta y que el mensaje solo contenía el enlace.
Las rutas multisalto no participan. Para las sesiones de emergencia solo se usan rutas directas.
El cliente de emergencia es Ghostlane, iPhone incluido. Está en el App Store y en Google Play, y tiene versiones para Windows, macOS y Linux. Los usuarios que instalaron el antiguo olcbox tienen que cambiarse a Ghostlane: olcbox ya no se actualiza, no conoce SaluteJazz ni VK Calls y sus versiones antiguas carecen del cifrado nuevo. Más detalles en la guía de instalación.
Cómo desactivarlo
Desactiva «Ruta de emergencia (OLCRTC)» en todas las rutas de emergencia del clúster, o elimina esas rutas: el acceso de emergencia del clúster se desactiva y dejarán de iniciarse sesiones nuevas. Las que ya están en marcha terminan su plazo.
Si tu suscripción Pro ha caducado, todavía puedes desactivarlo todo, pero volver a activarlo requiere renovarla.