root@matellb:~# cat /etc/nftables.d/proxy.conf
#!/sbin/nft -f
 
flush ruleset
 
table ip filter {
    # allow all packets sent by the firewall machine itself
    chain output {
        type filter hook output priority 100; policy accept;
    }
 
    # allow LAN to firewall, disallow WAN to firewall
    chain input {
        type filter hook input priority 0; policy accept;
        iifname "wg0" accept
        iifname "eth0" accept
    }
 
    # allow packets from WG to WAN, and WAN to WG
    chain forward {
        type filter hook forward priority 0; policy accept;
        iifname "wg0" oifname "eth0" accept
        iifname "eth0" oifname "wg0" accept
    }
}
 
 
table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        masquerade
    }
 
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        ip daddr 128.140.47.251 tcp dport { 80, 443 } dnat to 192.168.8.10
        ip daddr 116.202.187.170 tcp dport { 80, 443 } dnat to 192.168.8.22
    }
}

Klar, ich erkläre dir, wie deine nftables-Konfiguration funktioniert und wie damit Traffic von einem VServer zu einem anderen über eine WireGuard-Verbindung geleitet wird.

Was macht diese Konfiguration? 1. Filter-Table

output: Erlaubt alle ausgehenden Pakete vom Server selbst (Policy: accept).

input: Erlaubt alle eingehenden Pakete auf die Interfaces wg0 (WireGuard) und eth0 (vermutlich dein öffentliches Interface).

forward: Erlaubt das Weiterleiten von Paketen:

Von wg0 nach eth0 (also von WireGuard ins Internet) Von eth0 nach wg0 (also vom Internet ins WireGuard-Netz) 2. NAT-Table

postrouting: Alle Pakete, die den Server verlassen, werden mit masquerade versehen. Das heißt, ihre Quell-IP wird auf die öffentliche IP des Servers gesetzt (Source NAT). Das ist wichtig, damit Antworten an den Server zurückkommen.

prerouting: Hier findet Destination NAT (DNAT) statt:

Pakete, die an die öffentliche IP 128.140.47.251 auf Port 80 oder 443 gehen, werden an 192.168.8.10 weitergeleitet. Pakete, die an die öffentliche IP 116.202.187.170 auf Port 80 oder 443 gehen, werden an 192.168.8.22 weitergeleitet. Wie funktioniert das Routing über WireGuard?

Angenommen, du hast zwei VServer:

VServer1: Öffentliche IP (z.B. 128.140.47.251), WireGuard-Interface wg0, internes Netz 192.168.8.0/24 VServer2: WireGuard-IP 192.168.8.10 (oder .22)

Wenn jetzt jemand von außen (Internet) auf 128.140.47.251:80 zugreift:

Das Paket kommt auf eth0 an. Die NAT-Regel in prerouting sorgt dafür, dass das Ziel von 128.140.47.251:80 auf 192.168.8.10:80 geändert wird. Das Paket wird weitergeleitet (forward chain erlaubt das). Das Routing sorgt dafür, dass Pakete ins Netz 192.168.8.0/24 über das Interface wg0 geschickt werden (das musst du in deiner Routing-Tabelle sicherstellen). Das Paket wird über das WireGuard-Interface an VServer2 (192.168.8.10) geschickt.

Die Antwortpakete von VServer2 gehen zurück über WireGuard zu VServer1, werden dort per masquerade mit der öffentlichen IP versehen und ins Internet zurückgeschickt.

Was musst du noch beachten?

Routing: Dein VServer1 muss wissen, dass das Netz 192.168.8.0/24 über das Interface wg0 erreichbar ist. Das geht meist automatisch, wenn WireGuard läuft, kannst du aber mit ip route prüfen.

WireGuard-Konfiguration: Die Peers müssen korrekt eingerichtet sein, damit die Pakete auch wirklich über das VPN gehen.

Firewall auf VServer2: VServer2 muss Verbindungen von VServer1 (bzw. aus dem WireGuard-Netz) auf den gewünschten Ports erlauben.

Zusammengefasst:

Deine Konfiguration sorgt dafür, dass Traffic, der auf bestimmte öffentliche IPs und Ports ankommt, per DNAT ins WireGuard-Netz umgeleitet wird. Die Weiterleitung und das NAT sorgen dafür, dass die Pakete korrekt ankommen und die Antworten zurück ins Internet finden.

Wenn du noch Fragen hast oder ein konkretes Beispiel durchgehen willst (z.B. wie die WireGuard-Konfig aussehen muss), sag Bescheid!