Noodtoegang inschakelen
Stel noodtoegang (OLCRTC) in voor je gebruikers: Pro-abonnement, een noodroute en de runtime per server — stap voor stap, in de juiste volgorde.
Deze pagina is voor jou, de eigenaar van de dienst. Ze legt uit hoe je noodtoegang inschakelt, zodat je gebruikers erop kunnen rekenen. Voor de gebruikers zelf zijn er aparte pagina's: Noodtoegang — hoe het werkt en wat je tijdens een blokkade doet — en De noodclient installeren — waar je de app downloadt en hoe je hem installeert.
Noodtoegang (OLCRTC) is een reservekanaal voor netwerken met toelatingslijsten, waar de normale verbinding er helemaal niet doorheen komt. Het verkeer loopt nog steeds over je eigen servers, maar wordt vermomd als een videogesprek in een toegestane dienst. Het is geen tweede protocol en geen vervanging van het hoofdprotocol: het is trager, bedoeld voor korte sessies, wordt handmatig door de gebruiker gestart en alleen wanneer al het andere is opgehouden te werken.
De functie wordt in fasen uitgerold. Zelfs met alle schakelaars aan kan de nood-runtime nog niet op je servers geïnstalleerd zijn en het starten van sessies nog niet actief zijn: de toegang gaat geleidelijk open. Blijft een server na inschakelen lang weg van "gezond", dan is de uitrol hoogstwaarschijnlijk simpelweg nog niet bij jou aangekomen.
Ze werkt ook niet op elk netwerk of in elk land, en ze hangt ervan af of een externe videodienst bereikbaar is (en, voor de weg via e-mail, of de mail aankomt). Beloof het niet als een gegarandeerde mogelijkheid — presenteer het als verzekering tegen harde blokkades.
Wat je nodig hebt
- een Pro-abonnement (of Max, waarin alles uit Pro zit);
- minstens één route die als nood is gemarkeerd;
- minstens één server op een noodroute met runtime ingeschakeld;
- gebruikers met een geverifieerd e-mailadres en een actief account (zie het gedeelte over beperkingen hieronder).
Volgorde van handelingen
Er zijn twee schakelaars op twee verschillende plekken:
| Wat je inschakelt | Waar het staat | Hoe het heet |
|---|---|---|
| Route | route-instellingen (bij het bewerken) | "Noodroute (OLCRTC)" |
| Server | serverpaneel, knop "Bewerken" | "OLCRTC uitvoeren op deze server" |
Het cluster heeft geen eigen schakelaar: de noodtoegang van het cluster staat aan zolang minstens één van zijn routes is gemarkeerd.
Bij je eerste Pro-abonnement markeert het systeem voor jou de route met de meeste werkende inbounds als noodroute, en de noodtoegang van het cluster gaat meteen aan. Servers doen standaard mee en de runtime rolt zichzelf uit. Meestal zijn de stappen hieronder dus een controle en geen verplichte volgorde: loop ze door als je andere routes wilt kiezen, een capaciteit wilt instellen of een specifieke server buiten wilt laten.
Neem een Pro-abonnement. Ga naar Facturering → het abonnementenblok. Zonder een actief Pro worden de noodschakelaars helemaal niet getoond: de clusterpagina laat in plaats daarvan een kaart "Noodtoegang (OLCRTC)" zien met een knop "Upgraden".
Markeer een route als nood — in de instellingen van de route zelf. Open de route om te bewerken en zet de schakelaar "Noodroute (OLCRTC)" aan.
De schakelaar verschijnt alleen bij het bewerken van een bestaande route. Het formulier voor een nieuwe route heeft hem niet: maak eerst de route aan, open daarna de instellingen ervan en markeer hem als nood.
De servers van die route komen in de noodpool. Je kunt meerdere routes markeren — de pool voegt ze allemaal samen, en heeft één route geen geschikte server, dan gaat de verbinding naar een server uit een andere. Gemarkeerde routes krijgen in de routelijst het label nood (OLCRTC).
Zodra de eerste route is gemarkeerd, gaat de noodtoegang van het cluster vanzelf aan: je hoeft verder niets in te schakelen.
Sta sessies toe op servers. Klik op een server om zijn paneel te openen, zoek het blok Nood-Runtime (OLCRTC), druk op "Bewerken", zet "OLCRTC uitvoeren op deze server" aan en druk op "Opslaan".
De runtime installeert en werkt zichzelf op de achtergrond bij — je hoeft niet op de server in te loggen. Zolang hij niet geïnstalleerd is en nog niets rapporteert, staat de status op "niet gezond"; dat is normaal, wacht op "gezond · N/M actief".
Het blok verschijnt alleen in de gewone interfacemodus — de vereenvoudigde Single-modus heeft het niet.
Stel de capaciteit in. In hetzelfde blok — Max. gelijktijdige sessies. Je mag het leeg laten, maar beter van niet: zie het volgende gedeelte.
Vertel het je gebruikers. Noodtoegang is nutteloos als mensen er pas van horen wanneer ze al geblokkeerd zijn: de client moet vooraf geïnstalleerd zijn. Wijs ze op Noodtoegang en De client installeren en vraag ze het proces één keer door te lopen zolang het internet nog normaal werkt.
Hoeveel sessies een server aankan
Een noodsessie is niet "nog één VPN-gebruiker" — ze is aanzienlijk duurder: de server verpakt het verkeer in een videostroom, en dat kost processortijd.
Gemeten op een echte sessie (Full HD-video, ongeveer 5 Mbit/s) kost één sessie ruwweg 15% van één kern en 31 MB geheugen. Geheugen doet er nauwelijks toe; de processor is de echte grens.
| Kernen op de server | Verstandige capaciteit |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Ga niet boven deze getallen, zelfs niet op een dedicated server: vier sessies op één kern is al ongeveer 60% daarvan plus de achtergrondbelasting. En let op: de meting is gedaan tijdens video kijken (~5 Mbit/s); trekt een gebruiker de tunnel vol, dan kan één sessie merkbaar meer kosten.
Een leeg capaciteitsveld betekent "geen limiet". De enige bescherming die dan overblijft, is de automatisering die geen nieuwe sessies meer plaatst op een zwaar overbelaste server. Die reageert echter met vertraging, en op een zwakke server hebben je gewone gebruikers er dan al last van. Stel op servers met één kern de capaciteit expliciet in.
Balanceren helpt tot op zekere hoogte: gebruikt de route het algoritme "Minst belast op verkeer" (de standaard), dan meldt een server met hoog processorgebruik minder vrije bandbreedte en worden nieuwe gewone gebruikers naar minder belaste servers geleid. Maar dat is een correctie op basis van de totale processorbelasting, geen telling van noodsessies, en ze loopt enkele minuten achter — een vervanging van een expliciete capaciteit is het niet.
Wat de interface toont
In het blok Nood-Runtime (OLCRTC) van elke server:
- Functie — of er op deze server sessies mogen draaien;
- Capaciteit — jouw limiet op gelijktijdige sessies ("niet ingesteld" = geen limiet);
- Runtime — status: "gezond · N/M actief", "niet gezond" of "rapporteert nog niet".
Verwacht direct na het inschakelen "niet gezond" — dat is normaal, de server installeert de runtime nog en heeft nog niets gerapporteerd. Blijft dat lang zo, controleer dan of de server überhaupt bereikbaar is. "Rapporteert nog niet" flitst alleen voorbij terwijl de pagina laadt.
Beperkingen die je vooraf moet kennen
Een sessie leeft tot 12 uur en stopt daarna vanzelf. Verlengen kan niet — de gebruiker maakt een nieuw gesprek aan en vraagt opnieuw een verbinding aan.
Eén sessie per gebruiker. Een tweede aanvraag maakt niets aan zolang er een sessie loopt: op de accountpagina ziet de gebruiker "de sessie loopt al", en een tweede e-mail krijgt geen antwoord — leg dat gebruikers vooraf uit, zodat het niet als een storing overkomt.
De internetsnelheid is lager dan bij een verbinding via Xray.
De videodienst moet bereikbaar zijn vanuit het land van de server. Het is jouw server die deelneemt aan het gesprek, dus het land van de server telt, niet dat van de gebruiker. In Letland zijn Yandex en Wildberries bijvoorbeeld geblokkeerd — via een Letse server komen Telemost en WB Stream niet op. Houd daar rekening mee bij het kiezen van de servers waarop je noodtoegang aanzet.
De eisen aan gebruikers zijn strenger dan ze lijken. Een geverifieerd e-mailadres is vereist — gebruikers die je handmatig zonder e-mailadres hebt aangemaakt, kunnen geen toegang aanvragen. Het account moet ook actief zijn: gepauzeerde, verlopen, door de limiet heen zijnde en op de eerste betaling wachtende accounts (on_hold — iedereen die zich zelf heeft aangemeld en nog niet heeft betaald) worden geweigerd. De e-mail moet de afzenderverificatie doorstaan en mag alleen de gesprekslink bevatten.
Op de accountpagina wordt elke afwijzing met de reden getoond; per e-mail gaat er een antwoord uit zodra we de afzender als jouw gebruiker kunnen herkennen (een niet-geauthenticeerde of onbekende afzender krijgt geen antwoord). Klaagt iemand dat "ik heb aangevraagd en er gebeurde niets", begin dan bij de accountstatus en de gebruikte gesprekslink; controleer bij de weg via e-mail ook of het bericht van het accountadres kwam en alleen de link bevatte.
Multi-hoproutes doen niet mee. Voor noodsessies worden alleen directe routes gebruikt.
De noodclient is Ghostlane, ook voor iPhone. Hij staat in de App Store en Google Play en heeft builds voor Windows, macOS en Linux. Gebruikers die de oude olcbox hebben geïnstalleerd, moeten overstappen: olcbox wordt niet meer bijgewerkt en kent SaluteJazz en VK Calls niet, en de oudere versies missen de nieuwe versleuteling. Zie de installatiehandleiding.
Uitschakelen
Zet "Noodroute (OLCRTC)" uit op alle noodroutes van het cluster, of verwijder die routes — de noodtoegang van het cluster gaat dan uit en er worden geen nieuwe sessies meer gestart. Al lopende sessies maken hun termijn af.
Is je Pro-abonnement afgelopen, dan kun je alles nog uitschakelen, maar weer inschakelen kan alleen na verlenging.