Zum Inhalt

Netzwerk

Diese Seite beschreibt, wie unsere Hosts miteinander verbunden sind, welcher Verkehr wohin darf und welche Firewalls dazwischen liegen.

Überblick

flowchart LR
    internet(["Internet"])

    subgraph netcup ["Netcup"]
        fw["Netcup-Firewall<br>nur 80, 443, WireGuard"]
        werner["werner<br>firewalld"]
    end

    subgraph vorort ["Maschinendorf"]
        gw["Gateway<br>maschinendorf.resolve.bar"]
        subgraph vlan ["Server-VLAN"]
            ch["containerhost"]
            nas[("NAS")]
        end
    end

    internet --> fw --> werner
    werner <-->|WireGuard-Tunnel| gw
    gw <--> ch
    ch -->|NFS| nas

Server-VLAN und Gateway

Im Maschinendorf liegen containerhost, der Proxmox-Host und das NAS in einem eigenen VLAN für Server, getrennt vom übrigen Netz vor Ort. So kommen Geräte von Mitgliedern und Gästen im Netz vor Ort nicht an containerhost und das NAS heran.

Das Gateway verbindet dieses VLAN mit dem Internet, aber nur in eine Richtung: Die Geräte im VLAN dürfen ins Internet, aus dem Internet kommt niemand ins VLAN hinein, außer über eigene VPN-Tunnel, die auf dem Gateway enden. Einer davon ist der WireGuard-Tunnel, über den werner mit dem Server-VLAN verbunden ist. Ein anderer ist das Admin-VPN, ebenfalls mit WireGuard; den Zugang vergeben die Admins des Maschinendorfs. Per SSH erreichen wir containerhost nur darüber oder vor Ort aus dem Zauberer-WLAN, dem Netz für die Administration.

Die Namen unter garage-lab.net, etwa vm-containerhost.garage-lab.net, löst der DNS-Server auf dem Gateway auf, nicht deSEC (siehe DNS). werner fragt ihn über den Tunnel; er steht in /etc/resolv.conf auf werner als erster Nameserver.

Das Gateway betreibt das Maschinendorf. Gateway, VLAN und die Firewall-Regeln vor Ort sind nicht Teil dieses Repos und werden hier nicht beschrieben. Die Doku geht davon aus, dass der Verkehr aus dem Tunnel bei containerhost ankommt.

WireGuard-Tunnel

werner und das Gateway sind über einen verschlüsselten WireGuard-Tunnel verbunden. werner baut ihn zum Gateway auf, das über den DynDNS-Namen maschinendorf.resolve.bar erreichbar ist, und hält ihn dauerhaft offen. Diese Richtung, weil der Anschluss im Maschinendorf keine feste IP-Adresse hat, werner dagegen schon.

Durch den Tunnel läuft nur Verkehr zwischen werner und dem Server-VLAN:

Von Nach Wofür
werner containerhost, rest-server Backups (siehe Backup)
containerhost, Prometheus werner, Exporter und Caddy Messwerte abholen (siehe Monitoring)
werner Gateway, DNS-Server Namen unter garage-lab.net auflösen

So laufen Backups und Messwerte nie unverschlüsselt durch das Internet, und weder der rest-server noch die Exporter müssen aus dem Internet erreichbar sein. Nach außen ist nur der WireGuard-Port offen, und er antwortet nur Gegenstellen mit dem passenden Schlüssel.

Die Firewall auf dem Gateway lässt Verkehr von werner nur zu containerhost und zum DNS-Server auf dem Gateway selbst durch; alles andere im Netz vor Ort ist für werner gesperrt. Wird werner kompromittiert, kommt man von dort über den Tunnel also nur bis containerhost, nicht an das NAS oder andere Geräte vor Ort. Auch über containerhost lassen sich die vorhandenen Backups nicht löschen (siehe Backup).

Eingerichtet ist der Tunnel auf werner von Hand mit NetworkManager, wie in WireGuard-Tunnel einrichten.

Firewalls bei werner

werner wird von zwei Firewalls geschützt, die hintereinander liegen:

  1. Die Netcup-Firewall vor der VM, eingestellt in der Web-Oberfläche von Netcup (siehe Netcup). Sie lässt aus dem Internet nur die Ports 80 und 443 für Caddy und den Port für WireGuard durch.
  2. firewalld auf werner selbst. Der Tunnel (wg0) und die Netze der Podman-Container stehen dort in der Zone trusted, ihr Verkehr ist also erlaubt.

Die Netcup-Firewall entscheidet, was überhaupt aus dem Internet ankommt, unabhängig davon, was auf der VM eingestellt ist. Daraus folgt: Ports, die Container auf werner auf allen Netzwerkschnittstellen veröffentlichen, etwa die Exporter für das Monitoring, sind aus dem Internet nicht erreichbar, weil die Netcup-Firewall sie nicht durchlässt. Über den Tunnel sind sie erreichbar, und das ist gewollt: So holt Prometheus auf containerhost die Messwerte ab.

Die internen Podman-Netzwerke müssen in firewalld bekannt sein, damit ihre Container untereinander sprechen dürfen. Das erledigt das Skript rootfs/werner/usr/bin/fix-podman-internal-networks; wann man es braucht, steht in Interne Podman-Netzwerke reparieren. Das Skript ist eine Übergangslösung: Der Fehler ist upstream schon behoben, aber noch nicht in einer veröffentlichten Version; sobald sie auf den Hosts ist, wird das Skript nicht mehr gebraucht.

Weiterlesen