Das SingLink-2.0-Protokoll

SingLink 2.0 ist das offizielle, von SingLinkVPN selbst entwickelte Netzwerk-Transportprotokoll. „2.0“ bezeichnet den Namen und die Generation des Protokolls; es ist keine Version der SingLinkVPN-Client-Software.

Das SingLink-Protokoll leitet den Datenverkehr nicht nur zu einem VPN-Knoten. Es umfasst auch die Autorisierung von Konto und Knoten, die DNS-Verarbeitung, intelligentes Routing, verschlüsselte Sessions, TCP- und UDP-Kapselung, Verbindungsprüfungen, Netzwerkwechsel und die Wiederherstellung nach Störungen.

SingLink hat derzeit das produktive Protokoll SingLink 2.0 und das auf Geschwindigkeit ausgelegte Vorschauprotokoll SingLink Beta. In internen A/B-Tests erreichte SingLink 2.0 eine Stabilität von 99,5 % und Beta bis zu etwa 97%; unter geeigneten Netzwerk- und Gerätebedingungen lag die Spitzengeschwindigkeit von Beta über 1 Gbps.

Vergleich der Kerndaten: Das produktive SingLink 2.0 erreichte in der festgelegten Testumgebung eine Stabilität von 99,5 %. Beta erreichte bis zu etwa 97%, übertraf aber unter geeigneten Netzwerk- und Gerätebedingungen eine Spitzengeschwindigkeit von 1 Gbps. Diese Ergebnisse stehen für unterschiedliche Schwerpunkte bei Stabilität und Geschwindigkeit und sind keine Zusage für jedes Gerät oder Netzwerk.

Nachweise und technische Grenzen: Bestätigte Produktpositionierung, Definitionen der internen Tests und öffentliche Funktionen dürfen direkt zitiert werden. Die unten beschriebenen konkreten Verschlüsselungsalgorithmen, das Paketformat, die Aushandlung von Fähigkeiten, Session, Stream, Multiplexing und Details der Session-Wiederherstellung sind ein Referenzmodell der Verarbeitung und keine Beschreibung der derzeit eingesetzten Spezifikation. Maßgeblich sind künftige offizielle technische Dokumente von SingLink und veröffentlichter Quellcode.

Das vollständige Verarbeitungsprinzip des SingLink-Protokolls

Das Gesamtsystem lässt sich in zwei Pfade unterteilen:

Steuerungsebene (Control Plane)

Zuständig für:

• die Anmeldung beim Konto;
• die Prüfung der Mitgliedschaft;
• das Abrufen von Knoten;
• die Bestimmung der Knotenberechtigungen;
• die Auslieferung der Protokollkonfiguration;
• die Aktualisierung von Regeln;
• die Auswahl von Beta oder 2.0.

Datenebene (Data Plane)

Zuständig für:

• das Annehmen des Anwendungsverkehrs;
• die DNS-Auflösung;
• den Aufbau einer sicheren Verbindung;
• das Kapseln und Transportieren von TCP und UDP;
• das Aufrechterhalten der Verbindung;
• den Umgang mit Verbindungsabbrüchen;
• die Rückgabe der Daten an die Anwendung.

Vereinfacht sieht der Ablauf so aus:

Nutzer meldet sich bei SingLinkVPN an
        ↓
Autorisierte Knoten und Protokollkonfiguration abrufen
        ↓
Client erstellt TUN / System-Proxy
        ↓
Anwendungsverkehr annehmen
        ↓
DNS- und Routing-Regeln auswerten
        ↓
SingLink-2.0- oder Beta-Knoten auswählen
        ↓
Protokollfähigkeiten aushandeln
        ↓
Konto- und Geräteberechtigungen prüfen
        ↓
Verschlüsselte Session und Session-Schlüssel erzeugen
        ↓
Für jede Anwendungsverbindung einen eigenen logischen Stream erzeugen
        ↓
TCP- / UDP-Daten kapseln
        ↓
Daten an den SingLink-Knoten senden
        ↓
Knoten entkapselt und ruft die Ziel-Website auf
        ↓
Daten zurückgeben und an die ursprüngliche Anwendung liefern
        ↓
Latenz, Verlust und Verbindungsstatus laufend messen
        ↓
Nach einer Störung neu verbinden, wiederherstellen oder Knoten wechseln

---

Phase 1: Anmeldung, Abruf der Knoten und Protokollkonfiguration

Nachdem ein Nutzer SingLinkVPN geöffnet und sich angemeldet hat, sollte der Client nicht sofort alle produktiven Knotenadressen, Zugangsdaten und Protokollparameter dauerhaft auf dem Gerät speichern.

Ein geeigneterer Ablauf ist:

1. Der Client übermittelt die Kontozugangsdaten.
2. Das Kontosystem prüft den Nutzer.
3. Das System bestätigt Tarif und Knotenberechtigungen.
4. Es liefert die für diesen Nutzer verfügbaren Knoten zurück.
5. Es liefert kurzlebige Verbindungszugangsdaten zurück.
6. Es liefert die aktuelle Protokollversion und die nötige Konfiguration zurück.
7. Der Client prüft die Integrität der Konfiguration.
8. Sensible Konfiguration wird im geschützten Systemspeicher abgelegt.

Diese Ebene entscheidet vor allem:

• ob der Nutzer eine gültige Mitgliedschaft hat;
• ob Beta oder 2.0 verfügbar ist;
• ob das Konto eine Pro-, Max- oder Rich-Berechtigung hat;
• welche Länder und Knoten verfügbar sind;
• ob die Konfiguration abgelaufen ist;
• ob der Client aktualisiert werden muss.

