CreateYourVPN Academy
Kurs: So funktioniert es

Notfallzugang: wenn das Netz alles blockiert

Der Notfallzugang (OLCRTC) in CreateYourVPN: ein Ersatzkanal, getarnt als Videoanruf, für Netze mit Allowlist — was er deine Server kostet, was sich mit Pro von selbst einschaltet und was du deinen Nutzern vorab sagen solltest.

Alles bisher setzte eines voraus: dass das Netz deine Server überhaupt noch durchlässt. Eine Route wählt einen Server, ein Inbound lässt die Verbindung wie einen gewöhnlichen HTTPS-Besuch aussehen, Multihop zieht den Weg über mehrere Länder — all das braucht Traffic, der das Gerät überhaupt verlässt.

Manchmal tut er das nicht. Ein Netz stellt auf Allowlist um: Eine kurze Liste erlaubter Dienste funktioniert, alles andere — dein VPN eingeschlossen — kommt schlicht nicht durch. Genau für diese Stunden ist der Notfallzugang (OLCRTC) gebaut.

Was er ist — und was nicht

Der Notfallzugang ist ein Ersatzkanal, kein zweites Protokoll. Die normale Verbindung bleibt, was sie war: VLESS + Reality auf deinen eigenen Servern. Der Notfallzugang nutzt dieselben Server, verpackt den Traffic aber in einen Videoanruf bei einem Dienst, den das eingeschränkte Netz noch erlaubt — von außen sieht das wie eine gewöhnliche Videokonferenz aus.

Daraus folgen drei Dinge, und alle drei solltest du kennen, bevor du etwas versprichst:

  • Der Nutzer startet ihn von Hand, nur wenn sonst nichts mehr geht. Es gibt kein automatisches Umschalten: Die normale Verbindung „springt“ nicht von selbst hinüber.
  • Er ist langsam. Etwa 14 Mbit/s im Download, unter einem Megabit im Upload, 175–235 ms Latenz. Bequem zum Lesen und für Video, unbrauchbar für Uploads, Videocalls und Spiele.
  • Er ist befristet. Eine Sitzung lebt bis zu 12 Stunden und endet dann von selbst; pro Nutzer läuft eine gleichzeitig; zum Weitermachen startet er eine neue.

Die Funktion ist experimentell. Sie hängt davon ab, ob ein externer Videodienst aus dem eingeschränkten Netz erreichbar ist — sie funktioniert also nicht in jedem Land und nicht in jedem Netz. Präsentiere sie deinen Nutzern als Versicherung gegen harte Sperren, nicht als garantierte Möglichkeit.

Wie es aus Sicht des Nutzers aussieht

  1. Er erstellt einen frischen Videoanruf in einem unterstützten Dienst — Yandex Telemost, WB Stream oder Jitsi Meet.
  2. Er übergibt dessen Link: eingefügt in den Block Notfallzugang in seinem Konto oder per E-Mail an eine persönliche Anfrageadresse geschickt. Beide Wege tun dasselbe — und der E-Mail-Weg funktioniert noch, wenn dein Portal bereits blockiert ist.
  3. Einer deiner Server tritt diesem Anruf als Gast bei. Nach etwa einer Minute bekommt der Nutzer einen Verbindungslink, der mit olcrtc:// beginnt, plus einen QR-Code.
  4. Er importiert ihn in olcbox, die Notfall-App, und verbindet sich.

Beides, was der Nutzer braucht — die App und die Anfrageadresse —, muss vor der Sperre bei ihm liegen. Unter einer Allowlist sind App-Stores und Download-Seiten meist nicht erreichbar, und das Konto, in dem die Adresse steht, öffnet sich womöglich auch nicht mehr. Wer vom Notfallzugang erst während der Sperre erfährt, erfährt zu spät davon.

