Accès de secours : quand le réseau bloque tout

Tout ce qui précède reposait sur une hypothèse : que le réseau laisse encore passer vos serveurs. Une route choisit un serveur, un inbound fait ressembler la connexion à une visite HTTPS ordinaire, le multihop étire le chemin sur plusieurs pays — mais tout cela suppose que le trafic sorte de l'appareil.

Or il ne sort pas toujours. Le réseau bascule sur une liste blanche : une courte liste de services autorisés fonctionne, et tout le reste — votre VPN compris — ne passe tout simplement pas. L'accès de secours (OLCRTC) est fait exactement pour ces heures-là.

Ce que c'est — et ce que ce n'est pas

L'accès de secours est un canal de repli, pas un second protocole. La connexion normale reste ce qu'elle a toujours été : VLESS + Reality sur vos propres serveurs. L'accès de secours réutilise ces mêmes serveurs, mais emballe le trafic à l'intérieur d'un appel vidéo sur un service que le réseau restreint laisse encore passer — vu de l'extérieur, cela ressemble à une visioconférence ordinaire.

Trois conséquences en découlent, et il vaut mieux les connaître avant de promettre quoi que ce soit :

• C'est l'utilisateur qui le lance à la main, uniquement quand plus rien ne fonctionne. Il n'y a pas de bascule automatique : la connexion normale ne « passe » pas d'elle-même sur le secours.
• C'est lent. Environ 14 Mbit/s en réception, moins d'un mégabit en émission, 175–235 ms de latence. Confortable pour lire et regarder des vidéos, inutilisable pour envoyer des fichiers, passer des appels vidéo ou jouer.
• C'est temporaire. Une session vit jusqu'à 12 heures puis s'arrête d'elle-même ; un utilisateur ne peut en avoir qu'une à la fois ; pour continuer, il en démarre une nouvelle.

À quoi cela ressemble côté utilisateur

1. Il crée un nouvel appel vidéo dans un service pris en charge — Yandex Telemost, WB Stream ou Jitsi Meet.
2. Il en transmet le lien : collé dans le bloc Accès de secours de son espace, ou envoyé par e-mail à une adresse de demande personnelle. Les deux voies font la même chose — et celle de l'e-mail continue de fonctionner quand votre vitrine est déjà bloquée.
3. L'un de vos serveurs rejoint cet appel en tant qu'invité. Une minute environ plus tard, l'utilisateur reçoit un lien de connexion commençant par olcrtc:// et un QR code.
4. Il l'importe dans olcbox, l'application de secours, et se connecte.

Ce qu'il faut de votre côté

• Un abonnement Pro — 0,99 € par mois. C'est l'offre qui apporte l'accès de secours ; Max l'inclut aussi, avec tout le reste (leçon 13).
• Une route de secours. Les serveurs des routes marquées comme de secours forment le pool sur lequel atterrissent les sessions. Lors de votre premier abonnement, le système en marque une pour vous — celle qui compte le plus d'inbounds fonctionnels — et lève au passage l'interrupteur du cluster.
• Les serveurs. Ils participent par défaut, et le runtime s'installe et se met à jour en arrière-plan : rien à installer en SSH.

Autrement dit, dans le cas courant il n'y a rien à configurer : vous vous abonnez, et l'accès de secours fonctionne. Les commandes manuelles restent là pour quand vous en avez besoin : quelles routes composent le pool, combien de sessions tient chaque serveur, et faut-il en écarter un.

En quoi cela diffère d'une route normale

• L'utilisateur ne choisit pas de pays. Il ne voit même pas le pool — c'est vous qui exprimez l'intention géographique en marquant certaines routes comme de secours. Vous pouvez en marquer plusieurs : le pool les fusionne, et si l'une n'a pas de serveur adapté, la session part sur une autre.
• Les routes multihop ne participent pas. Les sessions de secours n'utilisent que des routes directes.
• Une session coûte du vrai CPU. L'emballage du trafic dans un flux vidéo a consommé, à la mesure, environ 15 % d'un cœur et 31 Mo de mémoire (session vidéo à ~5 Mbit/s) — bien plus qu'un utilisateur VPN supplémentaire. L'ordre de grandeur : 3 sessions par cœur, soit 3 sur un serveur monocœur, 6–7 sur deux cœurs, 12–14 sur quatre.

Lesquels de vos utilisateurs pourront s'en servir

Les exigences sont plus strictes qu'il n'y paraît — et c'est de là que viennent les questions au support :

• Un e-mail vérifié. Les utilisateurs que vous avez créés à la main sans adresse e-mail ne pourront rien demander du tout.
• Un compte actif. Les comptes en pause, expirés, ayant épuisé leur quota de trafic et en attente du premier paiement (tous ceux qui se sont inscrits eux-mêmes sans avoir encore payé) sont refusés.

La plainte que vous entendrez ressemble à « j'ai demandé et il ne s'est rien passé ». Commencez par le statut du compte et le lien de l'appel ; pour la voie e-mail, vérifiez que le message est parti de l'adresse du compte et ne contenait que le lien.

À retenir

• L'accès de secours est une bouée pour les réseaux à liste blanche, pas un second protocole ni un remplacement de la connexion normale.
• Le trafic passe par vos propres serveurs, déguisé en appel vidéo que l'utilisateur crée lui-même.
• Lent, jusqu'à 12 heures, une session par utilisateur, démarrage manuel.
• Avec Pro, il s'active tout seul : une route est marquée comme de secours, l'interrupteur du cluster se lève, les serveurs participent par défaut.
• Une session ≈ 15 % d'un cœur CPU — sur les serveurs faibles, fixez explicitement la capacité.
• L'utilisateur a besoin d'un e-mail vérifié, d'un compte actif et de l'application installée à l'avance.

La suite

L'accès de secours répond à la panne du réseau. La leçon suivante traite de l'autre moitié : comment le système remarque que ce sont vos serveurs qui sont tombés.