netpolicyd – Routing, Firewall und NAT als Soll-Zustand für Linux-Hosts | Mohammad Mahdi Afshar

Was es ist

netpolicyd hält eine Soll-Netzwerkkonfiguration für einen Linux-Host – Routen, Richtlinienregeln, Adressen, Firewall, NAT, Traffic Control und Sysctls – und wendet sie mit ip, nft, tc und sysctl an. netpolicyctl ist das Bedienpult: eine Terminaloberfläche mit einfachem und erweitertem Modus, dazu eine CLI.

Was es verwaltet

Bereich	Angewendet mit
Richtlinien	Geordnete High-Level-Regeln, die zu `ip rule` / Tabellenrouten / NAT werden
Routen und IP-Regeln	`ip route`, `ip rule`
Adressen und Links	`ip addr`, `ip link`
Firewall und NAT	nftables (Masquerade, SNAT, Forward-Helfer)
IP-Listen	Benannte CIDR-Gruppen, übersetzt in nft-Sets
Traffic Control	HTB-Shaping ausgehend, Policing eingehend
Sysctls	`ip_forward`, `rp_filter`, …

Es zeigt auch den Live-Zustand: einen schreibgeschützten Auszug aus Firewall und Routing des Hosts sowie Interface-Raten und Socket-Übersicht aus /proc/net/dev und ss.

Das Anwendungsmodell

Soll-Objekte werden über die API geschrieben (oder gesammelt mit PUT /v1/desired ersetzt).
POST /v1/apply erstellt einen geordneten Befehlsplan. ?dry_run=1 liefert denselben Plan, ohne den Host anzufassen.
Die verwaltete Firewall wird als ein nft -f-Skript erzeugt, das die Tabelle inet netpolicyd in einer einzigen Transaktion deklariert, löscht und neu definiert – kein halb angewendeter Zustand, keine gestapelten Duplikate. Regeln außerhalb dieser Tabelle bleiben unberührt.
IP-Listen werden zu benannten nft-Sets, nicht zu einer Regel pro Adresse; eine große Länderliste ist damit ein Set-Lookup statt Tausender Regeln.
Richtlinienrouten liegen in einem Prioritätsbereich, der netpolicyd gehört. Regeln in diesem Bereich, die die aktuelle Generation nicht verlangt, werden entfernt – aber nie bei leerer Behalten-Liste, denn direkt nach einem Neustart heißt „leer“ „noch nichts mitgeteilt“, nicht „nichts soll existieren“.

Beispiel: Ausgang nach Quelle

curl -s -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"src-via-gre-lab","priority":10,
       "subjects":[{"kind":"cidr","value":"10.77.0.4/32"}],
       "destination":{"kind":"any","value":"0.0.0.0/0"},
       "action":"egress","egress_name":"gre-lab","source_cidr":"10.77.0.4/32"}' \
  http://127.0.0.1:51910/v1/policies
netpolicyctl apply

Das plant eine ip rule und eine Routingtabelle mit Standardroute über gre-lab, dazu Masquerading über dieses Gerät, sofern nicht bereits ein expliziter NAT-Eintrag es abdeckt.

Grenzen

Der Soll-Zustand liegt im Speicher. Nach einem Neustart muss ihn etwas – eine Control Plane oder ein Skript – erneut übergeben; der Kernel-Zustand bleibt bis dahin bestehen.
Live-Anwendung braucht CAP_NET_ADMIN. Ohne ip-Binary oder mit --mock wird nur geplant.
Die API gehört auf Loopback oder in ein privates Management-Netz.

Technik

Go, Bubble Tea für die TUI, nftables, iproute2, tc. Lizenziert unter der GNU AGPL v3.