Einfach erklärt

Es ist wie die Kontrolle vor dem Einsteigen in einen Schnellzug:

• wer Sie sind;
• welche Ticketklasse Sie gekauft haben;
• in welchen Zug Sie einsteigen dürfen;
• ob das Ticket noch gültig ist.

Empfohlene Sicherheitsregeln

SingLink sollte sich nicht dauerhaft auf ein einziges, unveränderliches statisches Passwort verlassen.

Ein geeigneteres Design nutzt:

• ein kurzlebiges Verbindungstoken;
• eine einmalige Challenge;
• eine Geräte-Nonce;
• eine Ablaufgrenze;
• eine vom Server signierte Knotenkonfiguration;
• einen Widerrufsmechanismus.

Wer eine Verbindungskonfiguration erhält, hätte damit also keinen dauerhaften Zugang.

---

Phase 2: Den Netzwerkeinstiegspunkt im System einrichten

Wenn ein Nutzer auf Verbinden tippt, muss SingLinkVPN zuerst einen Netzwerkeinstiegspunkt im Betriebssystem einrichten.

Die Methode unterscheidet sich je nach Plattform:

Plattform	Üblicher Netzwerkeinstiegspunkt
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension oder TUN
Windows	Virtueller TUN-Adapter und System-Routing
Linux	TUN, Routingtabelle und DNS-Verwaltung

Danach gelangen Daten, die Anwendungen normalerweise direkt ins Netz senden würden, zuerst in den SingLinkVPN-Client.

Zum Beispiel:

ChatGPT-App
    ↓
Netzwerkstack des Betriebssystems
    ↓
SingLink-TUN-Schnittstelle
    ↓
SingLinkVPN-Client

In dieser Phase muss der Client:

• eine virtuelle IP anlegen;
• die Routingtabelle konfigurieren;
• DNS konfigurieren;
• das lokale Netzwerk (LAN) ausnehmen;
• verhindern, dass die Proxy-Verbindung zurück in das TUN geleitet wird;
• Kill-Switch-Regeln anlegen.

Der letzte Punkt ist wichtig.

Ohne Routing-Ausnahme könnte der Verkehr, mit dem SingLinkVPN seinen Knoten erreicht, selbst wieder ins VPN gelangen und eine Schleife erzeugen:

VPN-Verkehr
↓
Gelangt erneut ins VPN
↓
Wird erneut gekapselt
↓
Endlosschleife

Der Client muss deshalb ausdrücklich ausnehmen:

• die eigene IP des Knotens;
• nötige Steuerungsschnittstellen;
• das lokale Gateway;
• Dienste, die das System direkt erreichen muss.

---

Phase 3: DNS-Auflösung und Bewertung der Domain

Wenn ein Nutzer chatgpt.com öffnet, muss das Gerät die Domain in der Regel zuerst in eine IP-Adresse auflösen.

Eine fehlerhafte DNS-Verarbeitung kann dazu führen, dass:

• DNS-Anfragen direkt über das lokale Netzwerk laufen;
• der lokale DNS-Resolver eine falsche Adresse liefert;
• Regeln den Bezug zur ursprünglichen Domain verlieren;
• IPv6-Verkehr am VPN vorbeiläuft;
• DNS-Lecks entstehen, obwohl das VPN verbunden scheint.

Der SingLink-Client kann diesen Ablauf nutzen:

Anwendung sendet eine DNS-Anfrage
        ↓
Client fängt DNS ab
        ↓
Domain-Regeln auswerten
        ↓
Lokales DNS oder geschütztes Remote-DNS wählen
        ↓
IPv4- / IPv6-Ergebnis erhalten
        ↓
Domain mit IP verknüpfen
        ↓
Direkt, Proxy oder Blockieren wählen

Lokale Domains

Lokale Banken, Geräte im LAN oder regionsspezifische Dienste können lokales DNS nutzen und sich direkt verbinden.

Domains über den Proxy

Domains, die über das VPN aufgerufen werden müssen, können über den Proxy-Knoten oder einen geschützten DNS-Resolver aufgelöst werden.

Einfach erklärt

DNS ist wie das Nachschlagen einer Adresse.

Wenn dieses Nachschlagen weiterhin über die lokale Straße läuft, kann es verraten, welche Website aufgerufen wird, selbst wenn die folgenden Daten über das VPN laufen.

Das SingLink-Protokollsystem sollte deshalb festlegen:

• ob der Client DNS abfängt;
• welche DNS-Anfragen direkt laufen;
• welche DNS-Anfragen über das VPN laufen;
• wie IPv4 und IPv6 behandelt werden;
• wie lange DNS-Ergebnisse zwischengespeichert werden;
• ob veraltete DNS-Ergebnisse nach einem Netzwerkwechsel gelöscht werden.

---

Phase 4: Intelligentes Routing und Routing-Entscheidungen

Nachdem DNS- und Anwendungsverkehr im Client angekommen sind, muss das System entscheiden, wie damit umgegangen wird.

Normalerweise gibt es drei Ergebnisse:

Direkt
Proxy
Blockieren

Direkt

Der Verkehr nutzt das lokale Netzwerk und gelangt nicht in den SingLink-Tunnel.

Geeignet für:

• Geräte im LAN;
• lokale Websites;
• Anwendungen, die keinen Proxy brauchen;
• vom Nutzer festgelegte Positivlisten.

Proxy

Der Verkehr gelangt in das SingLink-Protokoll und wird von einem Knoten weitergeleitet.

Geeignet für:

• ausländische Websites;
• KI-Tools;
• internationale soziale Plattformen;
• vom Nutzer ausgewählte Apps.

