JIT-WireGuard-Technik

WireGuard-Verbesserungen bei Fly.io

• Fly.io wandelt Container in VMs um und betreibt sie weltweit auf Hardware mit der Leistung von Firecracker.
• Es nutzt WireGuard intensiv, und es ist inzwischen Teil der Kunden-API.
• Bei jedem Ausführen der flyctl-CLI wird ein TCP/IP-Stack erzeugt, der mit einer eindeutigen IPv6-Adresse direkt mit Fly Machines kommuniziert.
• Dieser Ansatz hat Vor- und Nachteile, und es gibt einige Verbesserungen.

Die bisherige Situation

• Weltweit verteilte „Gateway“-Server akzeptieren WireGuard-Verbindungen und verbinden sie mit dem passenden privaten Netzwerk.
• Bei jedem Ausführen von flyctl wird ein Hintergrund-Agent-Prozess erzeugt oder verbunden.
• Der Agent erstellt über die GraphQL-API eine neue WireGuard-Peer-Konfiguration.
• Die API überträgt die Peer-Konfiguration über das NATS-Messaging-System an das passende Gateway.
• Auf dem Gateway empfängt der Dienst wggwd die Konfiguration, speichert sie in einer SQLite-Datenbank und fügt sie dem Kernel hinzu.
• Die API antwortet auf die GraphQL-Anfrage mit der Konfiguration, und flyctl verbindet sich mit dem WireGuard-Peer.
• NATS ist schnell, garantiert aber keine Zustellung und räumt veraltete Peers auf den Gateways nicht auf.

Ein besserer Weg

• Zum Speichern von WireGuard-Peers ist keine komplexe Datenbank nötig.
• Stattdessen wurden die Gateways so geändert, dass sie die Konfiguration bei Bedarf von der API abrufen.
• Peers können nur dann dem Kernel hinzugefügt werden, wenn ein Client eine Verbindung aufbauen möchte, und entfernt werden, wenn sie nicht mehr benötigt werden.

JIT-WireGuard-Peers ermöglichen

• Die WireGuard-Konfigurationsschnittstelle im Linux-Kernel verwendet Netlink.
• WireGuard-Verbindungsanfragepakete lassen sich mit BPF-Filtern und Packet Sockets identifizieren und abfangen.
• WireGuard kennt keine Konzepte von „Client“ und „Server“, sondern ist ein Punkt-zu-Punkt-Protokoll.
• Wenn flyctl ein UDP-Paket an ein Gateway sendet, ist das eine handshake initiation.
• Mit einem BPF-Filter lassen sich eingehende Verbindungen abfangen.
• Da WireGuard auf dem Noise Protocol Framework basiert, muss die Verschlüsselung aufgehoben werden, um Anfragen zu identifizieren.
• Es lässt sich ein Event-Feed erzeugen, der die öffentlichen Schlüssel aller Nutzer liefert, die versuchen, sich mit einem Gateway zu verbinden.
• Jedes Mal, wenn ein neuer Peer erkannt wird, werden die zugehörigen Peer-Informationen über eine interne HTTP-API-Anfrage abgerufen und installiert.

Apps minutenschnell starten

• Auf Fly.io lassen sich Apps schnell bereitstellen und dabei eigene JIT-WireGuard-Peers erhalten.

Ein Blick auf die Grafiken

• Das System lief über mehrere Wochen und reduzierte die Zahl veralteter WireGuard-Peers, die auf den Gateways verblieben, deutlich.
• Die Gateways halten dadurch weniger Zustand vor, und die Peer-Konfiguration wird schneller.
• Über Grafana-Diagramme werden die erfolgreichen Ergebnisse des Umschalttags gezeigt.

Meinung von GN⁺

• Die WireGuard-Verbesserungen von Fly.io sind ein gutes Beispiel dafür, wie sich Netzwerkleistung und Stabilität deutlich steigern lassen.
• Dieser Ansatz kann besonders bei Cloud-basierten Diensten helfen, Netzwerkverkehr und Sicherheit zu verbessern.
• Ähnliche Projekte sind Tailscale und ZeroTier, die ebenfalls VPN-Alternativen für private und geschäftliche Nutzer anbieten.
• Bei der Einführung von WireGuard sollten Netzwerkkonfiguration, Sicherheitsrichtlinien und Kompatibilität berücksichtigt werden.
• Die Vorteile dieser Technik liegen in hoher Geschwindigkeit und einfacher Konfiguration, während die Integration in bestehende Infrastruktur und das Management Herausforderungen darstellen können.

[GN⁺]

Hacker-News-Kommentare

• Es heißt, dass WireGuard im Linux-Kernel keine Funktion hat, Peers bei Bedarf zu installieren, was beim Aufbau des Designs Probleme verursacht.

  • Dass WireGuard im Linux-Kernel keine Funktion besitzt, Peers auf Anfrage zu installieren, erschwert das Design.
  • Zwar lassen sich Peers zur Laufzeit hinzufügen, aber offenbar sollen Peers vor dem Hinzufügen zur Schnittstelle authentifiziert werden, um unnötige Einträge zu vermeiden.
  • Mithilfe eines eBPF-Filters werden Verbindungen auf Basis von Schlüssel-Routing direkt mit authentifizierten Gegenstellen verwaltet; nach abgeschlossener Prüfung wird der Peer zur Schnittstelle hinzugefügt und nach einem Timeout wieder entfernt.

