Cómo activar el acceso de emergencia
Configura el acceso de emergencia (OLCRTC) para tus usuarios: suscripción Pro, una ruta de emergencia, el interruptor del clúster 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 es experimental y 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 y el correo sean accesibles. 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;
- el interruptor de OLCRTC activado en el clúster;
- al menos un servidor de ese clúster 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 tres interruptores, en tres sitios distintos, y es fácil confundirlos: dos de ellos se llaman casi igual.
| Qué activas | Dónde está | Cómo se llama |
|---|---|---|
| Ruta | ajustes de la ruta (al editarla) | «Ruta de emergencia (OLCRTC)» |
| Clúster | página del clúster, encima de la lista de rutas | «Activar OLCRTC para este clúster» |
| Servidor | panel del servidor, botón «Editar» | «Ejecutar OLCRTC en este servidor» |
El orden importa: el clúster no te dejará activar OLCRTC mientras no haya ninguna ruta de emergencia. Primero la ruta, después el clúster.
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, en el bloque «Acceso de emergencia (OLCRTC)», 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 en la lista de rutas.
Activa OLCRTC para todo el clúster. Este es un segundo interruptor, distinto, no el de la ruta. Está en la página del clúster, en el bloque «Acceso de emergencia» marcado con OLCRTC, justo encima de la lista de rutas, y se llama «Activar OLCRTC para este clúster».
Es el interruptor principal: mientras esté desactivado, los usuarios del clúster no podrán solicitar nada, por muchas rutas que hayas marcado como de emergencia. Debajo del interruptor puedes ver cuántas rutas de emergencia hay ya en el grupo.
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 (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 envía un correo nuevo.
Una sesión por usuario. Un segundo correo no crea nada y no recibe respuesta; conviene explicárselo a los usuarios de antemano para que no parezca una avería.
Unos 14 Mbit/s de bajada y menos de un megabit de subida, con 175–235 ms de latencia. Ver vídeo y trabajar con el correo es cómodo; enviar archivos grandes, hacer videollamadas y jugar, no. Ese es el techo de la configuración actual del túnel, no el de la conexión principal.
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 la frecuencia está limitada a cinco solicitudes por hora y usuario, y cien para todo el servicio.
Los rechazos en estas comprobaciones son silenciosos: el usuario no recibe ninguna respuesta. Si alguien se queja de que «envié el correo y no llegó nada», empieza por el estado de la cuenta y por si envió el enlace de llamada correcto.
Las rutas multisalto no participan. Para las sesiones de emergencia solo se usan rutas directas.
El iPhone es más difícil. El cliente de iOS solo se puede instalar por sideload, porque Apple no lo distribuye. Tus usuarios con iPhone tienen que prepararse con antelación y con más cuidado; la guía de instalación lo explica.
Cómo desactivarlo
Puedes quitar Activar OLCRTC para este clúster en cualquier momento: dejarán de iniciarse sesiones nuevas. Las que ya están en marcha terminan su plazo.
La última ruta de emergencia no se puede desmarcar ni eliminar mientras OLCRTC esté activo: marca antes otra ruta, o desactiva OLCRTC en el clúster.
Si tu suscripción Pro ha caducado, todavía puedes desactivarlo todo, pero volver a activarlo requiere renovarla.