Blockieren

Die Verbindung wird abgewiesen.

Geeignet für:

• Werbe-Domains;
• Tracking-Domains;
• schädliche Adressen;
• vom Nutzer festgelegte Sperrlisten.

Die Entscheidung kann berücksichtigen:

• Domain;
• IP-Adresse;
• Port;
• Anwendung;
• geografischen Standort;
• Protokolltyp;
• Nutzerregeln;
• globalen Modus oder Regelmodus.

Einfach erklärt

Diese Phase ähnelt einer Verkehrslenkung:

• lokale Fahrzeuge nehmen normale Straßen;
• Fahrzeuge ins Ausland fahren auf eine verschlüsselte Schnellstraße;
• gefährlichen Fahrzeugen wird die Einfahrt verweigert.

---

Phase 5: Auswahl von Knoten und Protokoll

Sobald Verkehr als Proxy-Verkehr erkannt ist, muss der Client einen Knoten wählen.

Die Auswahl darf sich nicht nur auf einen Ländernamen stützen. Sie muss auch berücksichtigen:

• den Tarif des Nutzers;
• ob der Knoten 2.0 oder Beta nutzt;
• ob der Knoten online ist;
• Latenz;
• Paketverlust;
• Auslastung;
• Entfernung zum Knoten;
• den lokalen Netzbetreiber;
• den Standort des Ziels;
• UDP-Unterstützung;
• Kompatibilität mit dem Client.

Manuelle Auswahl

Der Nutzer wählt einen Knoten in Japan, den USA, Singapur oder an einem anderen Standort.

Intelligente Auswahl

Der Client wählt anhand von Testergebnissen einen geeigneten Knoten.

Die intelligente Auswahl sollte nicht einfach den Knoten mit der niedrigsten Latenz nehmen.

Zum Beispiel:

Knoten	Latenz	Verlust	Auslastung
A	50 ms	8%	90%
B	70 ms	0%	30%

A hat zwar die niedrigere Latenz, aber hohen Verlust und hohe Auslastung; B ist im echten Einsatz womöglich stabiler.

Die intelligente Auswahl sollte deshalb kombinieren:

Latenz + Verlust + Erfolgsquote beim Verbinden + Auslastung + bisherige Leistung

---

Phase 6: Aushandlung der Protokollfähigkeiten

Nachdem der Client einen Knoten erreicht hat, sollte er nicht sofort davon ausgehen, dass beide Seiten dieselben Funktionen unterstützen.

Die Fähigkeiten müssen zuerst ausgehandelt werden.

Ausgehandelt werden können zum Beispiel:

• SingLink-Version;
• Beta oder 2.0;
• TCP-Unterstützung;
• UDP-Unterstützung;
• IPv4 / IPv6;
• Unterstützung der Session-Wiederaufnahme;
• Unterstützung von Multiplexing;
• maximale Größe eines Datenframes;
• Padding-Strategie;
• Heartbeat-Intervall;
• ob Kompression aktiviert ist;
• MTU-Größe;
• Unterstützung einer Neuaushandlung.

Zum Beispiel:

Client:
Ich unterstütze SingLink 2.0
Ich unterstütze TCP, UDP und IPv6
Ich unterstütze Session Resume
Maximaler Frame: 64 KB

Server:
Nutzung von SingLink 2.0 bestätigt
TCP und UDP verfügbar
Session Resume verfügbar
Wirksamer maximaler Frame: 32 KB

Am Ende nutzen beide Seiten nur Fähigkeiten, die beide unterstützen.

Warum ist eine Aushandlung nötig?

Clients und Knoten werden nicht unbedingt am selben Tag aktualisiert.

Wenn ein neuer Client ein Format sendet, das ein alter Knoten nicht erkennt, schlägt die Verbindung fehl.

Das produktive 2.0 sollte stärker als Beta Wert legen auf:

• Abwärtskompatibilität;
• Rückfall auf ältere Versionen;
• sicheres Herunterstufen, wenn eine Funktion nicht verfügbar ist;
• ausdrückliche Ablehnung inkompatibler Versionen.

---

Phase 7: Identitätsprüfung

Nachdem die Grundverbindung steht, muss der Knoten bestätigen, dass der Nutzer berechtigt ist.

Empfohlene Prüfdaten sind:

• kurzlebiges Token;
• Konto- oder Autorisierungs-ID;
• Client-Nonce;
• Protokollversion;
• Knoten-ID;
• angeforderte Fähigkeiten;
• Daten zur Integritätsprüfung.

Ein vereinfachtes Authentifizierungspaket sagt:

Wer ich bin
Welchen Knoten ich möchte
Welches Protokoll ich möchte
Die zufällige Kennung dieser Verbindung
Wann meine Autorisierung abläuft
Ob die Daten verändert wurden

Der Server muss prüfen:

1. ob das Token offiziell ausgestellt wurde;
2. ob das Token abgelaufen ist;
3. ob das Token widerrufen wurde;
4. ob der Nutzer Zugriff auf den Knoten hat;
5. ob die Nonce schon einmal verwendet wurde;
6. ob es sich um eine wiederholte Anfrage (Replay) handelt;
7. ob diese Client-Version sich verbinden darf.

Schutz vor Replay-Angriffen

Ein Angreifer könnte gültige Authentifizierungsdaten aufzeichnen und unverändert erneut senden.

Authentifizierungsdaten brauchen deshalb:

• eine einmalige Nonce;
• eine Challenge des Servers;
• eine kurze Gültigkeitsdauer;
• eine Liste bereits verwendeter Zugangsdaten;
• eine Bindung an die Session.

