Funktionsweise

Ein Paket, vier Übergaben

PLY setzt am System an, nicht an der Anwendung. macOS übergibt ein ganzes IP-Paket an den Packet Tunnel des Systems, und der Server bringt die Antwort auf demselben geschützten Weg zurück.

  1. 01 · Client

    Die Anwendung nutzt das gewohnte Netz

    Ein Browser, ein Terminal, ein Anruf oder ein selbst geschriebenes Protokoll sehen eine Systemschnittstelle und behandeln sie wie immer. PLY sieht nie in den Inhalt von TCP und UDP hinein und schreibt ihre Semantik nicht um, also gibt es nichts, worüber eine Anwendung stolpern könnte.

  2. 02 · Packet Tunnel

    Das System übergibt rohes IP

    Eine Network System Extension bringt utun hoch und reicht ganze IP-Pakete über eine lokale Brücke an den Rust-Client weiter. Die Brücke lässt nur einen Prozess desselben Benutzers zu.

  3. 03 · Transport

    Der Planer verteilt die Pakete auf die Strecken

    Verschlüsselte UDP-Datagramme laufen über die Strecken, die der Server per Sonde bestätigt hat. Der Planer entscheidet, welche Strecke ein Paket nimmt und wie viel Redundanz es bekommt. Bestätigungen, FEC und Überlastregelung arbeiten weiter, während eine Strecke schlechter wird.

  4. 04 · Ausgang

    Linux routet den Verkehr oder setzt NAT

    Ein dauerhaftes TUN auf dem Server entlässt den erlaubten Verkehr in ein geroutetes Netz oder über den gewählten Uplink mit MASQUERADE. Nach außen verlässt der Verkehr die Adresse des Servers, nicht die des Mac.

Im Datenpfad

Was unterwegs mit dem Paket geschieht

  • MTU und Fragmentierung

    Der Client setzt eine ausdrückliche MTU auf utun. Was größer ist, teilt der Transport selbst und setzt es auf der Gegenseite wieder zusammen, damit eine Strecke mit kleiner MTU nicht die ganze Verbindung mitnimmt.

  • Verschlüsselung

    Jedes Datagramm geht verschlüsselt hinaus. Schlüssel leben in Epochen und wechseln im laufenden Betrieb, ein einziger Zähler vergibt jede Nonce im Projekt, und ein wiederholtes Datagramm verwirft der Empfänger anhand seines Wiedereinspielfensters.

  • Streckenwahl und Redundanz

    Die Wichtigkeit kommt allein aus dem Kopf des Pakets: dem DSCP, das Anwendung oder Router schon gesetzt haben, und der Rolle eines TCP-Pakets, denn eine verlorene reine Bestätigung kostet einen ganzen Zeitablauf, ein verlorenes Segment einer Massenübertragung dagegen eine einzige Wiederholung. Niemand liest die Nutzlast. Die Redundanz wird dann für jede Nachricht aus dieser Wichtigkeit, den Streckenwerten und der verbleibenden Zeit berechnet.

  • Der Rückweg

    Die Antwort kommt denselben Weg zurück. Der Server merkt sich, welches Gerät welche Adresse hält, und gibt die Antwort eines anderen nicht an einen zufällig passenden Port.

Wenn eine Strecke ausfällt

Eine Strecke gilt als lebendig, sobald ihr Ausgang geprüft ist

Einen Socket an eine Adresse zu binden beweist nichts. Das System kann diesen Verkehr immer noch auf eine andere Schnittstelle legen, und dann stehen zwei Zeilen in der Oberfläche, die in Wahrheit eine einzige physische Strecke sind, und die Mehrwegigkeit existiert nur auf dem Papier. PLY schickt Sonden und prüft, von welcher öffentlichen Adresse sie den Server erreichen. Solange diese Adresse nicht bestätigt ist, trägt die Strecke keinen echten Verkehr.

  • ACTIVEAusgang geprüft; die Strecke trägt.
  • PROBINGSonden laufen; noch kein echter Verkehr.
  • MUTEDVorerst beiseitegestellt, wird weiter geprüft.
  • DEADZurückgezogen. Sie kehrt nur über eine neue Prüfung zurück.