Activer l'accès de secours
Configurez l'accès de secours (OLCRTC) pour vos utilisateurs : abonnement Pro, une route de secours et le runtime par serveur — étape par étape, dans le bon ordre.
Cette page s'adresse à vous, le propriétaire du service. Elle explique comment activer l'accès de secours pour que vos utilisateurs puissent compter dessus. Pour les utilisateurs eux-mêmes, il existe des pages distinctes : Accès de secours — comment cela fonctionne et quoi faire pendant un blocage — et Installation de l'application de secours — où télécharger l'application et comment l'installer.
L'accès de secours (OLCRTC) est un canal de repli pour les réseaux à listes blanches où la connexion habituelle ne passe pas du tout. Le trafic continue de transiter par vos propres serveurs, mais il est déguisé en appel vidéo sur un service autorisé. Ce n'est ni un second protocole ni un remplacement du principal : il est plus lent, prévu pour des sessions courtes, démarré manuellement par l'utilisateur, et uniquement quand tout le reste a cessé de fonctionner.
La fonctionnalité est déployée par étapes. Même avec tous les interrupteurs activés, le runtime de secours peut ne pas encore être installé sur vos serveurs et le démarrage des sessions peut ne pas encore être actif : l'accès s'ouvre progressivement. Si un serveur reste longtemps loin de l'état « en bon état » après activation, c'est très probablement que le déploiement n'est simplement pas encore arrivé jusqu'à vous.
Elle ne fonctionne pas non plus sur tous les réseaux ni dans tous les pays, et elle dépend de l'accessibilité d'un service vidéo externe (et, pour la voie par e-mail, du bon acheminement du courrier). Ne la promettez pas comme une capacité garantie — présentez-la comme une assurance contre les blocages sévères.
Ce qu'il vous faut
- un abonnement Pro (ou Max, qui inclut tout ce que contient Pro) ;
- au moins une route marquée comme de secours ;
- au moins un serveur d'une route de secours avec le runtime activé ;
- des utilisateurs avec un e-mail vérifié et un compte actif (voir la section sur les limites plus bas).
Ordre des opérations
Il y a deux interrupteurs, à deux endroits différents :
| Ce que vous activez | Où cela se trouve | Comment cela s'appelle |
|---|---|---|
| Route | réglages de la route (en modification) | « Route de secours (OLCRTC) » |
| Serveur | panneau du serveur, bouton « Modifier » | « Exécuter OLCRTC sur ce serveur » |
Le cluster n'a pas d'interrupteur propre : l'accès de secours du cluster est actif tant qu'au moins une de ses routes est marquée comme de secours.
Lors de votre premier abonnement Pro, le système marque à votre place comme route de secours celle qui compte le plus d'inbounds fonctionnels, et l'accès de secours du cluster s'active aussitôt. Les serveurs participent par défaut et le runtime se déploie tout seul. La plupart du temps, les étapes ci-dessous sont donc une vérification plutôt qu'une séquence obligatoire : parcourez-les si vous voulez choisir d'autres routes, fixer une capacité ou écarter un serveur précis.
Souscrivez à Pro. Allez dans Facturation → bloc de l'abonnement. Sans Pro actif, les interrupteurs de secours ne s'affichent tout simplement pas : la page du cluster présente à la place une carte « Accès de secours (OLCRTC) » avec un bouton « Mettre à niveau ».
Marquez une route comme de secours — dans les réglages de la route elle-même. Ouvrez la route en modification et activez « Route de secours (OLCRTC) ».
L'interrupteur n'apparaît qu'en modification d'une route existante. Le formulaire de création de route ne l'a pas : créez d'abord la route, puis ouvrez ses réglages et marquez-la comme de secours.
Les serveurs de cette route rejoignent le pool de secours. Vous pouvez marquer plusieurs routes — le pool les fusionne toutes, et si une route n'a pas de serveur adapté, la connexion part vers un serveur d'une autre. Les routes marquées reçoivent une étiquette secours (OLCRTC) dans la liste des routes.
Dès que la première route est marquée, l'accès de secours du cluster s'active tout seul : il n'y a rien d'autre à activer.
Autorisez les sessions sur les serveurs. Cliquez sur un serveur pour ouvrir son panneau, trouvez le bloc Runtime de secours (OLCRTC), appuyez sur « Modifier », activez « Exécuter OLCRTC sur ce serveur » et appuyez sur « Enregistrer ».
Le runtime s'installe et se met à jour tout seul, en arrière-plan — inutile de vous connecter au serveur. Tant qu'il n'est pas installé et qu'il ne rapporte pas, l'état affiché est « pas en bon état » ; c'est normal, attendez « en bon état · N/M actives ».
Le bloc n'apparaît que dans le mode d'interface normal — le mode simplifié Single ne l'a pas.
Définissez la capacité. Dans le même bloc — Sessions simultanées max. Vous pouvez le laisser vide, mais mieux vaut éviter : voir la section suivante.
Informez vos utilisateurs. L'accès de secours ne sert à rien si les gens l'apprennent une fois déjà bloqués : l'application doit être installée à l'avance. Renvoyez-les vers Accès de secours et Installation de l'application, et demandez-leur de parcourir tout le déroulement une fois pendant qu'Internet fonctionne encore normalement.
Combien de sessions un serveur peut supporter
Une session de secours n'est pas « un utilisateur VPN de plus » — elle coûte nettement plus cher : le serveur emballe le trafic dans un flux vidéo, et cela consomme du temps processeur.
Mesuré sur une session réelle (vidéo Full HD, environ 5 Mbit/s), une session occupe à peu près 15 % d'un cœur et 31 Mo de mémoire. La mémoire n'a presque aucune importance ; la vraie limite, c'est le processeur.
| Cœurs du serveur | Capacité raisonnable |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Ne dépassez pas ces chiffres, même sur un serveur dédié : quatre sessions sur un seul cœur représentent déjà environ 60 % de celui-ci, plus la charge de fond. Et notez que la mesure a été prise en regardant une vidéo (~5 Mbit/s) ; si un utilisateur sature le tunnel, une session peut coûter sensiblement plus.
Un champ de capacité vide signifie « aucune limite ». La seule protection restante est l'automatisme qui cesse de placer de nouvelles sessions sur un serveur très surchargé. Mais il réagit avec du retard et, sur un serveur faible, vos utilisateurs habituels en souffriront déjà d'ici là. Sur les serveurs à un seul cœur, définissez la capacité explicitement.
L'équilibrage aide en partie : si la route utilise l'algorithme « Moins chargé par le trafic » (celui par défaut), un serveur dont le processeur est très sollicité annonce moins de bande passante libre et les nouveaux utilisateurs habituels sont dirigés vers des serveurs moins chargés. Mais c'est une correction fondée sur la charge processeur globale, pas sur un décompte des sessions de secours, et elle accuse plusieurs minutes de retard — elle ne remplace pas une capacité explicite.
Ce que montre l'interface
Dans le bloc Runtime de secours (OLCRTC) de chaque serveur :
- Fonction — si des sessions peuvent s'exécuter sur ce serveur ;
- Capacité — votre limite de sessions simultanées (« non définie » = aucune limite) ;
- Runtime — l'état : « en bon état · N/M actives », « pas en bon état » ou « ne rapporte pas encore ».
Juste après l'activation, attendez-vous à « pas en bon état » — c'est normal, le serveur installe encore le runtime et n'a pas encore rapporté. Si cela dure longtemps, vérifiez que le serveur est joignable tout court. « Ne rapporte pas encore » n'apparaît qu'un instant pendant le chargement de la page.
Limites à connaître d'emblée
Une session vit jusqu'à 12 heures, puis s'arrête d'elle-même. Elle ne peut pas être prolongée — l'utilisateur crée un nouvel appel et demande une nouvelle connexion.
Une session par utilisateur. Une seconde demande ne crée pas de seconde session : dans l'espace client s'affiche « la session est déjà en cours », et un second e-mail reste sans réponse — mieux vaut l'expliquer aux utilisateurs à l'avance pour que cela ne passe pas pour une panne.
Le débit Internet est plus faible qu'avec une connexion via Xray.
Le service vidéo doit être accessible depuis le pays du serveur. C'est votre serveur qui rejoint l'appel : ce qui compte est donc le pays du serveur, pas celui de l'utilisateur. En Lettonie, par exemple, Yandex et Wildberries sont bloqués — via un serveur letton, Telemost et WB Stream ne démarreront pas. Gardez-le en tête au moment de choisir les serveurs qui porteront l'accès de secours.
Les exigences envers les utilisateurs sont plus strictes qu'il n'y paraît. Un e-mail vérifié est obligatoire — les utilisateurs que vous avez créés manuellement sans e-mail ne peuvent pas demander l'accès. Le compte doit aussi être actif : les comptes en pause, expirés, à quota épuisé et en attente du premier paiement (on_hold — tous ceux qui se sont inscrits eux-mêmes et n'ont pas encore payé) sont refusés. L'e-mail doit passer l'authentification de l'expéditeur et ne contenir que le lien de l'appel.
Dans l'espace client, chaque refus s'affiche avec sa raison ; par e-mail, une réponse est envoyée dès que nous pouvons reconnaître l'expéditeur comme l'un de vos utilisateurs (un expéditeur non authentifié ou inconnu reste sans réponse). Si quelqu'un se plaint que « j'ai fait la demande et rien ne s'est passé », commencez par le statut du compte et le lien d'appel utilisé ; pour la voie par e-mail, vérifiez aussi que le message est parti de l'adresse du compte et ne contenait que le lien de l'appel.
Les routes multi-sauts ne participent pas. Seules les routes directes sont utilisées pour les sessions de secours.
Le client de secours est Ghostlane, y compris sur iPhone. Il est disponible sur l'App Store et Google Play, avec des versions pour Windows, macOS et Linux. Les utilisateurs qui avaient installé l'ancien olcbox doivent passer à Ghostlane : olcbox n'est plus mis à jour et ne connaît ni SaluteJazz ni VK Calls, et ses anciennes versions ne disposent pas du nouveau chiffrement. Voir le guide d'installation.
Comment le désactiver
Désactivez « Route de secours (OLCRTC) » sur toutes les routes de secours du cluster, ou supprimez ces routes — l'accès de secours du cluster se désactive et plus aucune nouvelle session ne sera démarrée. Celles déjà en cours vont jusqu'au bout de leur durée.
Si votre abonnement Pro a pris fin, vous pouvez encore tout désactiver, mais le réactiver nécessite de le renouveler.