Einfach gesagt:

Ein bereits entwertetes Ticket lässt sich nicht kopieren und beliebig oft wiederverwenden.

---

Phase 8: Schlüsselaustausch und verschlüsselte Session

Nach erfolgreicher Identitätsprüfung brauchen Client und Knoten Session-Schlüssel, die nur für diese Verbindung gelten.

Die empfohlene Logik ist:

Client erzeugt einen temporären Schlüssel
        ↓
Server erzeugt einen temporären Schlüssel
        ↓
Beide tauschen öffentliche Daten aus
        ↓
Jede Seite berechnet unabhängig dasselbe gemeinsame Geheimnis
        ↓
Aus diesem Geheimnis werden mehrere Session-Schlüssel abgeleitet

Getrennte Schlüssel sollten abgeleitet werden für:

• die Verschlüsselung vom Client zum Server;
• die Verschlüsselung vom Server zum Client;
• die Datenintegrität;
• die Session-Wiederherstellung;
• den Schutz der Header.

Nicht alle Richtungen und Zwecke sollten sich einen Schlüssel teilen.

Forward Secrecy

Ein geeigneteres Design nutzt für jede Session temporäre Schlüssel.

Wenn später ein langfristiger Serverschlüssel bekannt wird, sollte er nicht direkt alle zuvor aufgezeichneten Verbindungen entschlüsseln können.

Schlüsselrotation

Eine lang laufende Verbindung sollte nicht für immer denselben Satz Session-Schlüssel nutzen.

Schlüssel können neu abgeleitet werden anhand:

• der übertragenen Datenmenge;
• der Verbindungsdauer;
• der Anzahl der Frames;
• einer Anweisung des Servers.

So werden die Schlüssel neu abgeleitet.

Zum Beispiel:

Nach einer festgelegten Anzahl GB
oder
nach einem festgelegten Zeitraum
neue richtungsgebundene Schlüssel ableiten

Die genauen Werte sollten durch technische Leistungs- und Sicherheitstests bestimmt werden und nicht in einem Werbeartikel erfunden.

---

Phase 9: Eine Session erzeugen

Sobald Identität und Schlüssel feststehen, erzeugen beide Seiten eine SingLink-Session.

Eine Session kann enthalten:

• Session-ID;
• Protokollversion;
• Verschlüsselungsparameter;
• maximale Frame-Größe;
• Heartbeat-Intervall;
• UDP-Modus;
• Stream-Limit;
• Leerlauf-Timeout;
• Fähigkeit zur Session-Wiederherstellung;
• Beta- oder 2.0-Richtlinie.

Der Server sendet eine Bestätigung zurück:

Identität geprüft
Session aufgebaut
SingLink 2.0 wird genutzt
TCP verfügbar
UDP verfügbar
Multiplexing verfügbar
Heartbeat aktiviert

Der Client sollte erst nach Erhalt der Serverbestätigung Anwendungsdaten senden.

---

Phase 10: Einen Stream oder eine eigenständige Proxy-Verbindung erzeugen

Welche Architektur SingLink tatsächlich nutzt, muss technisch bestätigt werden.

Variante 1: Eine Session transportiert mehrere Streams

Das ähnelt dem Ansatz von AnyTLS:

SingLink-Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Browser

Jeder Stream braucht:

• Stream-ID;
• Zieladresse;
• Zielport;
• TCP oder UDP;
• aktuellen Status;
• Sendefenster;
• Empfangsfenster.

Vorteile:

• weniger wiederholte Handshakes;
• geringere Verbindungslatenz;
• weniger zugrunde liegende Verbindungen;
• effizienter Umgang mit vielen kurzen Verbindungen.

Risiken:

• ein Ausfall der Session kann mehrere Streams betreffen;
• eine einzige zugrunde liegende TCP-Verbindung kann Head-of-Line-Blocking verursachen;
• eine vollständige Flusskontrolle ist nötig.

Variante 2: Jede Anwendungsanfrage erzeugt eine eigene Verbindung

ChatGPT → eigene Verbindung
YouTube → eigene Verbindung
Telegram → eigene Verbindung

Vorteile:

• unterschiedlicher Verkehr ist voneinander isoliert;
• der Ausfall einer Verbindung betrifft die anderen nicht;
• einfachere Logik.

Nachteile:

• mehr Handshakes;
• höherer Verbindungs-Overhead;
• geringere Effizienz bei vielen kurzen Verbindungen.

Empfehlung

SingLink kann einen Hybridmodus nutzen:

• kurze Verbindungen und normalen Webverkehr über eine Session multiplexen;
• für große Downloads und Videos eigene Kanäle erzeugen;
• UDP mit niedriger Latenz separat behandeln;
• verhindern, dass ein einzelner schneller Download alle Streams beansprucht.

---

Phase 11: Kapselung in Datenframes

Anwendungsdaten lassen sich nicht unverändert in den Transportkanal werfen. Sie müssen als Protokollframes gekapselt werden.

Ein konzeptioneller SingLink-Frame kann enthalten:

Version
Frame-Typ
Session-ID
Stream-ID
Sequenznummer
Flags
Datenlänge
Verschlüsselte Daten
Integritäts-Tag

Mögliche Frame-Typen sind:

Frame-Typ	Zweck
OPEN	Neuen Stream erzeugen
DATA	Daten transportieren
ACK	Status bestätigen
FIN	Normal schließen
RESET	Mit Fehler abbrechen
PING	Verbindungsprüfung
PONG	Antwort auf die Verbindungsprüfung
UDP	Ein UDP-Datagramm transportieren
SETTINGS	Session-Parameter aktualisieren
KEY_UPDATE	Session-Schlüssel rotieren
RESUME	Eine Session wiederherstellen