• Ich stimme zu, dass HTTP-Anfragen zuverlässiger sind als Routing über eine Message Queue, aber ich war überrascht, dass durch NATS verlorene Nachrichten einen so großen Einfluss auf den Dienst hatten.

  • Zustimmung zur Ansicht, dass direkte HTTP-Anfragen zuverlässiger sind als eine Message Queue, aber Verwunderung darüber, dass Nachrichtenverlust in NATS den Dienst so stark beeinträchtigt hat.
  • Es wird erwartet, dass NATS bei Nachrichtenverlust eine erneute Zustellung versucht, und es wird die Frage aufgeworfen, warum es zu einem so auffälligen Zuverlässigkeitsproblem kam.

• Ich möchte ein aktuelles experimentelles Projekt bewerben. Wenn du daran interessiert bist, Go-Apps zu bauen, die als WireGuard-Peers im User Space laufen, schau es dir an.

  • Für Menschen, die daran interessiert sind, Go-Apps zu bauen, die als WireGuard-Peers im User Space laufen, wird das eigene Projekt vorgestellt.
  • Es baut auf der hervorragenden Arbeit von wireguard-go auf, soll aber vereinfacht werden, damit es sich besser als Bibliothek einsetzen lässt.
  • Es besteht Interesse am Aufbau eines Service Mesh; Unterstützung für verschiedene Sprachen könnte schwierig sein, aber eine Socket-API sollte sich umsetzen lassen.
  • Es wird erwähnt, dass für die Verschlüsselung von WireGuard bislang keine Hardware-Beschleunigung sichtbar ist, was den Wettbewerb mit mTLS erschweren könnte.
  • Die Person arbeitet als Freelancer im Bereich High-Speed-/Secure-Networking und bittet Interessierte, Kontakt aufzunehmen (E-Mail im Profil).

• Es ist interessant, dass Tunneling von WireGuard über WebSockets die Standardeinstellung ist. Für die Performance ist das nicht gut, aber für DevOps-Arbeiten, bei denen flyctl verwendet wird, dürfte es passen.

  • Es wird darauf hingewiesen, dass Tunneling von WireGuard über WebSockets die Standardeinstellung ist.
  • Für die Performance ist das nicht optimal, aber für DevOps-Aufgaben mit flyctl dürfte es kein Problem sein.
  • Es wird Neugier auf die Zukunft von QUIC/HTTP3 geäußert sowie die Frage, ob Netzwerkbetreiber UDP auf Port 443 künftig eher korrekt behandeln statt zu blockieren.

• Wir können als Initiator den Peer installieren, und flyctl ist der Antwortende. Der Linux-Kernel initiiert die WireGuard-Verbindung zu flyctl. Das funktioniert, und dem Protokoll ist es weitgehend egal, wer Server und Client ist. Neue Verbindungen werden so schnell wie möglich eingerichtet.

  • Es wird erläutert, dass man als Initiator den Peer installieren kann, während flyctl antwortet und der Linux-Kernel die WireGuard-Verbindung startet.
  • Es wird erwähnt, dass das Protokoll sich kaum um die Rollen von Server und Client kümmert und neue Verbindungen sehr schnell aufgebaut werden können.

• Mein Startup hat Fly fast ein Jahr lang genutzt. Die Kernfunktion, Code innerhalb von weniger als einer Minute in deployten Code zu verwandeln, ist großartig. Neue Nodes lassen sich in wenigen Sekunden hoch- und herunterfahren.

  • Es werden Erfahrungen eines Startups geteilt, das Fly fast ein Jahr lang genutzt hat.
  • Die schnelle Deployment-Funktion wird positiv bewertet, zugleich wirkt das Unternehmen aber etwas unausgereift.
  • Erwähnt werden eine Erfahrung, bei der der API-Server von Fly 48 Stunden lang nicht erreichbar war, sowie inkonsistente Verbindungsabbrüche beim Produkt „db“.
  • Es wird darauf hingewiesen, dass der API-Zugriff von Fly häufig ausfiel und dadurch das Deployment neuer Service-Änderungen erschwert wurde.
  • Obwohl die Deployment-Erfahrung vermisst wird, wird die Nutzung von Cloud Run auf GCP als zufriedenstellender beschrieben.

• „Jedes Mal, wenn man flyctl ausführt, erzeugt unsere liebenswerte, umfangreiche CLI aus dem Nichts einen TCP/IP-Stack und kommuniziert mit einer eigenen IPv6-Adresse direkt mit Fly Machines.“

  • Es wird Neugier darüber geäußert, wie flyctl beim Ausführen spontan einen TCP/IP-Stack erzeugt und über eine eigene IPv6-Adresse direkt mit Fly Machines kommuniziert.

• Was verhindert, dass das anfängliche Handshake-Paket erneut an den Netzwerk-Stack gesendet wird? Dann gäbe es offenbar keinen Paketverlust. Und welchem Zweck dient die Prüfung auf „udp[8] = 1“ im eBPF-Filter?

  • Es wird gefragt, welcher Mechanismus verhindert, dass das anfängliche Handshake-Paket erneut an den Netzwerk-Stack gesendet wird, und warum im eBPF-Filter ein bestimmter UDP-Paketwert geprüft wird.

• Wie kann man eine beliebige dockerisierte Anwendung auf Fly.io deployen? Nehmt mein Geld.

  • Es wird Interesse und Bereitschaft bekundet, eine dockerisierte Anwendung auf Fly.io zu deployen.

• Für alle anderen werde ich schamlos Netmaker bewerben.

  • Es werden gute Erfahrungen mit Netmaker geteilt, die persönliche Notwendigkeit des Zugriffs auf eine AWS VPC erwähnt und der Wunsch geäußert, dass Netmaker breiter angenommen wird.