Notfallzugang aktivieren
Richte den Notfallzugang (OLCRTC) für deine Nutzer ein: Pro-Abonnement, eine Notfallroute und die Runtime pro Server — Schritt für Schritt, in der richtigen Reihenfolge.
Diese Seite richtet sich an dich als Betreiber des Dienstes. Sie erklärt, wie du den Notfallzugang aktivierst, damit deine Nutzer sich darauf verlassen können. Für die Nutzer selbst gibt es eigene Seiten: Notfallzugang — wie es funktioniert und was während einer Sperre zu tun ist — und Notfall-App installieren — wo man die App herunterlädt und wie man sie installiert.
Der Notfallzugang (OLCRTC) ist ein Ausweichkanal für Netze mit Zulassungslisten, in denen die normale Verbindung überhaupt nicht durchkommt. Der Datenverkehr läuft weiterhin über deine eigenen Server, ist aber als Videoanruf in einem erlaubten Dienst getarnt. Er ist kein zweites Protokoll und kein Ersatz für das Hauptprotokoll: langsamer, für kurze Sitzungen gedacht, vom Nutzer manuell gestartet und nur dann, wenn alles andere nicht mehr funktioniert.
Die Funktion wird schrittweise ausgerollt. Selbst wenn alle Schalter aktiviert sind, ist die Notfall-Runtime womöglich noch nicht auf deinen Servern installiert und der Start von Sitzungen noch nicht freigeschaltet: Der Zugang öffnet sich nach und nach. Bleibt ein Server nach dem Aktivieren lange vom Zustand „fehlerfrei“ entfernt, ist der Rollout höchstwahrscheinlich einfach noch nicht bei dir angekommen.
Sie funktioniert außerdem nicht in jedem Netz und nicht in jedem Land und hängt davon ab, dass ein externer Videodienst erreichbar ist (und beim Weg per E-Mail auch davon, dass die Mail durchkommt). Versprich sie nicht als garantierte Möglichkeit — stelle sie als Versicherung gegen harte Sperren dar.
Was du brauchst
- ein Pro-Abonnement (oder Max, das alles aus Pro enthält);
- mindestens eine als Notfall markierte Route;
- mindestens einen Server auf einer Notfallroute mit aktivierter Runtime;
- Nutzer mit bestätigter E-Mail-Adresse und einem aktiven Konto (siehe Abschnitt zu den Grenzen weiter unten).
Reihenfolge der Schritte
Es gibt zwei Schalter an zwei verschiedenen Stellen.
| Was du aktivierst | Wo es liegt | Wie es heißt |
|---|---|---|
| Route | Routeneinstellungen (beim Bearbeiten) | „Notfallroute (OLCRTC)“ |
| Server | Server-Panel, Schaltfläche „Bearbeiten“ | „OLCRTC auf diesem Server ausführen“ |
Der Cluster hat keinen eigenen Schalter: Der Notfallzugang des Clusters ist aktiv, solange mindestens eine seiner Routen markiert ist.
Beim ersten Pro-Abo markiert das System für dich die Route mit den meisten funktionierenden Inbounds als Notfallroute, und der Notfallzugang des Clusters schaltet sich sofort ein. Server machen standardmäßig mit, und die Runtime rollt von selbst aus. Meist sind die Schritte unten daher eine Kontrolle und keine Pflichtreihenfolge: Geh sie durch, wenn du andere Routen wählen, eine Kapazität setzen oder einen bestimmten Server außen vor lassen willst.
Schließe Pro ab. Gehe zu Abrechnung → Abo-Block. Ohne aktives Pro werden die Notfall-Schalter gar nicht erst angezeigt: Auf der Cluster-Seite erscheint stattdessen eine Karte „Notfallzugang (OLCRTC)“ mit der Schaltfläche „Upgrade“.
Markiere eine Route als Notfallroute — in den Einstellungen der Route selbst. Öffne die Route zum Bearbeiten und aktiviere den Schalter „Notfallroute (OLCRTC)“.
Der Schalter erscheint nur beim Bearbeiten einer bestehenden Route. Im Formular zum Anlegen einer neuen Route gibt es ihn nicht: Lege zuerst die Route an, öffne dann ihre Einstellungen und markiere sie als Notfallroute.
Die Server dieser Route kommen in den Notfall-Pool. Du kannst mehrere Routen markieren — der Pool führt sie alle zusammen, und wenn eine Route keinen passenden Server hat, geht die Verbindung an einen Server aus einer anderen. Markierte Routen erhalten in der Routenliste die Kennzeichnung Notfall (OLCRTC).
Sobald die erste Route markiert ist, schaltet sich der Notfallzugang des Clusters von selbst ein: Du musst sonst nichts einschalten.
Erlaube Sitzungen auf den Servern. Klicke auf einen Server, um sein Panel zu öffnen, finde den Block Notfall-Runtime (OLCRTC), drücke „Bearbeiten“, aktiviere „OLCRTC auf diesem Server ausführen“ und drücke „Speichern“.
Die Runtime installiert und aktualisiert sich selbst im Hintergrund — du musst dich nicht auf dem Server anmelden. Bis sie installiert ist und meldet, wird der Zustand als „nicht fehlerfrei“ angezeigt; das ist normal, warte auf „fehlerfrei · N/M aktiv“.
Der Block erscheint nur im regulären Oberflächenmodus — im vereinfachten Single-Modus gibt es ihn nicht.
Lege die Kapazität fest. Im selben Block — Max. gleichzeitige Sitzungen. Du kannst das Feld leer lassen, solltest es aber besser nicht: siehe nächster Abschnitt.
Informiere deine Nutzer. Der Notfallzugang nützt nichts, wenn die Leute erst davon erfahren, wenn sie schon gesperrt sind: Die App muss im Voraus installiert werden. Verweise sie auf Notfallzugang und App installieren und bitte sie, den Ablauf einmal durchzugehen, solange das Internet noch normal funktioniert.
Wie viele Sitzungen ein Server verkraftet
Eine Notfallsitzung ist nicht „ein VPN-Nutzer mehr“ — sie ist deutlich teurer: Der Server verpackt den Datenverkehr in einen Videostream, und das kostet Rechenzeit.
Gemessen an einer echten Sitzung (Full-HD-Video, etwa 5 Mbit/s) belegt eine Sitzung rund 15 % eines Kerns und 31 MB Arbeitsspeicher. Der Speicher spielt kaum eine Rolle; die eigentliche Grenze ist die CPU.
| Kerne auf dem Server | Sinnvolle Kapazität |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Geh über diese Werte auch auf einem dedizierten Server nicht hinaus: Vier Sitzungen auf einem einzigen Kern sind bereits etwa 60 % davon plus Grundlast. Und beachte, dass die Messung beim Videoschauen entstand (~5 Mbit/s); wenn ein Nutzer den Tunnel voll auslastet, kann eine Sitzung merklich mehr kosten.
Ein leeres Kapazitätsfeld bedeutet „kein Limit“. Dann bleibt als einziger Schutz die Automatik, die keine neuen Sitzungen mehr auf einen stark überlasteten Server legt. Sie reagiert aber verzögert, und auf einem schwachen Server leiden deine regulären Nutzer bis dahin bereits. Auf Servern mit einem Kern solltest du die Kapazität ausdrücklich setzen.
Das Balancing hilft bis zu einem gewissen Grad: Nutzt die Route den Algorithmus „Am wenigsten ausgelastet nach Traffic“ (die Voreinstellung), meldet ein Server mit hoher CPU-Auslastung weniger freie Bandbreite, und neue reguläre Nutzer werden auf weniger ausgelastete Server geleitet. Das ist aber eine Korrektur anhand der Gesamtauslastung der CPU, keine Zählung der Notfallsitzungen, und sie hinkt mehrere Minuten hinterher — eine ausdrückliche Kapazität ersetzt sie nicht.
Was die Oberfläche anzeigt
Im Block Notfall-Runtime (OLCRTC) jedes Servers:
- Funktion — ob auf diesem Server Sitzungen laufen dürfen;
- Kapazität — dein Limit gleichzeitiger Sitzungen („nicht festgelegt“ = kein Limit);
- Runtime — der Zustand: „fehlerfrei · N/M aktiv“, „nicht fehlerfrei“ oder „meldet noch nicht“.
Direkt nach dem Aktivieren ist „nicht fehlerfrei“ zu erwarten — das ist normal, der Server installiert die Runtime noch und hat sich noch nicht gemeldet. Bleibt es lange dabei, prüfe, ob der Server überhaupt erreichbar ist. „Meldet noch nicht“ blitzt nur beim Laden der Seite kurz auf.
Grenzen, die man vorab kennen sollte
Eine Sitzung lebt bis zu 12 Stunden, dann stoppt sie von selbst. Verlängern lässt sie sich nicht — der Nutzer erstellt einen frischen Anruf und fordert die Verbindung erneut an.
Eine Sitzung pro Nutzer. Eine zweite Anfrage erzeugt keine zweite Sitzung: Im Kundenkonto erscheint „Die Sitzung läuft bereits“, und eine zweite E-Mail bekommt keine Antwort — das erklärst du deinen Nutzern besser vorab, damit es nicht wie ein Defekt wirkt.
Die Internetgeschwindigkeit ist niedriger als bei einer Verbindung über Xray.
Der Videodienst muss aus dem Land des Servers erreichbar sein. An der Konferenz nimmt dein Server teil, also zählt sein Standort, nicht der des Nutzers. In Lettland sind zum Beispiel Yandex und Wildberries gesperrt — über einen lettischen Server kommen Telemost und WB Stream nicht zustande. Berücksichtige das bei der Auswahl der Server für den Notfallzugang.
Die Anforderungen an die Nutzer sind strenger, als sie wirken. Eine bestätigte E-Mail-Adresse ist Pflicht — Nutzer, die du manuell ohne E-Mail angelegt hast, können keinen Zugang anfordern. Das Konto muss außerdem aktiv sein: pausierte, abgelaufene, in ihrem Limit erschöpfte und auf die erste Zahlung wartende Konten (on_hold — also alle, die sich selbst registriert und noch nicht bezahlt haben) werden abgelehnt. Die E-Mail muss die Absender-Authentifizierung bestehen und darf nur den Anruf-Link enthalten.
Im Kundenkonto wird jede Ablehnung mit ihrem Grund angezeigt; auf eine E-Mail kommt eine Antwort, wenn wir den Absender als deinen Nutzer erkennen können (ein nicht authentifizierter oder unbekannter Absender bekommt keine Antwort). Beschwert sich jemand mit „Ich habe angefragt und nichts ist passiert“, fang beim Kontostatus und beim verwendeten Anruf-Link an; beim Weg per E-Mail prüfe außerdem, ob die Mail von der Kontoadresse kam und nur den Link enthielt.
Multi-Hop-Routen nehmen nicht teil. Für Notfallsitzungen werden nur direkte Routen verwendet.
Der Notfall-Client ist Ghostlane, auch für das iPhone. Er ist im App Store und bei Google Play erhältlich und hat Builds für Windows, macOS und Linux. Nutzer, die das alte olcbox installiert haben, müssen umsteigen: olcbox wird nicht mehr aktualisiert und kennt weder SaluteJazz noch VK Calls, und seinen älteren Versionen fehlt die neue Verschlüsselung. Mehr dazu in der Installationsanleitung.
Wie du es abschaltest
Schalte „Notfallroute (OLCRTC)“ bei allen Notfallrouten des Clusters aus oder lösche diese Routen — dann schaltet sich der Notfallzugang des Clusters aus, und es werden keine neuen Sitzungen mehr gestartet. Bereits laufende Sitzungen laufen ihre Frist zu Ende.
Ist dein Pro-Abonnement ausgelaufen, kannst du alles noch abschalten, aber zum Wiedereinschalten musst du es verlängern.