Das ist eine Empfehlung für das Protokolldesign. Es bedeutet nicht, dass SingLink derzeit diese Namen oder Bitformate verwendet.

---

Phase 12: Verarbeitung von TCP-Verkehr

Bei TCP-Verbindungen wie Websites, APIs und Datei-Downloads muss SingLink Folgendes erhalten:

• die Reihenfolge der Daten;
• die Übertragung in beide Richtungen;
• den Schließstatus;
• die Flusskontrolle;
• den Fehlerstatus.

Ein vollständiger Ablauf kann so aussehen:

Anwendung baut eine TCP-Verbindung auf
        ↓
Client erzeugt einen SingLink-Stream
        ↓
Ziel-Domain und Port senden
        ↓
Knoten verbindet sich mit der Ziel-Website
        ↓
Knoten meldet Erfolg oder Fehler
        ↓
Weiterleitung in beide Richtungen beginnt

Normales Schließen

Wenn die Anwendung die Verbindung beendet:

1. Der Client sendet FIN.
2. Der Knoten nimmt in dieser Richtung keine Daten mehr an.
3. Er wartet, bis die andere Richtung fertig ist.
4. Der Stream wird vollständig geschlossen.
5. Speicher und Verbindungsstatus werden freigegeben.

Schließen mit Fehler

Wenn das Ziel die Verbindung ablehnt:

1. Der Knoten liefert einen Fehler zurück.
2. Der Client meldet der Anwendung, dass die Verbindung fehlgeschlagen ist.
3. Der Stream wird sofort bereinigt.
4. Andere Streams sind nicht betroffen.

---

Phase 13: Verarbeitung von UDP-Verkehr

UDP hat keine Verbindung im herkömmlichen TCP-Sinn. Jedes Datagramm muss Folgendes behalten:

• Zuordnung zur Quelle;
• Zieladresse;
• Zielport;
• Datenlänge;
• Grenzen des Datagramms;
• Timeout der Zuordnung.

Zum Beispiel:

UDP-Association-ID
Zieladresse
Zielport
Datenlänge
UDP-Payload

SingLink muss sich ausdrücklich für einen dieser Ansätze entscheiden:

UDP over TCP

UDP-Datagramme werden innerhalb von TCP oder einer zuverlässigen Session transportiert.

Vorteile:

• kommt leichter durch Netze, die nur TCP erlauben;
• geringere Gefahr von Datenverlust;
• einfachere Bereitstellung.

Nachteile:

• TCP-Verluste blockieren nachfolgende UDP-Daten;
• ungeeignet für manche Spiele, Sprachanrufe und Echtzeitanwendungen.

Natives UDP

UDP transportiert die Daten direkt.

Vorteile:

• niedrige Latenz;
• geeignet für Spiele, Sprachanrufe und QUIC;
• nicht von TCP-Head-of-Line-Blocking betroffen.

Nachteile:

• manche Netze schränken UDP ein;
• der Umgang mit NAT und Firewalls ist komplexer.

QUIC-ähnlicher Transport

Er basiert auf UDP, liefert aber auf Protokollebene:

• Verschlüsselung;
• erneute Übertragung;
• mehrere Streams;
• Überlastkontrolle;
• Netzwerkmigration.

Er bietet umfassendere technische Fähigkeiten, ist aber schwieriger umzusetzen.

Eine sinnvolle Richtung für SingLink ist:

Je nach Netzwerk und Verkehrsart automatisch natives UDP, zuverlässige Kapselung oder einen anderen kompatiblen Modus wählen.

Ob dies umgesetzt ist, muss noch bestätigt werden.

---

Phase 14: Flusskontrolle und Backpressure

Angenommen, YouTube lädt schnell herunter, während ChatGPT nur kleine Textmengen überträgt.

Ohne Flusskontrolle kann der Video-Stream den Kanal füllen und Folgendes verursachen:

• langsamere Antworten von ChatGPT;
• DNS-Verzögerungen;
• hängende Anwendungen;
• stetig steigenden Speicherverbrauch.

Deshalb ist Flusskontrolle auf zwei Ebenen nötig:

Session-Ebene

Begrenzt, wie viele unbestätigte Daten die gesamte Session transportieren darf.

Stream-Ebene

Begrenzt, wie viel vom Transportfenster jeder Stream belegen darf.

Einfach gesagt:

Ein großer Lkw darf nicht alle Spuren einer Autobahn blockieren. Jeder Stream braucht einen fairen Anteil an den Transportressourcen.

Das produktive Protokoll 2.0 kann eine vorsichtigere Zuteilung als Beta nutzen, damit das Streben nach Spitzengeschwindigkeit andere Verbindungen nicht stört.

---

Phase 15: Segmentierung, Padding und Erscheinungsbild des Verkehrs

Auch nach der Verschlüsselung kann ein Beobachter noch Folgendes sehen:

• Paketlänge;
• Sendeintervall;
• Verbindungsdauer;
• Verhältnis von Upload zu Download;
• Verhalten beim Neuverbinden.

Das Protokoll kann deshalb das Erscheinungsbild des Verkehrs verändern, zum Beispiel durch:

• Aufteilen großer Daten in mehrere Frames;
• Zusammenfassen kleiner Daten;
• Hinzufügen variablen Paddings;
• Anpassen der Sendeblöcke;
• Vermeiden einer festen Handshake-Länge;
• regelmäßiges Aktualisieren der Padding-Strategie.

Dabei muss aber klar sein:

