Le protocole SingLink 2.0
Contents
SingLink 2.0 est le protocole de transport réseau officiel développé en interne par SingLinkVPN. « 2.0 » désigne le nom et la génération du protocole ; ce n’est pas une version du logiciel client SingLinkVPN.
Le protocole SingLink ne se contente pas d’acheminer le trafic vers un nœud VPN. Il couvre aussi l’autorisation du compte et des nœuds, le traitement du DNS, le routage intelligent, les sessions chiffrées, l’encapsulation TCP et UDP, les contrôles de santé de la connexion, les changements de réseau et la reprise après incident.
SingLink dispose actuellement du protocole de production SingLink 2.0 et du protocole en préversion SingLink Beta, axé sur la vitesse. Lors de tests A/B internes, SingLink 2.0 a atteint une stabilité de 99,5 % et Beta jusqu’à environ 97 % ; dans des conditions de réseau et d’appareil adaptées, la vitesse de pointe de Beta a dépassé 1 Gbit/s.
Comparaison des données clés : en production, SingLink 2.0 a enregistré une stabilité de 99,5 % dans l’environnement de test indiqué. Beta a atteint jusqu’à environ 97 %, mais a dépassé 1 Gbit/s en vitesse de pointe dans des conditions de réseau et d’appareil adaptées. Ces résultats reflètent des priorités différentes entre stabilité et vitesse et ne constituent pas une garantie pour chaque appareil ou réseau.
Preuves et limites techniques : le positionnement confirmé du produit, les définitions des tests internes et les fonctions publiques peuvent être cités tels quels. Les algorithmes de chiffrement précis, le format des paquets, la négociation des capacités, les Session, Stream, le multiplexage et les détails de reprise de session décrits ci-dessous constituent un modèle de traitement de référence, et non la spécification actuellement déployée. Les futurs documents techniques officiels de SingLink et le code source publié font foi.
Les principes de fonctionnement complets du protocole SingLink
Le système complet se divise en deux chemins :
Le plan de contrôle
Il est chargé de :
- la connexion au compte ;
- la validation de l’abonnement ;
- l’obtention des nœuds ;
- la détermination des droits d’accès aux nœuds ;
- la transmission de la configuration du protocole ;
- la mise à jour des règles ;
- le choix entre Beta et 2.0.
Le plan de données
Il est chargé de :
- recevoir le trafic des applications ;
- résoudre le DNS ;
- établir une connexion sécurisée ;
- encapsuler et acheminer TCP et UDP ;
- maintenir la connexion active ;
- gérer les déconnexions ;
- renvoyer les données à l’application.
Le flux simplifié est le suivant :
L’utilisateur se connecte à SingLinkVPN
↓
Obtention des nœuds autorisés et de la configuration du protocole
↓
Le client crée un TUN / proxy système
↓
Réception du trafic des applications
↓
Évaluation des règles DNS et de routage
↓
Choix d’un nœud SingLink 2.0 ou Beta
↓
Négociation des capacités du protocole
↓
Vérification des droits du compte et de l’appareil
↓
Création de la session chiffrée et des clés de session
↓
Création d’un flux logique indépendant pour chaque connexion applicative
↓
Encapsulation des données TCP / UDP
↓
Envoi des données au nœud SingLink
↓
Le nœud désencapsule et accède au site de destination
↓
Retour des données et remise à l’application d’origine
↓
Mesure continue de la latence, des pertes et de l’état de la connexion
↓
Reconnexion, reprise ou changement de nœud après un incident
Étape 1 : connexion, récupération des nœuds et configuration du protocole
Après qu’un utilisateur a ouvert SingLinkVPN et s’est connecté, le client ne devrait pas stocker immédiatement et de façon permanente sur l’appareil toutes les adresses des nœuds de production, les identifiants et les paramètres du protocole.
Un flux plus approprié est le suivant :
- Le client transmet les identifiants du compte.
- Le système de comptes vérifie l’utilisateur.
- Le système confirme l’offre et les droits d’accès aux nœuds.
- Il renvoie les nœuds accessibles à cet utilisateur.
- Il renvoie des identifiants de connexion à courte durée de vie.
- Il renvoie la version actuelle du protocole et la configuration requise.
- Le client vérifie l’intégrité de la configuration.
- La configuration sensible est conservée dans le stockage protégé du système.
Cette couche détermine principalement :
- si l’utilisateur dispose d’un abonnement valide ;
- si Beta ou 2.0 est disponible ;
- si le compte bénéficie des droits Pro, Max ou Rich ;
- quels pays et quels nœuds sont disponibles ;
- si la configuration a expiré ;
- si le client doit être mis à jour.
En termes simples
C’est comme le contrôle avant de monter dans un train à grande vitesse :
- qui vous êtes ;
- quelle classe de billet vous avez achetée ;
- dans quel train vous pouvez monter ;
- si le billet est toujours valable.
Règles de sécurité recommandées
SingLink ne devrait pas s’appuyer indéfiniment sur un mot de passe statique permanent.
Une conception plus adaptée utilise :
- un jeton de connexion à courte durée de vie ;
- un défi à usage unique ;
- un nonce propre à l’appareil ;
- une limite d’expiration ;
- une configuration de nœud signée par le serveur ;
- un mécanisme de révocation.
Obtenir une configuration de connexion ne donnerait alors pas un accès permanent.
Étape 2 : mise en place du point d’entrée réseau du système
Lorsqu’un utilisateur appuie sur Connecter, SingLinkVPN doit d’abord créer un point d’entrée réseau dans le système d’exploitation.
La méthode diffère selon la plateforme :
| Plateforme | Point d’entrée réseau courant |
|---|---|
| iOS / iPadOS | Network Extension / Packet Tunnel |
| Android | VPN Service |
| macOS | Network Extension ou TUN |
| Windows | Adaptateur virtuel TUN et routage système |
| Linux | TUN, table de routage et gestion du DNS |
Une fois ce point d’entrée créé, les données que les applications enverraient normalement directement au réseau passent d’abord par le client SingLinkVPN.
Par exemple :
Application ChatGPT
↓
Pile réseau du système d’exploitation
↓
Interface TUN de SingLink
↓
Client SingLinkVPN
À cette étape, le client doit :
- créer une IP virtuelle ;
- configurer la table de routage ;
- configurer le DNS ;
- exclure le réseau local ;
- empêcher que la connexion au proxy soit réacheminée dans le TUN ;
- créer les règles du Kill Switch.
Le dernier point est important.
Sans exclusion de route, le trafic que SingLinkVPN utilise pour joindre son nœud pourrait lui-même repasser par le VPN et créer une boucle :
Trafic VPN
↓
Repasse par le VPN
↓
Est encapsulé de nouveau
↓
Boucle infinie
Le client doit donc exclure explicitement :
- l’IP du nœud lui-même ;
- les interfaces de contrôle nécessaires ;
- la passerelle locale ;
- les services que le système doit joindre directement.
Étape 3 : résolution DNS et évaluation du domaine
Lorsqu’un utilisateur ouvre chatgpt.com, l’appareil doit généralement d’abord résoudre le domaine en adresse IP.
Un mauvais traitement du DNS peut entraîner :
- des requêtes DNS qui passent directement par le réseau local ;
- un résolveur DNS local qui renvoie une adresse incorrecte ;
- des règles qui perdent le contexte du domaine d’origine ;
- un trafic IPv6 qui contourne le VPN ;
- des fuites DNS, alors même que le VPN semble connecté.
Le client SingLink peut suivre ce flux :
L’application envoie une requête DNS
↓
Le client intercepte le DNS
↓
Évaluation des règles de domaine
↓
Choix du DNS local ou d’un DNS distant protégé
↓
Obtention du résultat IPv4 / IPv6
↓
Association du domaine à l’IP
↓
Choix : direct, proxy ou blocage
Domaines locaux
Les banques locales, les appareils du réseau local ou les services propres à une région peuvent utiliser le DNS local et se connecter directement.
Domaines passant par le proxy
Les domaines qui doivent être consultés via le VPN peuvent être résolus par le nœud proxy ou par un résolveur DNS protégé.
En termes simples
Le DNS, c’est comme chercher une adresse.
Si cette recherche emprunte encore la route locale, elle peut révéler le site demandé, même si les données qui suivent passent par le VPN.
Le système du protocole SingLink doit donc définir :
- si le client intercepte le DNS ;
- quelles requêtes DNS passent en direct ;
- quelles requêtes DNS passent par le VPN ;
- comment IPv4 et IPv6 sont traités ;
- combien de temps les résultats DNS sont mis en cache ;
- si les résultats DNS périmés sont effacés après un changement de réseau.
Étape 4 : routage intelligent et décisions d’acheminement
Une fois le DNS et le trafic des applications entrés dans le client, le système doit décider comment les traiter.
Il y a normalement trois issues :
Direct
Proxy
Blocage
Direct
Le trafic utilise le réseau local et n’entre pas dans le tunnel SingLink.
Convient pour :
- les appareils du réseau local ;
- les sites web locaux ;
- les applications qui n’ont pas besoin de proxy ;
- les listes d’autorisation définies par l’utilisateur.
Proxy
Le trafic entre dans le protocole SingLink et est relayé par un nœud.
Convient pour :
- les sites web étrangers ;
- les outils d’IA ;
- les réseaux sociaux internationaux ;
- les applications choisies par l’utilisateur.
Blocage
La connexion est refusée.
Convient pour :
- les domaines publicitaires ;
- les domaines de pistage ;
- les adresses malveillantes ;
- les listes de blocage définies par l’utilisateur.
La décision peut prendre en compte :
- le domaine ;
- l’adresse IP ;
- le port ;
- l’application ;
- la situation géographique ;
- le type de protocole ;
- les règles de l’utilisateur ;
- le mode global ou le mode par règles.
En termes simples
Cette étape ressemble à la régulation du trafic routier :
- les véhicules locaux prennent les routes ordinaires ;
- les véhicules en partance pour l’étranger empruntent une autoroute chiffrée ;
- les véhicules dangereux se voient refuser l’accès.
Étape 5 : choix du nœud et du protocole
Une fois le trafic identifié comme devant passer par le proxy, le client doit choisir un nœud.
Ce choix ne peut pas reposer uniquement sur le nom d’un pays. Il doit aussi tenir compte :
- de l’offre de l’utilisateur ;
- du fait que le nœud utilise 2.0 ou Beta ;
- du fait que le nœud est en ligne ;
- de la latence ;
- de la perte de paquets ;
- de la charge ;
- de la distance du nœud ;
- de l’opérateur local ;
- de l’emplacement de la destination ;
- de la prise en charge d’UDP ;
- de la compatibilité du client.
Sélection manuelle
L’utilisateur choisit un nœud au Japon, aux États-Unis, à Singapour ou ailleurs.
Sélection intelligente
Le client choisit un nœud adapté à partir des résultats de tests.
La sélection intelligente ne devrait pas se contenter de choisir le nœud à la latence la plus faible.
Par exemple :
| Nœud | Latence | Pertes | Charge |
|---|---|---|---|
| A | 50 ms | 8 % | 90 % |
| B | 70 ms | 0 % | 30 % |
Même si A a une latence plus faible, ses pertes et sa charge sont élevées ; B peut se révéler plus stable en usage réel.
La sélection intelligente doit donc combiner :
Latence + pertes + taux de réussite de connexion + charge + performances historiques
Étape 6 : négociation des capacités du protocole
Une fois le nœud atteint, le client ne doit pas supposer d’emblée que les deux côtés prennent en charge les mêmes fonctions.
Les capacités doivent d’abord être négociées.
Les éléments négociés peuvent comprendre :
- la version de SingLink ;
- Beta ou 2.0 ;
- la prise en charge de TCP ;
- la prise en charge d’UDP ;
- IPv4 / IPv6 ;
- la prise en charge de la reprise de session ;
- la prise en charge du multiplexage ;
- la taille maximale des trames de données ;
- la stratégie de Padding (remplissage) ;
- l’intervalle des battements de cœur (heartbeat) ;
- l’activation ou non de la compression ;
- la taille du MTU ;
- la prise en charge de la renégociation.
Par exemple :
Client :
Je prends en charge SingLink 2.0
Je prends en charge TCP, UDP et IPv6
Je prends en charge Session Resume
Trame maximale : 64 KB
Serveur :
Utilisation de SingLink 2.0 confirmée
TCP et UDP disponibles
Session Resume disponible
Trame maximale effective : 32 KB
Au final, les deux côtés n’utilisent que les capacités qu’ils prennent tous deux en charge.
Pourquoi la négociation est-elle nécessaire ?
Les clients et les nœuds ne sont pas forcément mis à jour le même jour.
Si un nouveau client envoie un format qu’un ancien nœud ne reconnaît pas, la connexion échoue.
En production, 2.0 doit mettre davantage l’accent que Beta sur :
- la rétrocompatibilité ;
- le repli sur une version antérieure ;
- une dégradation sûre lorsqu’une fonction n’est pas disponible ;
- le rejet explicite des versions incompatibles.
Étape 7 : vérification d’identité
Une fois la connexion de base établie, le nœud doit confirmer que l’utilisateur est autorisé.
Les données de vérification recommandées comprennent :
- un jeton à courte durée de vie ;
- un identifiant de compte ou d’autorisation ;
- un nonce du client ;
- la version du protocole ;
- l’identifiant du nœud ;
- les capacités demandées ;
- des données de vérification de l’intégrité.
Un paquet d’authentification simplifié dit :
Qui je suis
Quel nœud je veux
Quel protocole je veux
L’identifiant aléatoire de cette connexion
Quand mon autorisation expire
Si les données ont été modifiées
Le serveur doit vérifier :
- si le jeton a été émis officiellement ;
- si le jeton a expiré ;
- si le jeton a été révoqué ;
- si l’utilisateur a accès au nœud ;
- si le nonce a déjà été utilisé ;
- si la requête est un rejeu ;
- si cette version du client est autorisée à se connecter.
Protection contre le rejeu
Un attaquant pourrait enregistrer des données d’authentification valides et les renvoyer telles quelles.
Les données d’authentification ont donc besoin :
- d’un nonce à usage unique ;
- d’un défi du serveur ;
- d’une courte durée de validité ;
- d’un registre des identifiants déjà utilisés ;
- d’une liaison à la session.
En termes simples :
Un billet déjà composté ne peut pas être copié et réutilisé indéfiniment.
Étape 8 : échange de clés et session chiffrée
Une fois l’identité vérifiée, le client et le nœud ont besoin de clés de session propres à cette connexion.
La logique recommandée est la suivante :
Le client crée une clé éphémère
↓
Le serveur crée une clé éphémère
↓
Les deux échangent leurs données publiques
↓
Chacun calcule indépendamment le même secret partagé
↓
Plusieurs clés de session sont dérivées de ce secret partagé
Des clés distinctes devraient être dérivées pour :
- le chiffrement du client vers le serveur ;
- le chiffrement du serveur vers le client ;
- l’intégrité des données ;
- la reprise de session ;
- la protection des en-têtes.
Les différents sens et usages ne devraient pas partager une même clé.
Confidentialité persistante (forward secrecy)
Une conception plus adaptée utilise des clés éphémères pour chaque session.
Si une clé de serveur à long terme venait à fuiter plus tard, elle ne devrait pas permettre de déchiffrer directement toutes les connexions enregistrées auparavant.
Rotation des clés
Une connexion de longue durée ne devrait pas utiliser indéfiniment le même jeu de clés de session.
Les clés peuvent être redérivées en fonction :
- du volume de données transférées ;
- de la durée de la connexion ;
- du nombre de trames ;
- d’une instruction du serveur.
pour redériver les clés.
Par exemple :
Après un nombre défini de Go
ou
après une durée définie
dériver de nouvelles clés pour chaque sens
Les valeurs exactes doivent être fixées par des tests d’ingénierie de performances et de sécurité, et non inventées dans un article promotionnel.
Étape 9 : création d’une Session
Une fois l’identité et les clés établies, les deux côtés créent une Session SingLink.
Une Session peut contenir :
- l’identifiant de Session ;
- la version du protocole ;
- les paramètres de chiffrement ;
- la taille maximale des trames ;
- l’intervalle des battements de cœur ;
- le mode UDP ;
- la limite de Streams ;
- le délai d’inactivité ;
- la capacité de reprise de session ;
- la politique Beta ou 2.0.
Le serveur renvoie une confirmation :
Identité vérifiée
Session établie
Utilisation de SingLink 2.0
TCP disponible
UDP disponible
Multiplexage disponible
Battements de cœur activés
Le client ne devrait envoyer les données des applications qu’après avoir reçu la confirmation du serveur.
Étape 10 : création d’un Stream ou d’une connexion proxy indépendante
Seule une confirmation de l’équipe d’ingénierie permettra d’établir quelle architecture SingLink utilise réellement.
Option 1 : une Session transporte plusieurs Streams
Cette approche ressemble à celle d’AnyTLS :
Session SingLink
├─ Stream 1 : ChatGPT
├─ Stream 2 : YouTube
├─ Stream 3 : Telegram
└─ Stream 4 : navigateur
Chaque Stream a besoin :
- d’un identifiant de Stream ;
- d’une adresse de destination ;
- d’un port de destination ;
- de TCP ou d’UDP ;
- d’un état courant ;
- d’une fenêtre d’émission ;
- d’une fenêtre de réception.
Avantages :
- moins de poignées de main répétées ;
- une latence de connexion plus faible ;
- moins de connexions sous-jacentes ;
- un traitement efficace des nombreuses connexions courtes.
Risques :
- la défaillance d’une Session peut affecter plusieurs Streams ;
- une connexion TCP sous-jacente unique peut provoquer un blocage en tête de ligne ;
- un contrôle de flux complet est nécessaire.
Option 2 : chaque requête applicative crée une connexion indépendante
ChatGPT → connexion indépendante
YouTube → connexion indépendante
Telegram → connexion indépendante
Avantages :
- les différents trafics sont isolés ;
- la défaillance d’une connexion n’affecte pas les autres ;
- une logique plus simple.
Inconvénients :
- davantage de poignées de main ;
- un surcoût de connexion plus important ;
- une efficacité moindre pour les nombreuses connexions courtes.
Recommandation
SingLink peut utiliser un mode hybride :
- multiplexer les connexions courtes et le trafic web ordinaire dans une Session ;
- créer des canaux indépendants pour les gros téléchargements et la vidéo ;
- traiter séparément l’UDP à faible latence ;
- empêcher qu’un seul téléchargement à haut débit n’accapare tous les Streams.
Étape 11 : encapsulation en trames de données
Les données des applications ne peuvent pas être déposées telles quelles dans le canal de transport. Elles doivent être encapsulées sous forme de trames du protocole.
Une trame SingLink conceptuelle peut contenir :
Version
Type de trame
Session ID
Stream ID
Numéro de séquence
Indicateurs (flags)
Longueur des données
Données chiffrées
Étiquette d’intégrité
Les types de trames possibles comprennent :
| Type de trame | Rôle |
|---|---|
| OPEN | Créer un nouveau Stream |
| DATA | Transporter des données |
| ACK | Confirmer l’état |
| FIN | Fermeture normale |
| RESET | Terminer de façon anormale |
| PING | Contrôle de santé |
| PONG | Réponse au contrôle de santé |
| UDP | Transporter un datagramme UDP |
| SETTINGS | Mettre à jour les paramètres de session |
| KEY_UPDATE | Renouveler les clés de session |
| RESUME | Reprendre une session |
Il s’agit d’une recommandation de conception de protocole. Elle n’affirme pas que SingLink utilise actuellement ces noms ou ces formats binaires.
Étape 12 : traitement du trafic TCP
Pour les connexions TCP comme les sites web, les API et les téléchargements de fichiers, SingLink doit préserver :
- l’ordre des données ;
- le transfert bidirectionnel ;
- l’état de fermeture ;
- le contrôle de flux ;
- l’état d’erreur.
Un flux complet peut être :
L’application crée une connexion TCP
↓
Le client crée un Stream SingLink
↓
Envoi du domaine et du port de destination
↓
Le nœud se connecte au site de destination
↓
Le nœud signale la réussite ou l’échec
↓
Début du relais bidirectionnel
Fermeture normale
Lorsque l’application met fin à la connexion :
- Le client envoie FIN.
- Le nœud cesse de recevoir des données dans ce sens.
- Il attend que l’autre sens se termine.
- Le Stream se ferme complètement.
- La mémoire et l’état de connexion sont libérés.
Fermeture anormale
Si la destination refuse la connexion :
- Le nœud renvoie une erreur.
- Le client signale l’échec de la connexion à l’application.
- Le Stream est immédiatement nettoyé.
- Les autres Streams ne sont pas affectés.
Étape 13 : traitement du trafic UDP
UDP n’a pas de connexion au sens de TCP. Chaque datagramme doit conserver :
- l’association de la source ;
- l’adresse de destination ;
- le port de destination ;
- la longueur des données ;
- les limites du datagramme ;
- le délai d’expiration de l’association.
Par exemple :
UDP Association ID
Adresse de destination
Port de destination
Longueur des données
Charge utile UDP
SingLink doit choisir explicitement entre ces approches :
UDP sur TCP
Les datagrammes UDP sont transportés dans TCP ou dans une Session fiable.
Avantages :
- passage plus facile à travers les réseaux qui n’autorisent que TCP ;
- moins de risques de perte de données ;
- déploiement plus simple.
Inconvénients :
- une perte côté TCP bloque les données UDP suivantes ;
- inadapté à certains jeux, à la voix et aux usages en temps réel.
UDP natif
UDP transporte directement les données.
Avantages :
- faible latence ;
- adapté aux jeux, à la voix et à QUIC ;
- pas affecté par le blocage en tête de ligne de TCP.
Inconvénients :
- certains réseaux restreignent UDP ;
- la gestion du NAT et des pare-feu est plus complexe.
Transport de type QUIC
Il repose sur UDP, mais fournit au niveau du protocole :
- le chiffrement ;
- la retransmission ;
- plusieurs Streams ;
- le contrôle de congestion ;
- la migration entre réseaux.
Il offre des capacités techniques plus complètes, mais il est plus difficile à mettre en œuvre.
Une orientation raisonnable pour SingLink serait :
Choisir automatiquement l’UDP natif, une encapsulation fiable ou un autre mode compatible selon le réseau et le type de trafic.
Reste à confirmer si cela est effectivement mis en œuvre.
Étape 14 : contrôle de flux et contre-pression
Supposons que YouTube télécharge rapidement pendant que ChatGPT ne transfère que de petites quantités de texte.
Sans contrôle de flux, le Stream vidéo peut saturer le canal et provoquer :
- des réponses de ChatGPT plus lentes ;
- des retards DNS ;
- des applications bloquées ;
- une consommation de mémoire en hausse continue.
Deux niveaux de contrôle de flux sont donc nécessaires :
Niveau Session
Il limite la quantité de données non acquittées que l’ensemble de la Session peut transporter.
Niveau Stream
Il limite la part de la fenêtre de transport que chaque Stream peut occuper.
En termes simples :
Un seul gros camion ne peut pas occuper toutes les voies d’une autoroute. Chaque Stream doit recevoir une part équitable des ressources de transport.
En production, le protocole 2.0 peut utiliser un ordonnancement plus prudent que Beta, afin que la recherche de la vitesse de pointe ne perturbe pas les autres connexions.
Étape 15 : segmentation, Padding et apparence du trafic
Une fois les données chiffrées, un observateur peut encore voir :
- la longueur des paquets ;
- l’intervalle d’envoi ;
- la durée de la connexion ;
- le rapport entre envoi et téléchargement ;
- le comportement de reconnexion.
Le protocole peut donc modifier l’apparence du trafic, par exemple en :
- découpant les gros volumes de données en plusieurs trames ;
- regroupant les petites données ;
- ajoutant un Padding variable ;
- ajustant les lots d’envoi ;
- évitant une longueur de poignée de main fixe ;
- mettant régulièrement à jour la stratégie de Padding.
Mais il faut être clair :
Le Padding ne peut pas remplacer le chiffrement et ne peut pas garantir que le trafic restera toujours impossible à identifier.
Un Padding excessif entraîne aussi :
- davantage de trafic ;
- une latence plus élevée ;
- une consommation CPU accrue ;
- un gaspillage du quota du plan gratuit.
Le profil 2.0 peut donc s’adapter :
- faible surcoût sur les réseaux ordinaires ;
- traitement de l’apparence renforcé dans les environnements réseau particuliers ;
- réduction du Padding inutile pendant les téléchargements à haut débit ;
- remplissage adapté pour les petites données de contrôle.
Beta peut au contraire réduire le surcoût supplémentaire pour améliorer la vitesse de pointe.
Étape 16 : MTU et gestion de la taille des paquets
L’ajout des en-têtes du protocole et des données chiffrées au trafic TUN augmente la taille des paquets.
Dépasser le MTU du réseau peut entraîner :
- une fragmentation IP ;
- des pertes de paquets ;
- des sites web qui ne s’ouvrent pas ;
- une vitesse instable ;
- un VPN connecté mais qui ne transmet aucune donnée.
SingLink doit :
- déterminer le MTU du TUN ;
- soustraire les en-têtes du protocole ;
- soustraire le surcoût du chiffrement ;
- s’ajuster pour IPv4 et IPv6 ;
- découper les données si nécessaire ;
- éviter toute fragmentation IP inutile.
C’est pourquoi une taille de paquet fixe ne convient pas à tous les réseaux.
En production, 2.0 doit offrir une compatibilité MTU multiplateforme plus complète. Si Beta utilise des trames volumineuses plus agressives, il peut être plus rapide sur certains réseaux, mais moins stable sur des réseaux atypiques.
Étape 17 : gestion de la latence, des pertes et de la congestion
Le client doit surveiller en continu :
- la latence RTT ;
- la gigue ;
- la perte de paquets ;
- la vitesse d’envoi ;
- la vitesse de réception ;
- les données non acquittées ;
- la réponse du nœud.
Il ne peut pas s’appuyer sur un seul Ping.
Par exemple :
Normal : 60 ms
Hausse temporaire : 120 ms
Hausse durable : 500 ms
Aucune réponse : délai dépassé
Chaque situation appelle un traitement différent :
| Situation | Traitement |
|---|---|
| Latence temporaire | Continuer à attendre ; ne pas se reconnecter immédiatement |
| Légère perte de paquets | Ajuster la fenêtre ou le rythme d’envoi |
| Latence élevée durable | Réduire la concurrence ou envisager un autre nœud |
| Aucune donnée, mais le battement de cœur réussit | Conserver la Session |
| Battement de cœur et données en échec | Considérer la connexion comme interrompue |
| Panne complète du nœud | Se reconnecter ou changer de nœud |
Se reconnecter après la perte d’un seul paquet rendrait le protocole moins stable.
Étape 18 : battements de cœur et contrôles de santé
Même en l’absence de données applicatives pendant longtemps, le système doit savoir si le canal reste actif.
Il peut utiliser :
PING
↓
PONG
Les battements de cœur ne doivent pas être trop fréquents.
Une fréquence excessive :
- gaspille la batterie ;
- consomme des données ;
- augmente la charge du serveur ;
- crée une signature temporelle fixe.
Une fréquence insuffisante :
- retarde la détection d’un nœud défaillant ;
- fait attendre plus longtemps les applications ;
- ralentit la reprise après un changement de réseau.
La fréquence des battements de cœur peut donc s’adapter à l’état de la connexion :
- en présence de trafic normal, ne pas ajouter de battements de cœur ;
- après une période d’inactivité, lancer des battements de cœur à basse fréquence ;
- après un changement de réseau, renforcer temporairement les contrôles ;
- après des échecs répétés, marquer la connexion comme interrompue.
Étape 19 : changements de réseau et reprise de session
Lorsqu’un téléphone passe du Wi-Fi à la 5G, la connexion d’origine devient généralement invalide.
Un traitement complet devrait être :
Détection du changement de réseau
↓
Arrêt de l’envoi de nouvelles données par le canal défaillant
↓
Obtention de la nouvelle IP locale et de la nouvelle route
↓
Reconnexion au nœud d’origine
↓
Envoi de l’identifiant de reprise de session
↓
Le serveur valide l’ancienne Session
↓
Reprise des Streams logiques récupérables
↓
Les applications sont invitées à reconstruire les connexions TCP non récupérables
Une limite importante :
Toutes les connexions TCP des applications ne peuvent pas être reprises de façon transparente.
Le protocole peut restaurer :
- l’état de la Session ;
- l’autorisation sur le nœud ;
- les paramètres du protocole ;
- certains Streams dont l’état reste valide.
Mais si la connexion TCP propre au site de destination a pris fin, l’application devra peut-être quand même se reconnecter.
Il ne faut donc pas le présenter ainsi :
Toutes les applications traverseront toujours un changement de réseau sans aucune interruption.
Une formulation plus exacte est :
SingLink 2.0 raccourcit le temps de reconnexion, restaure l’état du protocole et du routage, et cherche à réduire au minimum l’impact sur les applications.
Étape 20 : panne de nœud et bascule automatique
Les incidents de nœud peuvent se répartir en deux catégories :
Défaillance légère
- latence en hausse ;
- pertes de paquets occasionnelles ;
- absence de réponse temporaire ;
- certaines destinations indisponibles.
Traitement :
- attendre brièvement ;
- réduire la pression sur le transport ;
- mesurer de nouveau ;
- se reconnecter au même nœud.
Défaillance grave
- nœud injoignable ;
- interface d’authentification indisponible ;
- délais dépassés de façon durable ;
- nœud retiré du service.
Traitement :
- Cesser d’utiliser le nœud d’origine.
- Activer le Kill Switch.
- Choisir un nœud de remplacement dans la liste disponible.
- Établir une nouvelle Session sécurisée.
- Restaurer le DNS et les routes.
- Inviter les applications à reconstruire les connexions nécessaires.
En production, 2.0 peut basculer de façon plus prudente, afin qu’une brève gigue ne provoque pas des sauts répétés d’un nœud à l’autre.
Beta peut se reconnecter ou choisir des nœuds à haut débit de façon plus agressive, au prix de variations plus importantes.
Étape 21 : retour des données et désencapsulation
La réponse du site de destination suit ce flux :
Le site de destination renvoie les données
↓
Le nœud SingLink les reçoit
↓
Recherche de la Session et du Stream correspondants
↓
Encapsulation en trame de données SingLink
↓
Chiffrement et envoi au client
↓
Le client vérifie l’intégrité
↓
Déchiffrement
↓
Démultiplexage selon le Stream ID
↓
Écriture dans le TUN ou le proxy système
↓
Retour à l’application d’origine
Le client doit vérifier :
- si les données ont été modifiées ;
- si les numéros de séquence sont corrects ;
- si la trame est un doublon ;
- si le Stream existe toujours ;
- si la longueur respecte les limites ;
- si la fenêtre de réception a été dépassée.
Les données invalides ne doivent pas être transmises directement à l’application.
Étape 22 : déconnexion normale et nettoyage sécurisé
Lorsqu’un utilisateur appuie sur Déconnecter, le client devrait :
- cesser d’accepter du nouveau trafic à faire passer par le proxy ;
- fermer normalement les Streams actifs ;
- envoyer au nœud la fin de la Session ;
- effacer les clés de session ;
- révoquer ou abandonner les jetons à courte durée de vie ;
- fermer le TUN ;
- restaurer les routes du système ;
- restaurer le DNS ;
- supprimer les règles du Kill Switch ;
- supprimer la configuration temporaire devenue inutile.
Si le client plante, le système d’exploitation ou le lancement suivant doit aussi disposer d’un chemin de réparation, afin de ne pas laisser :
- un proxy système invalide ;
- un DNS incorrect ;
- des routes résiduelles ;
- un appareil sans accès à Internet ;
- un Kill Switch bloqué en permanence.
Les différences de stratégie détaillées entre SingLink Beta et 2.0
Le tableau suivant traduit le positionnement technique du produit ; les paramètres exacts restent à confirmer par l’équipe d’ingénierie.
| Domaine de traitement | SingLink Beta | SingLink 2.0 |
|---|---|---|
| Orientation principale | Vitesse de pointe | Vitesse, stabilité, compatibilité |
| Paramètres de connexion | Plus agressifs | Adaptatifs et plus prudents |
| Concurrence | Peut utiliser une concurrence plus élevée | Empêche qu’un seul flux sature le canal |
| Fenêtre de transport | Orientée vers le débit | Ajustée dynamiquement selon la latence et les pertes |
| Bascule de nœud | Essaie plus tôt les nœuds à haut débit | Confirme la panne avant de basculer |
| Multiplexage | Orienté vers l’efficacité de la réutilisation | Équilibre réutilisation et isolation des pannes |
| Padding | Priorité à un surcoût réduit | S’adapte à l’environnement |
| Changement de réseau | Reprise de base | Reprise et compatibilité plus complètes |
| Tests de non-régression par plateforme | Périmètre de préversion | Tests de production complets |
| Stabilité interne | Environ 97 % | 99,5 % |
| Vitesse | Plus de 1 Gbit/s dans des conditions adaptées | Reste rapide sans viser uniquement la vitesse de pointe |
Le principe de fonctionnement complet en un paragraphe
Avec SingLink, le client prend d’abord la main sur le trafic de l’appareil et effectue le traitement du DNS, le routage intelligent et le choix du nœud. Il vérifie ensuite les droits du compte et l’accès au nœud, négocie les capacités du protocole avec le nœud et établit des clés de chiffrement temporaires. Une fois la connexion créée, le trafic TCP et UDP de chaque application est encapsulé sous forme de connexion proxy indépendante ou de Stream logique, puis acheminé par un canal protégé jusqu’au nœud, qui accède au site de destination. Pendant le transfert, le système gère en continu les fenêtres de flux, l’intégrité des données, la latence, la perte de paquets, les battements de cœur et l’état du nœud. Lorsque le réseau change ou qu’un nœud tombe en panne, il rétablit la Session, restaure les routes ou bascule vers un nœud disponible.
La différence essentielle entre Beta et 2.0 est la suivante :
SingLink Beta recherche la vitesse de pointe de façon plus agressive. SingLink 2.0 ajoute une compatibilité, des contrôles de santé, une classification des incidents, une reprise de session et une gestion multiplateforme plus complets, tout en conservant un transfert à haut débit, et atteint ainsi une stabilité plus élevée.
Questions fréquentes (FAQ)
Qu’est-ce que SingLink 2.0 ?
SingLink 2.0 est le protocole de transport réseau officiel développé par SingLinkVPN. Il assure la vérification d’identité, les sessions chiffrées, l’encapsulation du trafic, le transport TCP et UDP, les contrôles de santé et la reprise après incident.
SingLink 2.0 est-il une version du logiciel ?
Non. SingLink 2.0 est le nom officiel du protocole. Les versions des clients Windows, macOS, Android et iOS suivent une numérotation distincte.
Quelle est la différence entre SingLink Beta et 2.0 ?
SingLink Beta est un protocole en préversion axé sur la vitesse, dont la vitesse de pointe peut dépasser 1 Gbit/s dans des conditions adaptées. SingLink 2.0 est le protocole de production et met l’accent sur la vitesse, la stabilité, la compatibilité multiplateforme et la reprise après déconnexion.
Quel est le taux de stabilité de SingLink 2.0 ?
Lors du test A/B interne de SingLinkVPN dans des conditions définies, SingLink 2.0 a atteint une stabilité de 99,5 % et Beta jusqu’à environ 97 %.
Comment SingLink traite-t-il le trafic réseau ?
Avec SingLink, le client prend d’abord la main sur le trafic du système et effectue le traitement du DNS et le routage intelligent. Il vérifie ensuite les droits du compte et l’accès au nœud, établit une Session chiffrée, encapsule les données TCP ou UDP et les envoie à un nœud.
Comment SingLink gère-t-il les déconnexions ?
SingLink vérifie en continu la latence, la perte de paquets, les battements de cœur et l’état du nœud. Après un incident, il peut rétablir une Session, restaurer les routes ou basculer vers un nœud disponible.
En quoi SingLink diffère-t-il de VLESS ?
VLESS définit principalement l’identité, les commandes et le relais vers la destination. SingLink intègre l’identité, le routage, les droits d’accès aux nœuds, la politique de transport, les contrôles de santé et la reprise après incident dans un système de protocole plus large.
En quoi SingLink diffère-t-il d’AnyTLS ?
AnyTLS transporte principalement une Session et plusieurs Streams sur une connexion TLS. SingLink joue un rôle plus large dans le produit, qui inclut aussi le routage intelligent, les droits liés à l’abonnement, l’ordonnancement des nœuds et la reprise des connexions. L’implémentation réelle des Session et Stream reste soumise à la documentation technique officielle.
Qui peut utiliser SingLink 2.0 ?
Les nœuds du protocole de production SingLink 2.0 sont actuellement accessibles principalement aux utilisateurs Pro, Max et Rich. Le protocole Beta est ouvert à tous les membres. L’affichage du client le plus récent fait foi pour l’accès réel.
SingLink 2.0 est-il entièrement open source ?
Le code source du protocole central de SingLink n’est pas encore entièrement public, mais la documentation technique, les méthodes de test, les formats de données, les outils de validation et le mécanisme de divulgation des vulnérabilités font partie du plan open source continu.
Sources et lectures complémentaires
Le positionnement du produit et les éléments relatifs au périmètre public de cet article s’appuient aussi sur le centre technologique officiel de SingLinkVPN, le dépôt de recherche public de SingLinkLabs et sa méthodologie de benchmark des performances.
À lire aussi : le guide complet du plan gratuit SingLinkVPN, le plan open source de SingLinkVPN et le rapport d’audit de sécurité 2026 de SingLinkVPN.
Note technique : les chiffres de 99,5 %, d’environ 97 % et de plus de 1 Gbit/s correspondent respectivement à des résultats internes de stabilité en test A/B et à des résultats de débit de pointe dans des conditions définies. Ils ne signifient pas que chaque région, appareil, opérateur, réseau ou période donnera le même résultat. Les algorithmes de chiffrement précis, les formats de paquets et les mécanismes de Session et de Stream restent soumis aux futurs documents techniques officiels de SingLink et au code source publié.
