====== nftables ======
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
}
}
systemctl restart nftables
---
### **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:
1. Das Paket kommt auf `eth0` an.
2. 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.
3. Das Paket wird weitergeleitet (forward chain erlaubt das).
4. 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).
5. 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!