Padding kann Verschlüsselung nicht ersetzen und nicht garantieren, dass Verkehr niemals erkannt wird.

Übermäßiges Padding verursacht außerdem:

• mehr Datenverkehr;
• höhere Latenz;
• mehr CPU-Last;
• verschwendetes Volumen im kostenlosen Plan.

Das Profil von 2.0 kann sich deshalb anpassen:

• in normalen Netzen mit geringem Overhead arbeiten;
• in besonderen Netzwerkumgebungen die Bearbeitung des Erscheinungsbilds verstärken;
• bei schnellen Downloads unnötiges Padding reduzieren;
• kleine Steuerdaten passend auffüllen.

Beta kann dagegen zusätzlichen Overhead reduzieren, um die Spitzengeschwindigkeit zu erhöhen.

---

Phase 16: Umgang mit MTU und Paketgröße

Wenn TUN-Verkehr um Protokoll-Header und verschlüsselte Daten ergänzt wird, wächst die Paketgröße.

Wird die MTU des Netzes überschritten, kann das Folgendes verursachen:

• IP-Fragmentierung;
• verworfene Pakete;
• Websites, die sich nicht öffnen;
• instabile Geschwindigkeit;
• ein VPN, das verbunden ist, aber keine Daten überträgt.

SingLink muss:

1. die TUN-MTU bestimmen;
2. Protokoll-Header abziehen;
3. den Verschlüsselungs-Overhead abziehen;
4. für IPv4 und IPv6 anpassen;
5. Daten bei Bedarf aufteilen;
6. unnötige IP-Fragmentierung vermeiden.

Deshalb passt eine feste Paketgröße nicht zu jedem Netz.

Das produktive 2.0 sollte eine umfassendere plattformübergreifende MTU-Kompatibilität haben. Wenn Beta aggressivere große Frames nutzt, kann es in manchen Netzen schneller, in ungewöhnlichen Netzen aber weniger stabil sein.

---

Phase 17: Umgang mit Latenz, Verlust und Überlastung

Der Client muss laufend beobachten:

• RTT-Latenz;
• Jitter;
• Paketverlust;
• Sendegeschwindigkeit;
• Empfangsgeschwindigkeit;
• unbestätigte Daten;
• Antwortverhalten des Knotens.

Er kann sich nicht auf einen einzelnen Ping verlassen.

Zum Beispiel:

Normal: 60 ms
Vorübergehender Anstieg: 120 ms
Anhaltender Anstieg: 500 ms
Keine Antwort: Timeout

Verschiedene Situationen erfordern unterschiedliche Reaktionen:

Situation	Reaktion
Vorübergehende Latenz	Weiter warten; nicht sofort neu verbinden
Geringer Paketverlust	Fenster oder Sendetakt anpassen
Anhaltend hohe Latenz	Parallelität verringern oder einen anderen Knoten erwägen
Keine Daten, aber Heartbeat erfolgreich	Session beibehalten
Heartbeat und Daten schlagen fehl	Verbindung als unterbrochen behandeln
Vollständiger Ausfall des Knotens	Neu verbinden oder Knoten wechseln

Nach einem einzigen verlorenen Paket neu zu verbinden, würde das Protokoll instabiler machen.

---

Phase 18: Heartbeats und Verbindungsprüfungen

Auch wenn lange keine Anwendungsdaten fließen, muss das System wissen, ob der Kanal noch lebt.

Es kann dafür nutzen:

PING
↓
PONG

Heartbeats dürfen nicht zu häufig sein.

Zu häufige Heartbeats:

• verschwenden Akku;
• verbrauchen Datenvolumen;
• erhöhen die Serverlast;
• erzeugen ein festes zeitliches Muster.

Zu seltene Heartbeats:

• verzögern die Erkennung eines ausgefallenen Knotens;
• lassen Anwendungen länger warten;
• verlangsamen die Wiederherstellung nach einem Netzwerkwechsel.

Die Heartbeat-Frequenz kann sich deshalb dem Zustand anpassen:

• bei normalem Verkehr keine zusätzlichen Heartbeats senden;
• nach einer Leerlaufphase mit seltenen Heartbeats beginnen;
• nach einem Netzwerkwechsel vorübergehend häufiger prüfen;
• nach wiederholten Fehlschlägen die Verbindung als unterbrochen markieren.

---

Phase 19: Netzwerkwechsel und Session-Wiederherstellung

Wenn ein Smartphone von WLAN zu 5G wechselt, wird die ursprüngliche Verbindung in der Regel ungültig.

Eine vollständige Behandlung sollte so aussehen:

Netzwerkwechsel erkennen
        ↓
Keine neuen Daten mehr über den ausgefallenen Kanal senden
        ↓
Neue lokale IP und Route ermitteln
        ↓
Erneut mit dem ursprünglichen Knoten verbinden
        ↓
Zugangsdaten zur Session-Wiederherstellung übermitteln
        ↓
Server prüft die alte Session
        ↓
Wiederherstellbare logische Streams wiederherstellen
        ↓
Anwendungen anweisen, nicht wiederherstellbare TCP-Verbindungen neu aufzubauen

Eine wichtige Einschränkung:

Nicht jede TCP-Verbindung einer Anwendung lässt sich nahtlos wiederherstellen.

Das Protokoll kann wiederherstellen:

• den Session-Status;
• die Knotenautorisierung;
• die Protokollparameter;
• manche Streams, deren Status noch gültig ist.

Wenn aber die TCP-Verbindung der Ziel-Website selbst beendet ist, muss sich die Anwendung womöglich trotzdem neu verbinden.

Es sollte deshalb nicht so beworben werden:

