Activer l'accès de secours
Configurez l'accès de secours (OLCRTC) pour vos utilisateurs : abonnement Pro, une route de secours, l'interrupteur du cluster 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 expérimentale et 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 de l'e-mail. 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 ;
- l'interrupteur OLCRTC activé sur le cluster ;
- au moins un serveur de ce cluster 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 trois interrupteurs, à trois endroits différents, et il est facile de les confondre — deux d'entre eux portent des noms presque identiques.
| Ce que vous activez | Où cela se trouve | Comment cela s'appelle |
|---|---|---|
| Route | réglages de la route (en modification) | « Route de secours (OLCRTC) » |
| Cluster | page du cluster, au-dessus de la liste des routes | « Activer OLCRTC pour ce cluster » |
| Serveur | panneau du serveur, bouton « Modifier » | « Exécuter OLCRTC sur ce serveur » |
L'ordre compte : le cluster ne vous laissera pas activer OLCRTC tant qu'il n'y a aucune route de secours. D'abord la route, ensuite le cluster.
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, dans le bloc « Accès de secours (OLCRTC) », 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 dans la liste des routes.
Activez OLCRTC pour tout le cluster. C'est un deuxième interrupteur, distinct — pas celui de la route. Il se trouve sur la page du cluster, dans le bloc « Accès de secours » marqué OLCRTC, juste au-dessus de la liste des routes, et s'appelle « Activer OLCRTC pour ce cluster ».
C'est l'interrupteur principal : tant qu'il est désactivé, les utilisateurs du cluster ne peuvent rien demander, quel que soit le nombre de routes que vous avez marquées comme de secours. Sous l'interrupteur, vous voyez combien de routes de secours sont déjà dans le pool.
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é (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 envoie un nouvel e-mail.
Une session par utilisateur. Un second e-mail ne crée rien et ne reçoit aucune réponse — mieux vaut l'expliquer aux utilisateurs à l'avance pour que cela ne passe pas pour une panne.
Environ 14 Mbit/s en réception et moins d'un mégabit en émission, avec 175–235 ms de latence. Regarder des vidéos et gérer ses e-mails est confortable ; envoyer de gros fichiers, faire des appels vidéo et jouer, non. C'est le plafond de la configuration actuelle du tunnel, pas celui de la connexion principale.
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 la fréquence est plafonnée à cinq demandes par heure et par utilisateur, et cent pour l'ensemble du service.
Les refus à ces vérifications sont silencieux : l'utilisateur ne reçoit aucune réponse. Si quelqu'un se plaint que « j'ai envoyé l'e-mail et rien n'est revenu », commencez par le statut du compte et par la question de savoir si le bon lien d'appel a été envoyé.
Les routes multi-sauts ne participent pas. Seules les routes directes sont utilisées pour les sessions de secours.
L'iPhone est plus compliqué. L'application iOS ne peut être installée que par sideload — Apple ne la distribue pas. Vos utilisateurs sur iPhone doivent se préparer à l'avance et plus soigneusement ; le guide d'installation l'explique.
Comment le désactiver
Vous pouvez décocher Activer OLCRTC pour ce cluster à tout moment — plus aucune nouvelle session ne sera démarrée. Celles déjà en cours vont jusqu'au bout de leur durée.
La dernière route de secours ne peut être ni démarquée ni supprimée tant qu'OLCRTC est activé : marquez d'abord une autre route, ou désactivez OLCRTC sur le cluster.
Si votre abonnement Pro a pris fin, vous pouvez encore tout désactiver, mais le réactiver nécessite de le renouveler.