PLY
Parlons-en
FR

Fonctionnement

Un paquet, quatre passages

PLY se branche sur le système, pas sur l'application. macOS remet un paquet IP entier au Packet Tunnel du système, et le serveur ramène la réponse par le même chemin protégé.

  1. 01 · Client

    L'application utilise le réseau habituel

    Un navigateur, un terminal, un appel ou un protocole que vous avez écrit voient une interface système et la traitent comme d'habitude. PLY n'inspecte jamais le contenu de TCP et UDP et n'en réécrit pas la sémantique, donc il n'y a rien sur quoi une application puisse buter.

  2. 02 · Packet Tunnel

    Le système livre de l'IP brut

    Une Network System Extension monte utun et passe des paquets IP entiers au client Rust par un pont local. Le pont n'admet qu'un processus du même utilisateur.

  3. 03 · Transport

    L'ordonnanceur répartit les paquets sur les liens

    Les datagrammes UDP chiffrés circulent sur les chemins que le serveur a confirmés par sonde. L'ordonnanceur décide quel chemin prend chaque paquet et combien de redondance y consacrer. Les acquittements, le FEC et le contrôle de congestion continuent de fonctionner pendant qu'un lien se dégrade.

  4. 04 · Sortie

    Linux route le trafic ou applique du NAT

    Un TUN persistant sur le serveur lâche le trafic autorisé dans un réseau routé, ou par le lien de sortie choisi avec MASQUERADE. Pour le monde extérieur, le trafic part de l'adresse du serveur, pas de celle du Mac.

À l'intérieur du chemin de données

Ce qui arrive au paquet en route

  • MTU et fragmentation

    Le client fixe un MTU explicite sur utun. Ce qui dépasse, c'est le transport lui-même qui le découpe et le recompose de l'autre côté, donc un lien à petit MTU ne fait pas tomber toute la connexion.

  • Chiffrement

    Chaque datagramme part chiffré. Les clés vivent par époques et tournent pendant la session, un seul compteur émet tous les nonce du projet, et le récepteur écarte un datagramme rejoué grâce à sa fenêtre anti-rejeu.

  • Choix du chemin et redondance

    L'importance vient du seul en-tête du paquet : le DSCP que l'application ou le routeur a déjà posé, et le rôle d'un paquet TCP, car perdre un simple acquittement coûte un délai d'attente entier là où perdre un segment d'un transfert de masse coûte une seule retransmission. Personne ne lit la charge utile. La redondance est ensuite calculée pour chaque message à partir de cette importance, des scores des chemins et du temps qu'il reste.

  • Le chemin retour

    La réponse revient par où elle est partie. Le serveur retient quel appareil détient quelle adresse et ne remettra pas la réponse d'un autre à un port qui se trouve coïncider.

Quand un chemin lâche

Un chemin compte comme vivant une fois sa sortie vérifiée

Attacher une socket à une adresse ne prouve rien. Le système peut encore déplacer ce trafic sur une autre interface, laissant deux lignes dans l'interface qui ne sont en réalité qu'un seul lien physique, et un multichemin qui n'existe que sur le papier. PLY envoie des sondes et regarde de quelle adresse publique elles atteignent le serveur. Tant que cette adresse n'est pas confirmée, le chemin ne transporte pas de trafic réel.

  • ACTIVESortie vérifiée ; le chemin transporte.
  • PROBINGLes sondes tournent ; pas encore de trafic réel.
  • MUTEDMis de côté pour l'instant, toujours vérifié.
  • DEADRetiré. Il ne revient qu'après une nouvelle vérification.