Jede Anwendung übersteht einen Netzwerkwechsel immer ohne Unterbrechung.

Genauer ist:

SingLink 2.0 verkürzt die Zeit zum Neuverbinden, stellt Protokoll- und Routingstatus wieder her und versucht, die Auswirkungen auf Anwendungen so gering wie möglich zu halten.

---

Phase 20: Knotenausfall und automatischer Wechsel

Störungen an Knoten lassen sich unterteilen in:

Weicher Ausfall

• steigende Latenz;
• gelegentlicher Paketverlust;
• vorübergehend keine Antwort;
• einige Ziele nicht erreichbar.

Reaktion:

• kurz warten;
• den Transportdruck verringern;
• erneut messen;
• erneut mit demselben Knoten verbinden.

Harter Ausfall

• Knoten nicht erreichbar;
• Authentifizierungsschnittstelle nicht verfügbar;
• anhaltende Timeouts;
• Knoten außer Betrieb genommen.

Reaktion:

1. Den ursprünglichen Knoten nicht mehr nutzen.
2. Den Kill Switch aktivieren.
3. Aus der Liste der verfügbaren Knoten eine Alternative wählen.
4. Eine neue sichere Session aufbauen.
5. DNS und Routen wiederherstellen.
6. Anwendungen anweisen, nötige Verbindungen neu aufzubauen.

Das produktive 2.0 kann vorsichtiger wechseln, damit kurzer Jitter nicht zu ständigem Springen zwischen Knoten führt.

Beta kann sich aggressiver neu verbinden oder schnelle Knoten wählen, was aber zu größeren Schwankungen führen kann.

---

Phase 21: Rückgabe der Daten und Entkapselung

Die Antwort der Ziel-Website durchläuft diesen Ablauf:

Ziel-Website liefert Daten zurück
        ↓
SingLink-Knoten empfängt sie
        ↓
Passende Session und passenden Stream finden
        ↓
Als SingLink-Datenframe kapseln
        ↓
Verschlüsseln und an den Client senden
        ↓
Client prüft die Integrität
        ↓
Entschlüsseln
        ↓
Nach Stream-ID demultiplexen
        ↓
In TUN oder System-Proxy schreiben
        ↓
An die ursprüngliche Anwendung zurückgeben

Der Client muss prüfen:

• ob Daten verändert wurden;
• ob die Sequenznummern stimmen;
• ob der Frame ein Duplikat ist;
• ob der Stream noch existiert;
• ob die Länge innerhalb der Grenzen liegt;
• ob das Empfangsfenster überschritten wurde.

Ungültige Daten dürfen nicht direkt an die Anwendung geliefert werden.

---

Phase 22: Normales Trennen und sicheres Aufräumen

Wenn ein Nutzer auf Trennen tippt, sollte der Client:

1. keinen neuen Proxy-Verkehr mehr annehmen;
2. aktive Streams normal schließen;
3. das Ende der Session an den Knoten senden;
4. Session-Schlüssel löschen;
5. kurzlebige Tokens widerrufen oder verwerfen;
6. das TUN schließen;
7. die System-Routen wiederherstellen;
8. DNS wiederherstellen;
9. die Kill-Switch-Regeln entfernen;
10. unnötige temporäre Konfiguration entfernen.

Wenn der Client abstürzt, braucht es auch im Betriebssystem oder beim nächsten Start einen Reparaturweg, damit nicht Folgendes zurückbleibt:

• ein ungültiger System-Proxy;
• falsches DNS;
• übrig gebliebene Routen;
• kein Internetzugang;
• ein dauerhaft gesperrter Kill Switch.

---

Detaillierte Unterschiede in der Strategie zwischen SingLink Beta und 2.0

Die folgende Übersicht beschreibt die technische Positionierung der Produkte; die genauen Parameter müssen noch technisch bestätigt werden.

Verarbeitungsbereich	SingLink Beta	SingLink 2.0
Hauptrichtung	Spitzengeschwindigkeit	Geschwindigkeit, Stabilität, Kompatibilität
Verbindungsparameter	Aggressiver	Adaptiv und vorsichtiger
Parallelität	Kann höhere Parallelität nutzen	Verhindert, dass ein Datenfluss den Kanal füllt
Transportfenster	Auf Durchsatz ausgerichtet	Dynamisch nach Latenz und Verlust angepasst
Knotenwechsel	Schnelle Knoten früher ausprobieren	Ausfall vor dem Wechsel bestätigen
Multiplexing	Auf effiziente Wiederverwendung ausgerichtet	Ausgleich zwischen Wiederverwendung und Isolation von Ausfällen
Padding	Geringerer Overhead hat Vorrang	An die Umgebung angepasst
Netzwerkwechsel	Grundlegende Wiederherstellung	Umfassendere Wiederherstellung und Kompatibilität
Regressionstests auf den Plattformen	Umfang einer Vorschau	Vollständige Produktivtests
Interne Stabilität	Etwa 97%	99,5 %
Geschwindigkeit	Über 1 Gbps unter geeigneten Bedingungen	Bleibt schnell, ohne nur nach der Spitze zu streben

---

Das vollständige Verarbeitungsprinzip in einem Absatz

Bei SingLink übernimmt zuerst der Client die Kontrolle über den Geräteverkehr und erledigt DNS-Verarbeitung, intelligentes Routing und Knotenauswahl. Dann prüft er die Berechtigungen von Konto und Knoten, handelt mit dem Knoten die Protokollfähigkeiten aus und erzeugt temporäre Verschlüsselungsschlüssel. Nach dem Verbindungsaufbau wird der TCP- und UDP-Verkehr jeder Anwendung als eigenständige Proxy-Verbindung oder logischer Stream gekapselt und über einen geschützten Kanal zum Knoten transportiert, der die Ziel-Website aufruft. Während der Übertragung verwaltet das System laufend Flussfenster, Datenintegrität, Latenz, Paketverlust, Heartbeats und Knotenstatus. Wenn sich das Netzwerk ändert oder ein Knoten ausfällt, baut es die Session neu auf, stellt Routen wieder her oder wechselt zu einem verfügbaren Knoten.

