Come attivare l'accesso di emergenza
Configura l'accesso di emergenza (OLCRTC) per i tuoi utenti: abbonamento Pro, una route di emergenza e il runtime sui singoli server — passo dopo passo, nell'ordine giusto.
Questa pagina è per te, titolare del servizio. Spiega come attivare l'accesso di emergenza perché i tuoi utenti possano contarci. Per gli utenti stessi ci sono pagine separate: Accesso di emergenza — come funziona e cosa fare durante un blocco — e Installazione del client di emergenza — dove scaricare l'app e come installarla.
L'accesso di emergenza (OLCRTC) è un canale di riserva per le reti con liste di consentiti, dove la connessione normale non passa affatto. Il traffico continua a passare per i tuoi server, ma è mascherato da videochiamata su un servizio permesso. Non è un secondo protocollo né un sostituto di quello principale: è più lento, pensato per sessioni brevi, avviato manualmente dall'utente e solo quando tutto il resto ha smesso di funzionare.
La funzione viene distribuita per fasi. Anche con tutti gli interruttori attivati, il runtime di emergenza potrebbe non essere ancora installato sui tuoi server e l'avvio delle sessioni potrebbe non essere ancora attivo: l'accesso si apre gradualmente. Se dopo l'attivazione un server resta a lungo lontano dallo stato «integro», con ogni probabilità la distribuzione semplicemente non è ancora arrivata da te.
Inoltre non funziona su tutte le reti né in tutti i Paesi e dipende dalla raggiungibilità di un servizio video esterno (e, per la via email, dal fatto che la posta arrivi). Non prometterla come una possibilità garantita: presentala come un'assicurazione contro i blocchi più duri.
Cosa serve
- un abbonamento Pro (oppure Max, che include tutto ciò che c'è in Pro);
- almeno una route contrassegnata come di emergenza;
- almeno un server di una route di emergenza con il runtime attivato;
- utenti con email verificata e account attivo (vedi la sezione sui limiti più sotto).
Ordine delle operazioni
Gli interruttori sono due, in due punti diversi:
| Cosa attivi | Dove si trova | Come si chiama |
|---|---|---|
| Route | impostazioni della route (in modifica) | «Route di emergenza (OLCRTC)» |
| Server | pannello del server, pulsante «Modifica» | «Esegui OLCRTC su questo server» |
Il cluster non ha un interruttore proprio: l'accesso di emergenza del cluster è attivo finché almeno una delle sue route è contrassegnata come di emergenza.
Con il primo abbonamento Pro il sistema contrassegna per te come di emergenza la route con più inbound funzionanti, e l'accesso di emergenza del cluster si attiva subito. I server partecipano per impostazione predefinita e il runtime si distribuisce da solo. Per questo, nella maggior parte dei casi i passaggi qui sotto sono una verifica e non una sequenza obbligatoria: percorrili se vuoi scegliere altre route, impostare una capacità o escludere un server specifico.
Attiva Pro. Vai in Fatturazione → blocco dell'abbonamento. Senza un Pro attivo gli interruttori di emergenza non vengono nemmeno mostrati: al loro posto la pagina del cluster mostra una scheda «Accesso di emergenza (OLCRTC)» con il pulsante «Esegui upgrade».
Contrassegna una route come di emergenza, nelle impostazioni della route stessa. Apri la route in modifica e attiva «Route di emergenza (OLCRTC)».
L'interruttore compare solo in modifica di una route esistente. Il modulo di creazione di una nuova route non lo ha: crea prima la route, poi apri le sue impostazioni e contrassegnala come di emergenza.
I server di quella route entrano nel pool di emergenza. Puoi contrassegnare più route: il pool le unisce tutte e, se una route non ha server adatti, la connessione va a un server di un'altra. Le route contrassegnate ricevono l'etichetta emergenza (OLCRTC) nell'elenco delle route.
Appena viene contrassegnata la prima route, l'accesso di emergenza del cluster si attiva da solo: non c'è nient'altro da attivare.
Consenti le sessioni sui server. Fai clic su un server per aprirne il pannello, trova il blocco Runtime di emergenza (OLCRTC), premi «Modifica», attiva «Esegui OLCRTC su questo server» e premi «Salva».
Il runtime si installa e si aggiorna da solo, in background: non serve accedere al server. Finché non è installato e non invia i suoi dati, lo stato viene mostrato come «non integro»; è normale, aspetta «integro · N/M attive».
Il blocco compare solo nella modalità di interfaccia normale: nella modalità semplificata Single non c'è.
Imposta la capacità. Nello stesso blocco: Sessioni simultanee max. Puoi lasciarlo vuoto, ma è meglio di no: vedi la sezione successiva.
Informa i tuoi utenti. L'accesso di emergenza è inutile se le persone lo scoprono quando sono già bloccate: il client va installato in anticipo. Indirizzali a Accesso di emergenza e a Installazione del client e chiedi loro di percorrere tutto il processo una volta, mentre internet funziona ancora normalmente.
Quante sessioni regge un server
Una sessione di emergenza non è «un utente VPN in più»: costa parecchio di più, perché il server impacchetta il traffico dentro un flusso video, e questo consuma tempo di CPU.
Misurato su una sessione reale (video Full HD, circa 5 Mbit/s), una sessione occupa all'incirca il 15 % di un core e 31 MB di memoria. La memoria conta pochissimo; il limite vero è la CPU.
| Core sul server | Capacità ragionevole |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Non superare questi numeri nemmeno su un server dedicato: quattro sessioni su un solo core sono già circa il 60 % dello stesso, più il carico di fondo. E tieni presente che la misura è stata presa guardando un video (~5 Mbit/s); se un utente satura il tunnel, una sessione può costare sensibilmente di più.
Un campo capacità vuoto significa «nessun limite». L'unica protezione che resta è l'automatismo che smette di collocare nuove sessioni su un server molto sovraccarico. Reagisce però in ritardo e, su un server debole, a quel punto i tuoi utenti normali staranno già soffrendo. Sui server a singolo core imposta la capacità in modo esplicito.
Il bilanciamento aiuta fino a un certo punto: se la route usa l'algoritmo «Meno carico per traffico» (quello predefinito), un server con CPU molto occupata dichiara meno banda libera e i nuovi utenti normali vengono indirizzati su server meno carichi. Ma è una correzione basata sul carico complessivo della CPU, non sul conteggio delle sessioni di emergenza, e arriva con vari minuti di ritardo: non sostituisce una capacità esplicita.
Cosa mostra l'interfaccia
Nel blocco Runtime di emergenza (OLCRTC) di ogni server:
- Funzione: se su questo server possono girare sessioni;
- Capacità: il tuo limite di sessioni simultanee («non impostata» = nessun limite);
- Runtime: lo stato, «integro · N/M attive», «non integro» oppure «non ancora in reporting».
Subito dopo l'attivazione aspettati «non integro»: è normale, il server sta ancora installando il runtime e non ha ancora inviato dati. Se resta così a lungo, verifica che il server sia raggiungibile del tutto. «Non ancora in reporting» compare solo per un istante mentre la pagina si carica.
Limiti da conoscere fin da subito
Una sessione vive fino a 12 ore, poi si ferma da sola. Non si può prolungare: l'utente crea una chiamata nuova e richiede di nuovo la connessione.
Una sessione per utente. Una seconda richiesta non crea una seconda sessione: nell'area personale compare «la sessione è già attiva» e una seconda email resta senza risposta. Conviene spiegarlo agli utenti in anticipo, perché non sembri un guasto.
La velocità di internet è inferiore rispetto a una connessione tramite Xray.
Il servizio video deve essere raggiungibile dal paese del server. A entrare nella chiamata è il tuo server, quindi conta dove si trova il server, non dove si trova l'utente. In Lettonia, per esempio, Yandex e Wildberries sono bloccati: tramite un server lettone Telemost e WB Stream non si avvieranno. Tienilo presente quando scegli su quali server attivare l'accesso di emergenza.
I requisiti per gli utenti sono più severi di quanto sembri. Serve un'email verificata: gli utenti che hai creato manualmente senza email non possono richiedere l'accesso. L'account deve inoltre essere attivo: gli account in pausa, scaduti, con il limite esaurito e in attesa del primo pagamento (on_hold, cioè tutti quelli che si sono registrati da soli e non hanno ancora pagato) vengono rifiutati. L'email deve superare la verifica di autenticità del mittente e contenere solo il link di chiamata.
Nell'area personale ogni rifiuto viene mostrato con il suo motivo; via email la risposta parte quando possiamo riconoscere il mittente come un tuo utente (un mittente non autenticato o sconosciuto resta senza risposta). Se qualcuno si lamenta dicendo «ho fatto la richiesta e non è successo niente», parti dallo stato dell'account e dal link di chiamata usato; per la via email verifica anche che il messaggio sia partito dall'indirizzo dell'account e contenesse solo il link.
Le route multi-hop non partecipano. Per le sessioni di emergenza si usano solo route dirette.
Il client di emergenza è Ghostlane, anche per iPhone. È disponibile sull'App Store e su Google Play, con versioni per Windows, macOS e Linux. Chi aveva installato il vecchio olcbox deve passare a Ghostlane: olcbox non viene più aggiornato e non conosce né SaluteJazz né VK Calls, e alle sue versioni precedenti manca la nuova cifratura. Dettagli nella guida all'installazione.
Come disattivarlo
Disattiva «Route di emergenza (OLCRTC)» su tutte le route di emergenza del cluster, oppure elimina quelle route: l'accesso di emergenza del cluster si disattiva e smetteranno di avviarsi nuove sessioni. Quelle già in corso completano il loro periodo.
Se il tuo abbonamento Pro è terminato, puoi comunque disattivare tutto, ma per riattivarlo dovrai rinnovarlo.