Com activar l'accés d'emergència
Configura l'accés d'emergència (OLCRTC) per als teus usuaris: subscripció Pro, una ruta d'emergència i el runtime de cada servidor — pas a pas i en l'ordre correcte.
Aquesta pàgina és per a tu, el propietari del servei. Explica com activar l'accés d'emergència perquè els teus usuaris hi puguin comptar. Per als usuaris mateixos hi ha pàgines a part: Accés d'emergència — com funciona i què fer durant un bloqueig — i Instal·lació del client d'emergència — on descarregar l'aplicació i com instal·lar-la.
L'accés d'emergència (OLCRTC) és un canal alternatiu per a xarxes amb llistes blanques, on la connexió normal no passa de cap manera. El trànsit continua anant pels teus propis servidors, però es camufla com una videotrucada en un servei permès. No és un segon protocol ni un substitut del principal: és més lent, està pensat per a sessions curtes, l'engega l'usuari manualment i només per quan tota la resta ha deixat de funcionar.
La funció es desplega per fases. Fins i tot amb tots els interruptors activats, pot ser que el runtime d'emergència encara no estigui instal·lat als teus servidors i que l'inici de sessions encara no estigui actiu: l'accés s'obre de manera gradual. Si un servidor triga molt a arribar a «correcte» després que l'activis, el més probable és que el desplegament encara no t'hagi arribat.
Tampoc no funciona a totes les xarxes ni a tots els països, i depèn que un servei de vídeo extern sigui accessible (i, per a la via del correu, també que el correu arribi). No la prometis com una possibilitat garantida: presenta-la com una assegurança contra els bloquejos durs.
Què et caldrà
- una subscripció Pro (o Max, que inclou tot el que hi ha a Pro);
- com a mínim una ruta marcada com a d'emergència;
- com a mínim un servidor d'una ruta d'emergència amb el runtime activat;
- usuaris amb el correu verificat i un compte actiu (vegeu la secció de límits més avall).
Ordre de les operacions
Hi ha dos interruptors, en dos llocs diferents:
| Què actives | On es troba | Com es diu |
|---|---|---|
| Ruta | configuració de la ruta (en editar-la) | «Ruta d'emergència (OLCRTC)» |
| Servidor | panell del servidor, botó «Edita» | «Executa OLCRTC en aquest servidor» |
El clúster no té cap interruptor propi: l'accés d'emergència del clúster està activat mentre com a mínim una de les seves rutes estigui marcada.
Amb la teva primera subscripció Pro el sistema marca per tu com d'emergència la ruta amb més inbounds en funcionament, i l'accés d'emergència del clúster s'activa de seguida. Els servidors hi participen per defecte i el runtime es desplega sol. Per això, la majoria de vegades els passos de sota són una comprovació i no una seqüència obligatòria: recorre'ls si vols triar altres rutes, fixar una capacitat o deixar fora un servidor concret.
Contracta Pro. Ves a Facturació → bloc de la subscripció. Sense una Pro activa, els interruptors d'emergència ni tan sols es mostren: a la pàgina del clúster hi apareix una targeta «Accés d'emergència (OLCRTC)» amb un botó «Millora el pla».
Marca una ruta com a d'emergència, a la configuració de la ruta mateixa. Obre la ruta per editar-la i activa «Ruta d'emergència (OLCRTC)».
L'interruptor només apareix quan edites una ruta existent. El formulari de ruta nova no el té: crea primer la ruta i després obre'n la configuració i marca-la com a d'emergència.
Els servidors d'aquesta ruta s'afegeixen al grup d'emergència. Pots marcar diverses rutes: el grup les uneix totes i, si en una ruta no hi ha cap servidor adequat, la connexió va a un servidor d'una altra. Les rutes marcades reben una etiqueta emergència (OLCRTC) a la llista de rutes.
Tan bon punt marques la primera ruta, l'accés d'emergència del clúster s'activa sol: no cal activar res més.
Permet les sessions als servidors. Fes clic en un servidor per obrir-ne el panell, busca el bloc Runtime d'emergència (OLCRTC), prem «Edita», activa «Executa OLCRTC en aquest servidor» i prem «Desa».
El runtime s'instal·la i s'actualitza en segon pla: no cal que entris al servidor. Fins que no estigui instal·lat i informant, l'estat es mostra com a «no correcte»; és normal, espera fins a «correcte · N/M actives».
El bloc només apareix en el mode d'interfície habitual: el mode simplificat «Un servidor» no el té.
Defineix la capacitat. Al mateix bloc — «Màx. de sessions simultànies». El pots deixar buit, però val més que no ho facis: mira la secció següent.
Explica-ho als teus usuaris. L'accés d'emergència no serveix de res si la gent se n'assabenta quan ja està bloquejada: el client s'ha d'instal·lar amb antelació. Envia'ls a Accés d'emergència i Instal·lació del client, i demana'ls que facin tot el procés un cop mentre internet encara funciona amb normalitat.
Quantes sessions aguanta un servidor
Una sessió d'emergència no és «un usuari de VPN més»: és considerablement més cara, perquè el servidor empaqueta el trànsit dins d'un flux de vídeo, i això costa temps de processador.
Segons el mesurament d'una sessió real (vídeo en Full HD, uns 5 Mbit/s), una sessió ocupa aproximadament el 15% d'un nucli i 31 MB de memòria. La memòria pràcticament no compta; el límit real és la CPU.
| Nuclis al servidor | Capacitat raonable |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
No superis aquestes xifres ni tan sols en un servidor dedicat: quatre sessions en un sol nucli ja en són aproximadament el 60%, més la càrrega de fons. I tingues present que el mesurament es va fer mirant vídeo (~5 Mbit/s); si un usuari satura el túnel, una sola sessió pot costar bastant més.
Un camp de capacitat buit vol dir «sense límit». Llavors l'única protecció que queda és l'automatisme que deixa de col·locar sessions noves en un servidor molt sobrecarregat. Però reacciona amb retard i, en un servidor feble, per aleshores els teus usuaris habituals ja n'estaran patint. Als servidors d'un sol nucli, defineix la capacitat explícitament.
L'equilibri de càrrega ajuda fins a cert punt: si la ruta fa servir l'algorisme «Menys carregat per trànsit» (el que hi ha per defecte), un servidor amb un ús alt de CPU informa de menys amplada de banda lliure i els usuaris habituals nous s'encaminen a servidors menys carregats. Però això és una correcció basada en la CPU global, no un recompte de sessions d'emergència, i arriba amb uns quants minuts de retard: no substitueix una capacitat explícita.
Què mostra la interfície
Al bloc Runtime d'emergència (OLCRTC) de cada servidor:
- «Funció» — si les sessions poden executar-se en aquest servidor;
- «Capacitat» — el teu límit de sessions simultànies («sense definir» = sense límit);
- «Runtime» — l'estat: «correcte · N/M actives», «no correcte» o «encara no informa».
Just després d'activar-ho, espera't un «no correcte»: és normal, el servidor encara està instal·lant el runtime i no ha informat. Si es manté així molta estona, comprova que el servidor estigui en línia. El text «encara no informa» només apareix un moment mentre es carrega la pàgina.
Límits que val la pena conèixer per endavant
Una sessió viu fins a 12 hores i després s'atura sola. No es pot allargar: l'usuari crea una trucada nova i torna a sol·licitar la connexió.
Una sessió per usuari. Una segona sol·licitud no crea una segona sessió: a l'àrea personal es mostra «La sessió ja està en marxa» i un segon correu es queda sense resposta — val la pena explicar-ho als usuaris per endavant, perquè no sembli que està espatllat.
La velocitat d'Internet és més baixa que amb una connexió per Xray.
El servei de vídeo ha de ser accessible des del país del servidor. Qui entra a la trucada és el teu servidor, així que el que compta és on és el servidor, no on és l'usuari. Per exemple, a Letònia Yandex i Wildberries estan bloquejats: a través d'un servidor letó, Telemost i WB Stream no s'activaran. Tingues-ho en compte quan triïs en quins servidors actives l'accés d'emergència.
Els requisits per als usuaris són més estrictes del que semblen. Cal un correu verificat: els usuaris que hagis creat manualment sense correu no poden sol·licitar accés. A més, el compte ha de ser actiu: els comptes pausats, caducats, amb el límit esgotat i els que esperen el primer pagament (on_hold — tothom qui s'ha registrat pel seu compte i encara no ha pagat) es rebutgen. El correu ha de superar l'autenticació del remitent i contenir només l'enllaç de la trucada.
A l'àrea personal cada rebuig es mostra amb el seu motiu; a un correu se li respon sempre que puguem reconèixer el remitent com a usuari teu (un remitent no autenticat o desconegut no rep resposta). Si algú es queixa que «ho he sol·licitat i no ha passat res», comença per l'estat del compte i per l'enllaç de trucada que ha fet servir; per a la via del correu, comprova també que l'ha enviat des de l'adreça del compte i que el missatge només contenia l'enllaç.
Les rutes multisalt no hi participen. Per a les sessions d'emergència només es fan servir rutes directes.
El client d'emergència és Ghostlane, iPhone inclòs. És a l'App Store i a Google Play, i té versions per a Windows, macOS i Linux. Els usuaris que tenien instal·lat l'antic olcbox s'han de passar a Ghostlane: olcbox ja no s'actualitza, no coneix SaluteJazz ni VK Calls i les seves versions antigues no tenen el xifratge nou. Més detalls a la guia d'instal·lació.
Com desactivar-ho
Desmarca «Ruta d'emergència (OLCRTC)» a totes les rutes d'emergència del clúster, o elimina aquestes rutes: l'accés d'emergència del clúster es desactiva i les sessions noves deixen d'iniciar-se. Les que ja estan en marxa acaben el seu termini.
Si la teva subscripció Pro ha caducat, encara pots desactivar-ho tot, però per tornar-ho a activar cal renovar-la.