Der wesentliche Unterschied zwischen Beta und 2.0:

SingLink Beta strebt aggressiver nach Spitzengeschwindigkeit. SingLink 2.0 ergänzt umfassendere Kompatibilität, Verbindungsprüfungen, Klassifizierung von Störungen, Session-Wiederherstellung und plattformübergreifende Verarbeitung, behält dabei die schnelle Übertragung bei und erreicht so eine höhere Stabilität.

---

Häufige Fragen (FAQ)

Was ist SingLink 2.0?

SingLink 2.0 ist das offizielle, von SingLinkVPN entwickelte Netzwerk-Transportprotokoll. Es übernimmt Identitätsprüfung, verschlüsselte Sessions, Kapselung des Verkehrs, TCP- und UDP-Transport, Verbindungsprüfungen und die Wiederherstellung nach Störungen.

Ist SingLink 2.0 eine Softwareversion?

Nein. SingLink 2.0 ist der offizielle Name des Protokolls. Die Client-Versionen für Windows, macOS, Android und iOS folgen einem eigenen Versionsschema.

Was ist der Unterschied zwischen SingLink Beta und 2.0?

Beta ist ein auf Geschwindigkeit ausgelegtes Vorschauprotokoll, dessen Spitzengeschwindigkeit unter geeigneten Bedingungen 1 Gbps übersteigen kann. 2.0 ist das produktive Protokoll und legt Wert auf Geschwindigkeit, Stabilität, plattformübergreifende Kompatibilität und Wiederherstellung nach Verbindungsabbrüchen.

Wie hoch ist die Stabilität von SingLink 2.0?

Im internen A/B-Test von SingLinkVPN unter festgelegten Bedingungen erreichte SingLink 2.0 eine Stabilität von 99,5 % und Beta bis zu etwa 97%.

Wie verarbeitet SingLink Netzwerkverkehr?

Der Client übernimmt zuerst den Systemverkehr und erledigt DNS-Verarbeitung und intelligentes Routing. Dann prüft er die Berechtigungen von Konto und Knoten, baut eine verschlüsselte Session auf, kapselt TCP- oder UDP-Daten und sendet sie an einen Knoten.

Wie geht SingLink mit Verbindungsabbrüchen um?

Das System prüft laufend Latenz, Paketverlust, Heartbeats und Knotenstatus. Nach einer Störung kann es eine Session neu aufbauen, Routen wiederherstellen oder zu einem verfügbaren Knoten wechseln.

Worin unterscheidet sich SingLink von VLESS?

VLESS definiert vor allem Identität, Befehle und die Weiterleitung zum Ziel. SingLink vereint Identität, Routing, Knotenberechtigungen, Transportstrategie, Verbindungsprüfungen und Wiederherstellung nach Störungen in einem umfassenderen Protokollsystem.

Worin unterscheidet sich SingLink von AnyTLS?

AnyTLS transportiert vor allem eine Session und mehrere Streams über eine TLS-Verbindung. SingLink hat eine breitere Rolle im Produkt, die auch intelligentes Routing, Mitgliedschaftsberechtigungen, Knotensteuerung und Verbindungswiederherstellung umfasst. Die tatsächliche Umsetzung von Session und Stream richtet sich nach der offiziellen technischen Dokumentation.

Wer kann SingLink 2.0 nutzen?

Knoten mit dem produktiven SingLink-2.0-Protokoll stehen derzeit vor allem Nutzern von Pro, Max und Rich zur Verfügung. Das Beta-Protokoll ist für alle Mitglieder offen. Maßgeblich für den tatsächlichen Zugang ist die Anzeige im aktuellen Client.

Ist SingLink 2.0 vollständig Open Source?

Der Quellcode des Kernprotokolls ist noch nicht vollständig öffentlich, aber technische Dokumente, Testmethoden, Datenformate, Prüfwerkzeuge und das Verfahren zur Meldung von Schwachstellen sind Teil des laufenden Open-Source-Plans.

---

Quellen und weiterführende Lektüre

Die Angaben in diesem Artikel zur Produktpositionierung und zum öffentlichen Umfang stützen sich auch auf das offizielle Technologiezentrum von SingLinkVPN, das öffentliche Forschungs-Repository von SingLinkLabs und dessen Methodik für Leistungs-Benchmarks.

Weiterführend sind der vollständige Leitfaden zum kostenlosen Plan von SingLinkVPN, der Open-Source-Plan von SingLinkVPN und der Sicherheitsprüfbericht 2026 von SingLinkVPN.

Technischer Hinweis: Die Werte 99,5 %, etwa 97% und über 1 Gbps sind interne A/B-Stabilitätsergebnisse beziehungsweise Ergebnisse zum Spitzendurchsatz unter festgelegten Bedingungen. Sie bedeuten nicht, dass jede Region, jedes Gerät, jeder Netzbetreiber, jedes Netzwerk und jeder Zeitraum dasselbe Ergebnis liefert. Konkrete Verschlüsselungsalgorithmen, Paketformate und die Mechanismen von Session und Stream richten sich nach künftigen offiziellen technischen Dokumenten von SingLink und veröffentlichtem Quellcode.