Noodtoegang inschakelen
Stel noodtoegang (OLCRTC) in voor je gebruikers: Pro-abonnement, een noodroute, de clusterschakelaar 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 is experimenteel en 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 en e-mail bereikbaar zijn. 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;
- de OLCRTC-schakelaar aan bij het cluster;
- minstens één server in dat cluster met runtime ingeschakeld;
- gebruikers met een geverifieerd e-mailadres en een actief account (zie het gedeelte over beperkingen hieronder).
Volgorde van handelingen
Er zijn drie schakelaars op drie verschillende plekken, en ze zijn makkelijk te verwarren — twee ervan heten bijna hetzelfde:
| Wat je inschakelt | Waar het staat | Hoe het heet |
|---|---|---|
| Route | route-instellingen (bij het bewerken) | "Noodroute (OLCRTC)" |
| Cluster | clusterpagina, boven de routelijst | "OLCRTC inschakelen voor dit cluster" |
| Server | serverpaneel, knop "Bewerken" | "OLCRTC uitvoeren op deze server" |
De volgorde is belangrijk: het cluster laat je OLCRTC niet inschakelen zolang er geen noodroute is. Eerst de route, dan het cluster.
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 in het blok "Noodtoegang (OLCRTC)" 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.
Schakel OLCRTC in voor het hele cluster. Dit is een tweede, aparte schakelaar — niet die in de route. Hij staat op de clusterpagina, in het blok "Noodtoegang" met het OLCRTC-label, direct boven de routelijst, en heet "OLCRTC inschakelen voor dit cluster".
Dit is de hoofdschakelaar: zolang hij uit staat, kunnen de gebruikers van het cluster niets aanvragen, hoeveel routes je ook als nood hebt gemarkeerd. Onder de schakelaar zie je hoeveel noodroutes al in de pool zitten.
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 stuurt een nieuwe e-mail.
Eén sessie per gebruiker. Een tweede e-mail maakt niets aan en krijgt geen antwoord — leg dat gebruikers vooraf uit, zodat het niet als een storing overkomt.
Ongeveer 14 Mbit/s down en minder dan een megabit up, met 175–235 ms vertraging. Video kijken en mailen gaat comfortabel; grote bestanden versturen, videobellen en gamen niet. Dat is het plafond van de huidige tunnelconfiguratie, niet van de hoofdverbinding.
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 de frequentie is begrensd op vijf aanvragen per uur per gebruiker en honderd voor de hele dienst.
Afwijzingen bij deze controles zijn stil: de gebruiker krijgt helemaal geen antwoord. Klaagt iemand dat "ik heb de e-mail gestuurd en er kwam niets terug", begin dan bij de accountstatus en bij de vraag of de juiste gesprekslink is verstuurd.
Multi-hoproutes doen niet mee. Voor noodsessies worden alleen directe routes gebruikt.
De iPhone is lastiger. De iOS-client kan alleen worden gesideload — Apple biedt hem niet aan. Je iPhone-gebruikers moeten zich vooraf en zorgvuldiger voorbereiden; de installatiehandleiding beschrijft dat.
Uitschakelen
Je kunt OLCRTC inschakelen voor dit cluster op elk moment uitzetten — er worden dan geen nieuwe sessies meer gestart. Al lopende sessies maken hun termijn af.
De laatste noodroute kan niet worden gedemarkeerd of verwijderd zolang OLCRTC aan staat: markeer eerst een andere route of schakel OLCRTC uit bij het cluster.
Is je Pro-abonnement afgelopen, dan kun je alles nog uitschakelen, maar weer inschakelen kan alleen na verlenging.