Come attivare l'accesso di emergenza
Configura l'accesso di emergenza (OLCRTC) per i tuoi utenti: abbonamento Pro, una route di emergenza, l'interruttore del cluster 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 è sperimentale e 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 dell'email. 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;
- l'interruttore OLCRTC attivato sul cluster;
- almeno un server di quel cluster con il runtime attivato;
- utenti con email verificata e account attivo (vedi la sezione sui limiti più sotto).
Ordine delle operazioni
Gli interruttori sono tre, in tre punti diversi, ed è facile confonderli: due di essi si chiamano quasi allo stesso modo.
| Cosa attivi | Dove si trova | Come si chiama |
|---|---|---|
| Route | impostazioni della route (in modifica) | «Route di emergenza (OLCRTC)» |
| Cluster | pagina del cluster, sopra l'elenco delle route | «Abilita OLCRTC per questo cluster» |
| Server | pannello del server, pulsante «Modifica» | «Esegui OLCRTC su questo server» |
L'ordine conta: il cluster non ti lascerà abilitare OLCRTC finché non c'è nessuna route di emergenza. Prima la route, poi il cluster.
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, nel blocco «Accesso di emergenza (OLCRTC)», 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 nell'elenco delle route.
Abilita OLCRTC per l'intero cluster. Questo è un secondo interruttore, separato, non quello della route. Si trova nella pagina del cluster, nel blocco «Accesso di emergenza» con l'etichetta OLCRTC, subito sopra l'elenco delle route, e si chiama «Abilita OLCRTC per questo cluster».
È l'interruttore principale: finché è disattivato, gli utenti del cluster non possono richiedere nulla, per quante route tu abbia contrassegnato come di emergenza. Sotto l'interruttore vedi quante route di emergenza ci sono già nel pool.
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 (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 invia un'email nuova.
Una sessione per utente. Una seconda email non crea nulla e non riceve risposta: conviene spiegarlo agli utenti in anticipo, perché non sembri un guasto.
Circa 14 Mbit/s in download e meno di un megabit in upload, con 175–235 ms di latenza. Guardare video e gestire la posta è comodo; inviare file grandi, fare videochiamate e giocare, no. È il tetto della configurazione attuale del tunnel, non quello della connessione principale.
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 la frequenza è limitata a cinque richieste all'ora per utente e cento per l'intero servizio.
I rifiuti a questi controlli avvengono in silenzio: l'utente non riceve alcuna risposta. Se qualcuno si lamenta dicendo «ho inviato l'email e non è arrivato niente», parti dallo stato dell'account e dal fatto che sia stato inviato il link di chiamata giusto.
Le route multi-hop non partecipano. Per le sessioni di emergenza si usano solo route dirette.
iPhone è più complicato. Il client iOS si può installare solo tramite sideload: Apple non lo distribuisce. I tuoi utenti con iPhone devono prepararsi in anticipo e con più attenzione; la guida all'installazione lo spiega.
Come disattivarlo
Puoi togliere Abilita OLCRTC per questo cluster in qualsiasi momento: smetteranno di avviarsi nuove sessioni. Quelle già in corso completano il loro periodo.
L'ultima route di emergenza non si può togliere né eliminare finché OLCRTC è attivo: contrassegna prima un'altra route, oppure disattiva OLCRTC sul cluster.
Se il tuo abbonamento Pro è terminato, puoi comunque disattivare tutto, ma per riattivarlo dovrai rinnovarlo.