networkingd

Was es ist

networkingd ist eine Control Plane für viele VPN-Gateway-Knoten. Sie verwaltet Nutzer, Gruppen, Tarife, Geräte und Richtlinien, übersetzt sie in einen Soll-Zustand pro Knoten und liefert Client-Konfigurationen aus. Auf jedem Gateway läuft ein Node-Agent, der seinen Soll-Zustand abruft und die lokalen Data-Plane-Daemons daran angleicht.

Ebene	Rolle
Eingang	Tunnel der Endnutzer hinein (WireGuard, OpenVPN, OpenConnect)
Ausgang	Ausgehende Pfade von den Gateway-Knoten
Richtlinien	Wer welchen Knoten, Eingang, Ausgang und welche Limits nutzen darf
Flotte	Viele Gateways unter einer Control Plane
Identität	Nutzer, Gruppen, Tarife, Abonnements
Portal-API	Was Client-Apps und das Webportal aufrufen

Architektur

  Client apps / web portal / admin console
              │  HTTPS + bearer token
              ▼
      controlplane (Go, REST /v1/*)
              │  node token + desired state
      ┌───────┴───────┐
      ▼               ▼
  node-agent      node-agent   … N
      │               │
      ▼               ▼
  local daemons over HTTP / Unix sockets only
  wireguardd · openvpnd · openconnectd · dnsd · netpolicyd

Die Grenzregeln sind streng und schriftlich festgehalten: Die Control Plane importiert nie Interna eines Daemons und ruft nie wg oder openvpn über eine Shell auf; der Agent spricht mit lokalen Daemons ausschließlich über deren HTTP-APIs; und Client-Apps sprechen nur mit der Portal-API, nie direkt mit einem Knoten. Jeder Daemon ist ein eigenes Repository – wireguardd, openvpnd, openconnectd, dnsd und netpolicyd – und als Submodul eingebunden.

Der Node-Agent

• Tritt der Control Plane mit Wiederholungen bei und betreibt dann zwei Schleifen.
• Heartbeats laufen in einer eigenen Goroutine, damit eine lange Paketinstallation während des Abgleichs den Knoten nicht tot erscheinen lässt.
• Die Abgleichschleife fragt den Soll-Zustand in zufällig gestreuten Abständen ab. Jeder Snapshot hat eine Generation; der Agent wendet WireGuard, OpenVPN, OpenConnect und Routing an, meldet den beobachteten Zustand und vermerkt die Generation nur dann als angewendet, wenn alle Teile erfolgreich waren. Ein Teilerfolg wird als partial gemeldet, und dieselbe Generation wird erneut versucht.
• Das Routing wird auch bei unveränderter Generation regelmäßig erneut an netpolicyd übergeben, weil dieser Daemon seinen Soll-Zustand im Speicher hält und ihn bei einem Neustart verliert.

Umfang und Status

Es ist eine interne Produkt-Control-Plane, kein öffentliches mandantenfähiges SaaS. Die Portal-API (Anmeldung, Geräte, Ausgang, Abrechnung, Tickets) und die Admin-Konsole sind im Einsatz; native Client-Apps werden noch entworfen und gebaut; IKEv2 und SSO/OIDC sind geplant, aber nicht ausgeliefert. Der Quellcode ist nicht öffentlich.

Technik

Go und chi für Control Plane und Agent; React 19, TanStack Start / Router / Query / Table, shadcn/ui und Tailwind v4 für Admin-Konsole und Portal; Prometheus und Alertmanager für das Monitoring.