Was du dafür brauchst

  • Ein Pro-Abo — 0,99 € pro Monat. Mit dieser Stufe kommt der Notfallzugang; Max hat ihn ebenfalls, zusammen mit allem anderen (Lektion 13).
  • Eine Notfallroute. Die Server der als Notfall markierten Routen bilden den Pool, auf dem die Sitzungen landen. Beim ersten Abo markiert das System eine für dich — die Route mit den meisten funktionierenden Inbounds — und legt gleich den Cluster-Schalter um.
  • Die Server. Sie machen standardmäßig mit, und die Runtime installiert und aktualisiert sich im Hintergrund: nichts per SSH einzurichten.

Im Normalfall gibt es also nichts zu konfigurieren: Abo abgeschlossen, Notfallzugang läuft. Die manuellen Schalter sind für den Fall da, dass du sie brauchst: welche Routen den Pool bilden, wie viele Sitzungen ein Server hält und ob einer außen vor bleiben soll.

Was ihn von einer normalen Route unterscheidet

  • Der Nutzer wählt kein Land. Er sieht den Pool gar nicht — die geografische Absicht drückst du aus, indem du bestimmte Routen als Notfall markierst. Du kannst mehrere markieren: Der Pool führt sie zusammen, und findet sich in einer kein passender Server, geht die Sitzung auf eine andere.
  • Multihop-Routen machen nicht mit. Für Notfallsitzungen werden nur direkte Routen genommen.
  • Eine Sitzung kostet echte CPU. Das Verpacken des Traffics in einen Videostream brauchte in der Messung rund 15 % eines Kerns und 31 MB Speicher (Videositzung mit ~5 Mbit/s) — deutlich mehr als ein weiterer VPN-Nutzer. Faustregel: 3 Sitzungen pro Kern, also 3 auf einem Einkern-Server, 6–7 bei zwei Kernen, 12–14 bei vier.

Ein leeres Feld „Max. gleichzeitige Sitzungen“ bedeutet kein Limit. Auf einem schwachen Server ist das eine Falle: Die Notfallsitzungen fressen die CPU, für die deine regulären Kunden zahlen. Auf Einkern-Maschinen trage die Zahl ausdrücklich ein.

Welche deiner Nutzer ihn tatsächlich nutzen können

Die Anforderungen sind strenger, als sie aussehen — und genau daher kommen die Support-Fragen:

  • Bestätigte E-Mail. Nutzer, die du ohne E-Mail-Adresse von Hand angelegt hast, können gar nichts anfragen.
  • Aktives Konto. Pausierte, abgelaufene, beim Traffic-Limit angekommene und auf die erste Zahlung wartende Konten (alle, die sich selbst registriert und noch nicht gezahlt haben) werden abgelehnt.

Die Beschwerde, die du hören wirst, klingt nach „Ich habe angefragt und es ist nichts passiert“. Fang beim Kontostatus und dem verwendeten Anruf-Link an; beim E-Mail-Weg prüfe zusätzlich, ob die Mail von der Kontoadresse kam und nur den Link enthielt.

Zu merken

  • Der Notfallzugang ist ein Rettungsring für Netze mit Allowlist, kein zweites Protokoll und kein Ersatz für die normale Verbindung.
  • Der Traffic läuft über deine eigenen Server, getarnt als Videoanruf, den der Nutzer selbst erstellt.
  • Langsam, bis zu 12 Stunden, eine Sitzung pro Nutzer, manueller Start.
  • Mit Pro schaltet er sich selbst ein: Eine Route wird als Notfall markiert, der Cluster-Schalter geht hoch, Server machen standardmäßig mit.
  • Eine Sitzung ≈ 15 % eines CPU-Kerns — auf schwachen Servern die Kapazität ausdrücklich setzen.
  • Der Nutzer braucht eine bestätigte E-Mail, ein aktives Konto und die vorab installierte App.

Weiter

Beim Notfallzugang geht es darum, was zu tun ist, wenn das Netz kaputtgeht. Die nächste Lektion handelt von der anderen Hälfte: wie das System merkt, dass deine Server kaputtgegangen sind.

On this page