Livre blanc technique du protocole SingLink

Le client obtient les packages, nœuds et autorisations de protocole disponibles du compte actuel. Les informations d’authentification doivent être de courte durée, révocables et découplées du statut de transfert de données ultérieur.

Le plan de contrôle renvoie l'adresse du nœud, le port, les protocoles disponibles et les politiques nécessaires, et ne doit pas fournir directement de clés principales à long terme ou de champs sensibles inutiles au client.

Le client reçoit le trafic qui doit être traité via le mode TUN, le proxy système ou l'extension réseau de la plate-forme. L'entrée spécifique dépend des capacités du système d'exploitation.

Des politiques cohérentes doivent être utilisées pour les requêtes DNS et les connexions ultérieures afin d'éviter que les noms de domaine ne passent par des proxys alors que le DNS fuit toujours du réseau local ou provoque un détournement erroné.

Détermine les connexions comme directes, proxy ou bloquées en fonction des règles, de l'application, du nom de domaine cible, de l'adresse IP et de l'état du réseau.

Le mode manuel utilise des nœuds spécifiés par l'utilisateur ; le mode intelligent peut sélectionner les nœuds candidats en fonction des autorisations de latence, de disponibilité, de charge, de région et de package.

Le client et le serveur confirment les générations de protocoles et les capacités prises en charge par les deux parties. L'ancien client ne doit pas activer silencieusement des comportements incompatibles lorsqu'il ne peut pas reconnaître de nouvelles fonctionnalités.

Les nœuds vérifient que le compte ou la session est valide et doivent empêcher la réutilisation des anciennes données d'authentification par vieillissement, randomisation ou mécanismes équivalents.

Le protocole nécessite l'établissement d'un contexte de chiffrement distinct pour la connexion actuelle. Les suites de chiffrement spécifiques, les champs de prise de contact et les périodes de rotation doivent être soumis aux futures spécifications publiques.

La session représente la session de transmission entre le client et le nœud, qui peut transporter l'état de la connexion, les informations de capacité, les pulsations et un ou plusieurs flux logiques.

Chaque demande d'application peut être mappée sur un flux logique au sein de la session, ou une connexion indépendante peut être établie ; la méthode finale dépend de la mise en œuvre publique.

Les informations de destination, l'identification du flux, la longueur de la charge utile, les commandes de contrôle et les données sont nécessaires pour former une trame analysable ; cette page n'invente pas de champs binaires non documentés.

Les flux d'octets TCP doivent maintenir l'ordre, gérer les demi-fermetures et les fermetures anormales, et transmettre la contre-pression côté application au côté transport.

Les datagrammes UDP doivent conserver les limites des messages et gérer les délais d'attente des sessions ; Les services de type UDP tels que QUIC doivent également éviter les blocages inutiles en tête de ligne.

Lorsque la vitesse de consommation du client, du nœud ou du service cible ralentit, la croissance de la mémoire tampon doit être limitée pour éviter qu'un seul flux n'interrompe la session entière.

La mise en paquets et le remplissage ne peuvent être utilisés que dans le cadre de la stratégie de transmission et ne peuvent pas être décrits comme une furtivité absolue ; ses conditions favorables et ses frais généraux nécessitent des tests et des vérifications.

La surcharge du tunnel réduira le MTU disponible, et les pannes de paquets volumineux doivent être réduites grâce à l'évitement de la fragmentation, à l'ajustement du MSS ou à des mécanismes équivalents.

Le protocole doit contrôler le rythme d'envoi et la retransmission en fonction du retour d'information du réseau, et faire la distinction entre la perte réelle de paquets, le délai d'attente et la gigue du réseau à court terme.

Surveillez en permanence l'état des sessions et des nœuds pour éviter de vous fier uniquement aux longs délais d'attente du système d'exploitation pour détecter les connexions mortes.

Après avoir basculé entre les réseaux Wi-Fi et mobiles, le client reconfirme l'entrée au réseau, les sessions DNS, de routage et de transmission, et reprend la connexion en fonction de ses capacités.

En cas de panne logicielle, la session peut être reconstruite en premier, et en cas de panne matérielle, les nœuds disponibles peuvent être commutés. Pendant le processus de commutation, le routage du système doit être restauré et le trafic provenant de connexions directes inattendues doit être évité.

Le client vérifie et décapsule les données renvoyées et efface l'état de session temporaire, les clés de cache, le routage et les modifications DNS une fois la connexion établie.