Como ativar o acesso de emergência
Configure o acesso de emergência (OLCRTC) para os seus usuários: assinatura Pro, uma rota de emergência, o interruptor do cluster e o runtime por servidor — passo a passo, na ordem certa.
Esta página é para você, dono do serviço. Ela mostra como ativar o acesso de emergência para que os seus usuários possam contar com ele. Para os próprios usuários há páginas separadas: Acesso de emergência — como funciona e o que fazer durante um bloqueio — e Instalação do cliente de emergência — onde baixar o app e como instalá-lo.
Acesso de emergência (OLCRTC) é um canal reserva para redes com listas de permissão, onde a conexão normal simplesmente não passa. O tráfego continua indo pelos seus próprios servidores, mas é disfarçado de chamada de vídeo em um serviço permitido. Não é um segundo protocolo nem uma substituição do principal: é mais lento, feito para sessões curtas, iniciado manualmente pelo usuário e só para quando todo o resto parou de funcionar.
O recurso é experimental e está sendo liberado por etapas. Mesmo com todos os interruptores ligados, o runtime de emergência pode ainda não estar instalado nos seus servidores e o início de sessões pode não estar ativo: o acesso é aberto gradualmente. Se um servidor demorar muito para ficar "saudável" depois de você ativá-lo, o mais provável é que a liberação simplesmente ainda não tenha chegado até você.
Ele também não funciona em toda rede nem em todo país, e depende de um serviço de vídeo externo e do e-mail estarem acessíveis. Não prometa isso como um recurso garantido — apresente como um seguro contra bloqueios severos.
O que você precisa
- uma assinatura Pro (ou Max, que inclui tudo o que há no Pro);
- pelo menos uma rota marcada como de emergência;
- o interruptor OLCRTC ativado no cluster;
- pelo menos um servidor desse cluster com o runtime ativado;
- usuários com e-mail verificado e conta ativa (veja a seção de limites abaixo).
Ordem das operações
São três interruptores, em três lugares diferentes, e é fácil confundi-los — dois deles têm nomes quase idênticos:
| O que você ativa | Onde fica | Como se chama |
|---|---|---|
| Rota | configurações da rota (ao editar) | "Rota de emergência (OLCRTC)" |
| Cluster | página do cluster, acima da lista de rotas | "Ativar OLCRTC para este cluster" |
| Servidor | painel do servidor, botão "Editar" | "Executar OLCRTC neste servidor" |
A ordem importa: o cluster não deixa ativar o OLCRTC enquanto não houver nenhuma rota de emergência. Primeiro a rota, depois o cluster.
Assine o Pro. Vá em Faturamento → bloco de assinatura. Sem um Pro ativo, os interruptores de emergência nem aparecem: no lugar deles a página do cluster mostra um card "Acesso de emergência (OLCRTC)" com um botão "Fazer upgrade".
Marque uma rota como de emergência — nas configurações da própria rota. Abra a rota para edição e, no bloco "Acesso de emergência (OLCRTC)", ative "Rota de emergência (OLCRTC)".
O interruptor só aparece ao editar uma rota existente. O formulário de criação de rota não o tem: crie a rota primeiro, depois abra as configurações dela e marque-a como de emergência.
Os servidores dessa rota entram no conjunto de emergência. Você pode marcar várias rotas — o conjunto reúne todas elas e, se uma rota não tiver um servidor adequado, a conexão vai para um servidor de outra. As rotas marcadas ganham a etiqueta emergência na lista de rotas.
Ative o OLCRTC para o cluster inteiro. Este é um segundo interruptor, separado — não o da rota. Ele fica na página do cluster, no bloco "Acesso de emergência" marcado com OLCRTC, logo acima da lista de rotas, e se chama "Ativar OLCRTC para este cluster".
Este é o interruptor principal: enquanto ele estiver desligado, os usuários do cluster não podem solicitar nada, por mais rotas que você tenha marcado como de emergência. Abaixo do interruptor dá para ver quantas rotas de emergência já estão no conjunto.
Permita sessões nos servidores. Clique em um servidor para abrir o painel dele, encontre o bloco Runtime de emergência (OLCRTC), pressione "Editar", ative "Executar OLCRTC neste servidor" e pressione "Salvar".
O runtime se instala e se atualiza em segundo plano — não é preciso entrar no servidor. Até ele estar instalado e reportando, o estado aparece como "não saudável"; isso é normal, aguarde "saudável · N/M ativas".
O bloco só aparece no modo normal da interface — o modo simplificado Single não o tem.
Defina a capacidade. No mesmo bloco — Máx. de sessões simultâneas. Você pode deixar em branco, mas é melhor não deixar: veja a próxima seção.
Avise os seus usuários. O acesso de emergência é inútil se as pessoas souberem dele quando já estiverem bloqueadas: o cliente precisa ser instalado com antecedência. Aponte-os para Acesso de emergência e Instalação do cliente e peça que percorram o processo uma vez enquanto a internet ainda funciona normalmente.
Quantas sessões um servidor aguenta
Uma sessão de emergência não é "mais um usuário de VPN" — ela é bem mais cara: o servidor empacota o tráfego em um fluxo de vídeo, e isso custa tempo de processador.
Medido em uma sessão real (vídeo em Full HD, cerca de 5 Mbit/s), uma sessão consome aproximadamente 15% de um núcleo e 31 MB de memória. A memória quase não importa; o processador é o limite real.
| Núcleos no servidor | Capacidade sensata |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Não passe desses números nem em um servidor dedicado: quatro sessões em um único núcleo já são cerca de 60% dele, além da carga de fundo. E note que a medição foi feita assistindo a vídeo (~5 Mbit/s); se um usuário saturar o túnel, uma sessão pode custar bem mais.
Um campo de capacidade vazio significa "sem limite". A única proteção que resta é a automação que para de colocar novas sessões em um servidor muito sobrecarregado. Mas ela reage com atraso e, em um servidor fraco, os seus usuários comuns já estarão sofrendo até lá. Em servidores de um núcleo, defina a capacidade explicitamente.
O balanceamento ajuda até certo ponto: se a rota usa o algoritmo Menor carga de tráfego (o padrão), um servidor com uso alto de processador reporta menos banda livre e os novos usuários comuns são direcionados para servidores menos carregados. Mas isso é uma correção baseada no processador em geral, não uma contagem de sessões de emergência, e ela atrasa alguns minutos — não substitui uma capacidade explícita.
O que a interface mostra
No bloco Runtime de emergência (OLCRTC) de cada servidor:
- Função — se sessões podem rodar neste servidor;
- Capacidade — o seu limite de sessões simultâneas ("não definida" = sem limite);
- Runtime — estado: "saudável · N/M ativas", "não saudável" ou "ainda não reporta".
Logo depois de ativar, espere "não saudável" — isso é normal, o servidor ainda está instalando o runtime e não reportou. Se ficar assim por muito tempo, verifique se o servidor está acessível. "Ainda não reporta" só aparece por um instante enquanto a página carrega.
Limites que vale conhecer de antemão
Uma sessão vive até 12 horas e depois para sozinha. Não dá para estender — o usuário cria uma chamada nova e envia um novo e-mail.
Uma sessão por usuário. Um segundo e-mail não cria nada e não recebe resposta — vale explicar isso aos usuários de antemão, para que não pareça um defeito.
Cerca de 14 Mbit/s de download e menos de um megabit de upload, com 175–235 ms de latência. Assistir a vídeos e cuidar do e-mail é confortável; enviar arquivos grandes, fazer chamadas de vídeo e jogar, não. Esse é o teto da configuração atual do túnel, não da conexão principal.
Os requisitos para os usuários são mais rígidos do que parecem. É preciso um e-mail verificado — usuários que você criou manualmente sem e-mail não conseguem solicitar acesso. A conta também precisa estar ativa: contas pausadas, expiradas, com o limite esgotado e à espera do primeiro pagamento (on_hold — todos que se cadastraram sozinhos e ainda não pagaram) são recusadas. O e-mail precisa passar na autenticação do remetente, e a frequência é limitada a cinco solicitações por hora por usuário e cem para o serviço inteiro.
As recusas nessas verificações são silenciosas: o usuário não recebe resposta nenhuma. Se alguém reclamar que "mandei o e-mail e não voltou nada", comece pelo status da conta e por verificar se o link de chamada correto foi enviado.
Rotas multi-hop não participam. Só rotas diretas são usadas nas sessões de emergência.
iPhone é mais difícil. O cliente para iOS só pode ser instalado por sideload — a Apple não o distribui. Os seus usuários de iPhone precisam se preparar com antecedência e com mais cuidado; o guia de instalação explica isso.
Como desativar
Você pode desmarcar Ativar OLCRTC para este cluster a qualquer momento — novas sessões deixam de ser iniciadas. As sessões já em andamento cumprem o prazo delas.
A última rota de emergência não pode ser desmarcada nem excluída enquanto o OLCRTC estiver ligado: marque outra rota primeiro ou desative o OLCRTC no cluster.
Se a sua assinatura Pro venceu, você ainda consegue desligar tudo, mas religar exige renová-la.