Verbindung & Auth
Eine Peer-zu-Peer-Verbindung (Raft-Port = Client-Port + 1000) wird in genau derselben Reihenfolge aufgebaut wie der Client-Port. Es gibt keinen protokollinternen Schritt, um Client und Peer zu unterscheiden — Rollen werden rein anhand des Ports auseinandergehalten.
- TCP-Verbindungsaufbau — die anwählende Seite ist immer der Anfragende
- TLS-Handshake, falls der Server TLS aktiviert hat
- Ein Auth-Handshake — die Spezifikation (Challenge, Digest, Antwort) ist byte-genau identisch zum Client-Port
- Ab hier Austausch von längen-präfixierten RPCs
Ablauf
Anwählender Knoten
Empfangender Knoten
TCP-Verbindungsaufbau (Raft-Port = Client-Port + 1000)
TLS-Handshake, falls der Server TLS aktiviert hat
Challenge (SHA-256 ␣ Nonce)
Digest — berechnet mit dem ersten Token in cluster_tokens
verifiziert gegen die gesamte cluster_tokens-Liste
ab hier längen-präfixierte Raft-RPCs
AnfrageAntwortKonsens-RPC (Raft)
Unterschied zum Client-Port
| Element | Client-Port | Raft-Port |
|---|---|---|
| Zur Verifikation genutzter Token-Satz | client_tokens | cluster_tokens |
| Gesendetes Token | das vom Client konfigurierte Token | das erste Token in cluster_tokens |
| Nach der Auth | \n-terminierte Frames | längen-präfixierte RPC |
- Auf der empfangenden Seite prüft die Verifikation gegen die gesamte
cluster_tokens-Liste, sodass du alte und neue Tokens gemeinsam auflisten und Knoten nacheinander neu starten kannst, um Tokens ohne Ausfallzeit zu rotieren (Konfiguration (Umgebungsvariablen)). - Bei aktiviertem TLS verwendet der Raft-Port dasselbe Zertifikat. Die anwählende Seite verifiziert das Zertifikat des Peers gegen
tls_ca(oder den System-Vertrauensspeicher, falls nicht gesetzt);tls_skip_verifyist nur für Tests. - Bei Auth-Fehler wird die Verbindung nach
E auth_failedgeschlossen — genau wie beim Client-Port.