Network-Appliance-Evaluierung

Dieser Guide erstellt ein Debian-Image mit zwei Interfaces für ein WireGuard-, DNS- und Routing-Lab. Produktivnutzung braucht exakte Interface-Map, geprüfte Firewall-Policy, echte Key-Custody, Hardware-Treiber-Tests und einen Recovery-Pfad.

Prompt

Create a Debian Trixie headless network-appliance evaluation image with two
NICs, SSH, firewall, WireGuard, dnsmasq, nftables, and IP forwarding. Keep
WireGuard private keys and site addresses out of the recipe. Create a locked
operator account and require key-only SSH only after its public key path is
verified. Add a client VM scenario that proves DHCP/DNS behavior, routed
traffic, allowed management access, and denied traffic.

Rezeptform

{
  "name": "branch-network-appliance-evaluation",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 2,
    "min_storage_gb": 16,
    "nic_count": 2
  },
  "os": {
    "features": ["headless", "ssh", "firewall", "vpn-wireguard"],
    "packages": ["dnsmasq", "nftables"],
    "users": [
      {
        "username": "operator",
        "groups": ["sudo"],
        "shell": "/bin/bash"
      }
    ],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {
          "port": 2222,
          "allow_root": false,
          "disable_password_auth": true
        }
      }
    ],
    "startup_scripts": [
      {
        "name": "enable-ip-forwarding",
        "description": "Persist the reviewed IPv4 forwarding setting.",
        "command": "set -Eeuo pipefail\nprintf '%s\\n' 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openfactory-forwarding.conf\nsysctl --system >/dev/null",
        "packages": [],
        "run_as": "root",
        "after": "network.target"
      }
    ]
  }
}

Ein anderer SSH-Port reduziert Scan-Rauschen, ist aber kein Authentifizierungs-Control. Key-only SSH ist wertvoll erst nach installiertem und getestetem Key.

Den Datenpfad testen, nicht nur Pakete

Eine einzelne VM kann zeigen, dass wg, dnsmasq und nftables existieren und Forwarding aktiv ist. Client-Verhalten beweist sie nicht. Bauen Sie eine Topologie mit mindestens:

• Appliance mit WAN- und LAN-Interfaces;
• LAN-Client ohne alternativen Default-Route; und
• begrenztem Upstream-Service oder Probe.

Prüfen Sie DHCP-Lease, DNS-Forwarding, beabsichtigte Routen, NAT falls nötig, WireGuard-Handshake mit Test-Keys, erlaubten Management-Zugriff und abgelehnten unaufgeforderten Traffic. Negative Tests einbeziehen, damit eine permissive Firewall nicht durchrutscht.

Deployment-Grenze

Zur Deployment-Zeit getrennt prüfen:

• Zuordnung VM-Interface-Reihenfolge zu physischen NIC-Namen und MAC-Adressen;
• Private-Key-Generierung, Storage, Rotation und Revocation;
• genehmigte Subnetze, Routen, Forwarding, NAT und DNS-Policy;
• IPv6-Verhalten statt stilles Deaktivieren;
• Updates ohne Management-Zugriff zu kappen;
• Config-Backup und Offline-Recovery; und
• Fail-open/Fail-closed nach Link-, DNS-, Clock- und Stromausfällen.

Validieren Sie die exakte Appliance-Hardware vor Produktivnutzung.