Notfallzugang aktivieren
Richte den Notfallzugang (OLCRTC) für deine Nutzer ein: Pro-Abonnement, eine Notfallroute, der Cluster-Schalter 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 ist experimentell und 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 und E-Mail erreichbar sind. 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;
- den OLCRTC-Schalter am Cluster aktiviert;
- mindestens einen Server dieses Clusters 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 drei Schalter an drei verschiedenen Stellen, und sie lassen sich leicht verwechseln — zwei davon heißen fast gleich.
| Was du aktivierst | Wo es liegt | Wie es heißt |
|---|---|---|
| Route | Routeneinstellungen (beim Bearbeiten) | „Notfallroute (OLCRTC)“ |
| Cluster | Cluster-Seite, über der Routenliste | „OLCRTC für diesen Cluster aktivieren“ |
| Server | Server-Panel, Schaltfläche „Bearbeiten“ | „OLCRTC auf diesem Server ausführen“ |
Die Reihenfolge zählt: Der Cluster lässt dich OLCRTC nicht aktivieren, solange es keine Notfallroute gibt. Erst die Route, dann der Cluster.
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 im Block „Notfallzugang (OLCRTC)“ 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.
Aktiviere OLCRTC für den gesamten Cluster. Das ist ein zweiter, separater Schalter — nicht der aus der Route. Er liegt auf der Cluster-Seite, im Block „Notfallzugang“ mit der Kennzeichnung OLCRTC, direkt über der Routenliste, und heißt „OLCRTC für diesen Cluster aktivieren“.
Das ist der Hauptschalter: Solange er aus ist, können die Nutzer des Clusters nichts anfordern, egal wie viele Routen du als Notfallrouten markiert hast. Unter dem Schalter siehst du, wie viele Notfallrouten bereits im Pool sind.
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 (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 sendet eine neue E-Mail.
Eine Sitzung pro Nutzer. Eine zweite E-Mail erzeugt nichts und bekommt keine Antwort — das erklärst du deinen Nutzern besser vorab, damit es nicht wie ein Defekt wirkt.
Etwa 14 Mbit/s im Download und unter einem Megabit im Upload, bei 175–235 ms Latenz. Videos schauen und E-Mails bearbeiten ist komfortabel; große Dateien senden, Videoanrufe und Gaming nicht. Das ist die Obergrenze der aktuellen Tunnelkonfiguration, nicht die der Hauptverbindung.
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 die Häufigkeit ist begrenzt: fünf Anfragen pro Stunde und Nutzer und hundert für den gesamten Dienst.
Ablehnungen bei diesen Prüfungen erfolgen stillschweigend: Der Nutzer bekommt überhaupt keine Antwort. Beschwert sich jemand mit „Ich habe die E-Mail geschickt und nichts kam zurück“, fang beim Kontostatus an und bei der Frage, ob der richtige Anruf-Link gesendet wurde.
Multi-Hop-Routen nehmen nicht teil. Für Notfallsitzungen werden nur direkte Routen verwendet.
iPhone ist schwieriger. Die iOS-App lässt sich nur per Sideload installieren — Apple führt sie nicht. Deine iPhone-Nutzer müssen sich im Voraus und sorgfältiger vorbereiten; die Installationsanleitung erklärt das.
Wie du es abschaltest
Du kannst OLCRTC für diesen Cluster aktivieren jederzeit wieder abwählen — dann werden keine neuen Sitzungen mehr gestartet. Bereits laufende Sitzungen laufen ihre Frist zu Ende.
Die letzte Notfallroute lässt sich bei aktivem OLCRTC weder demarkieren noch löschen: Markiere zuerst eine andere Route oder schalte OLCRTC am Cluster aus.
Ist dein Pro-Abonnement ausgelaufen, kannst du alles noch abschalten, aber zum Wiedereinschalten musst du es verlängern.