Natürlich bevorzugen wir es, wenn Sie Ihre ganze Infrastruktur in der dataforest cloud betreiben. Mit einem Seed als DDoS-Proxy können Sie unsere DDoS-Protection aber auch für Server nutzen, die gar nicht bei uns stehen. Der Seed bekommt die öffentliche Adresse, unsere Filter übernehmen den Angriffsschutz, und ein WireGuard-Tunnel bringt nur die sauberen Pakete zu Ihrem Server, egal ob der bei einem anderen Anbieter, im Homelab oder im eigenen Rechenzentrum läuft. Ihre Infrastruktur bleibt, wo sie ist.
Für wen sich der Proxy eignet
Der Proxy schützt jeden Dienst, der über feste TCP- oder UDP-Ports erreichbar ist. Typische Fälle:
- Homelab. Ein Gameserver oder Voice-Server zu Hause, oft hinter Carrier-Grade-NAT ohne eigene öffentliche Adresse. Der Tunnel wird von Ihrem Server aus aufgebaut, deshalb braucht er weder Portfreigabe noch feste Adresse. Ein Angriff trifft den Seed, nicht Ihren Internetanschluss.
- Server bei einem anderen Anbieter. Der Schutz dort kennt Spielprotokolle nicht oder sperrt bei Angriffen die ganze Adresse. Der Seed übernimmt die öffentliche Adresse, Ihr Server bleibt, wo er ist.
- Eigenes Rechenzentrum oder Büro. Dienste, die nach außen erreichbar sein müssen, bekommen eine geschützte Adresse, ohne dass Ihre Anbindung selbst Ziel wird.
Für viele Anwendungen gibt es Filter, die das jeweilige Protokoll kennen: Minecraft Java, FiveM, DayZ, TeamSpeak 3, WireGuard, OpenVPN, SSH, Remote Desktop und Webanwendungen. Alle anderen TCP- und UDP-Dienste können Sie mit generischen Filtern schützen. Ein Seed kann dabei mehrere Server und Dienste gleichzeitig schützen, dazu mehr am Ende.
Wie der Proxy funktioniert
Ein Nutzer verbindet sich mit der Adresse des Seeds. Bevor das Paket den Seed erreicht, prüft die DDoS-Protection an unserer Netzwerkgrenze, ob es zu einer geschützten Anwendung passt. Alles andere wird verworfen. Auf dem Seed schreibt eine nftables-Regel die Zieladresse um, von der öffentlichen Adresse des Seeds auf die Tunnel-Adresse Ihres Servers. Die Absenderadresse bleibt unverändert. Das Paket geht durch den WireGuard-Tunnel zu Ihrem Server, der den Nutzer mit seiner echten IP-Adresse sieht.
Die Antwort nimmt denselben Weg zurück. Dafür braucht Ihr Server eine Routing-Regel: Alles, was von der Tunnel-Adresse abgeschickt wird, geht in den Tunnel statt über die normale Netzwerkkarte. Auf dem Seed setzt die Verbindungsverfolgung die ursprüngliche Adresse wieder ein.
Zwei Dinge sind entscheidend, damit der Schutz hält:
- Die echte Adresse Ihres Servers darf niemand kennen. Der Proxy schützt nur den Traffic, der über ihn läuft. Wer die Adresse dahinter kennt, kann direkt angreifen.
- Ihr Server nimmt Verbindungen nur noch aus dem Tunnel an. Am besten hat er gar keine öffentliche Adresse. Alte DNS-Einträge, die direkt auf ihn zeigen, müssen weg.
Voraussetzungen
- Ein Seed mit IPv4-Adresse. Wie Sie ihn auswählen, steht im nächsten Abschnitt.
- Ein Server mit Root-Zugriff, auf dem Ihr Dienst läuft. Er braucht keine öffentliche Adresse, der Tunnel wird von ihm aus aufgebaut.
- SSH-Zugriff auf beide Maschinen.
In dieser Anleitung schützen wir beispielhaft einen Minecraft-Server im Homelab. Er läuft auf einem Linux-Rechner hinter einem Heimrouter, hat keine öffentliche Adresse und hört auf Port 25565, so wie ihn die Minecraft-Anleitung aufsetzt. Der Seed hat die öffentliche Adresse 198.51.100.10. Der Tunnel nutzt das Netz 10.100.0.0/24, der Seed ist 10.100.0.1, Ihr Server 10.100.0.2.
Seed erstellen
Erstellen Sie einen Seed mit IPv4-Adresse. Die individuellen Filter werden je IPv4-Adresse gebucht, ohne sie gibt es keinen Proxy.
Bei der Wahl der Line spielen CPU und Arbeitsspeicher keine Rolle, Verschlüsseln und Weiterleiten kosten kaum Rechenleistung. Entscheidend sind die Netzwerkanbindung und das Traffic-Kontingent, denn der gesamte Traffic Ihrer Nutzer läuft zweimal über den Seed, hinein und hinaus. Wir empfehlen deshalb einen Standard XS wegen des inkludierten Traffics und der besseren Datenrate. Für einen einzelnen Webserver reicht auch ein Entry S. Wird es eng, können Sie den Seed jederzeit auf ein größeres Modell upgraden.
Als Betriebssystem eignet sich Debian 13. WireGuard steckt dort bereits im Kernel, die Werkzeuge zum Einrichten müssen Sie nachinstallieren. Verbinden Sie sich per SSH mit dem Seed:
apt update
apt install -y wireguard-tools nftables
Erscheint die Meldung Could not get lock /var/lib/dpkg/lock-frontend, laufen noch die automatischen Updates nach dem ersten Start. Warten Sie eine Minute und versuchen Sie es erneut.
DDoS-Protection konfigurieren
Jeder Seed ist von Anfang an durch die automatischen Filter der DDoS-Protection geschützt. Für viele Anwendungen haben wir darüber hinaus Filter, die genau das jeweilige Protokoll kennen und alles verwerfen, was nicht dazu passt. Diese individuellen Filter empfehlen wir für jeden Server, dessen Adresse öffentlich ist. Sie werden je IPv4-Adresse gebucht und stundengenau abgerechnet. Für unser Beispiel gibt es sie sowohl für Minecraft Java als auch für WireGuard, der Proxy ist also rundum abgedeckt.
Öffnen Sie in der Cloud-Konsole den Bereich DDoS-Protection, klicken Sie auf Konfigurieren und richten Sie die Adresse des Seeds so ein:
- Unter Geschützte Ressourcen die IPv4-Adresse des Seeds hinzufügen.
- Den Typ auf Individuelle Filter stellen.
- Unter Geschützte Anwendungen über Anwendung schützen drei Einträge aus dem Katalog anlegen: Minecraft Java für Port 25565, WireGuard für den Tunnel und SSH für Ihren Zugang.
- Die Standardaktion auf Blockieren stellen. Damit ist jeder Port geschlossen, der zu keiner geschützten Anwendung gehört. Prüfen Sie vor dem Bestellen, dass SSH und WireGuard in der Liste stehen, sonst sperren Sie sich und den Tunnel aus.
Läuft bei Ihnen ein anderer Dienst, wählen Sie statt Minecraft Java die passende Anwendung aus dem Katalog. Für Dienste, die dort nicht stehen, gibt es Sonstige Anwendungen, bei denen Sie Protokoll und Port selbst angeben. Jeder Dienst, der später durch den Proxy laufen soll, braucht hier einen Eintrag. Sie können die Konfiguration jederzeit anpassen, ohne neue Kosten.
Schlüssel erzeugen
WireGuard braucht auf jeder Seite ein Schlüsselpaar, und jede Seite muss den öffentlichen Schlüssel der anderen kennen. Auf dem Seed:
umask 077
wg genkey | tee /etc/wireguard/seed.key | wg pubkey > /etc/wireguard/seed.pub
cat /etc/wireguard/seed.pub
Auf Ihrem Server brauchen Sie dieselben Werkzeuge, unter Debian und Ubuntu:
apt install -y wireguard-tools
umask 077
wg genkey | tee /etc/wireguard/origin.key | wg pubkey > /etc/wireguard/origin.pub
cat /etc/wireguard/origin.pub
Notieren Sie beide öffentlichen Schlüssel. Die privaten Schlüssel bleiben, wo sie sind.
WireGuard auf dem Seed
Erstellen Sie auf dem Seed die Datei /etc/wireguard/wg0.conf:
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <Inhalt von /etc/wireguard/seed.key>
[Peer]
PublicKey = <Inhalt von /etc/wireguard/origin.pub auf Ihrem Server>
AllowedIPs = 10.100.0.2/32
Der Seed hört auf UDP-Port 51820 und akzeptiert vom Peer nur Pakete mit der Tunnel-Adresse 10.100.0.2 als Absender. Mehr braucht er nicht, denn die Antworten Ihres Servers kommen immer von dieser Adresse.
Erlauben Sie dem Seed, Pakete weiterzuleiten, und starten Sie den Tunnel:
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-proxy.conf
sysctl -p /etc/sysctl.d/99-proxy.conf
systemctl enable --now wg-quick@wg0
Traffic über den Seed leiten
Prüfen Sie zuerst den Namen der öffentlichen Netzwerkschnittstelle des Seeds, in den Beispielen eth0:
ip -br link
Ersetzen Sie dann den Inhalt von /etc/nftables.conf auf dem Seed:
#!/usr/sbin/nft -f
flush ruleset
table ip proxy {
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
iifname "eth0" tcp dport 25565 dnat to 10.100.0.2
}
chain forward {
type filter hook forward priority filter; policy drop;
tcp flags syn tcp option maxseg size set rt mtu
ct state established,related accept
iifname "eth0" oifname "wg0" ip daddr 10.100.0.2 tcp dport 25565 accept
}
}
Das passiert dabei: Die dnat-Regel schreibt bei jedem Paket, das auf Port 25565 ankommt, die Zieladresse auf die Tunnel-Adresse Ihres Servers um. Der Absender bleibt stehen, es gibt bewusst keine masquerade-Regel, sonst sähe Ihr Server nur noch den Seed. Die maxseg-Regel passt die TCP-Segmentgröße an den Tunnel an, ohne sie bleiben große Pakete stecken und Spieler fliegen beim Laden der Welt raus. Die forward-Kette lässt nur die umgeschriebenen Pakete und deren Antworten durch, alles andere darf der Seed nicht weiterleiten.
Für einen anderen Dienst müssen Sie in der dnat- und in der forward-Regel Port und Protokoll ändern, etwa udp dport 9987 für TeamSpeak 3 oder tcp dport 3389 für Remote Desktop. Die maxseg-Regel bleibt stehen, sie wirkt nur auf TCP.
Aktivieren Sie das Regelwerk:
systemctl enable --now nftables
nft -f /etc/nftables.conf
nft list ruleset
Damit ist der Seed fertig. Er nimmt Verbindungen auf Port 25565 an und wartet darauf, dass Ihr Server den Tunnel aufbaut.
WireGuard auf Ihrem Server
Erstellen Sie auf Ihrem Server die Datei /etc/wireguard/wg0.conf:
[Interface]
Address = 10.100.0.2/24
PrivateKey = <Inhalt von /etc/wireguard/origin.key>
Table = off
PostUp = ip rule add from 10.100.0.2 table 100 priority 100
PostUp = ip route add default dev wg0 table 100
PostDown = ip rule del from 10.100.0.2 table 100 priority 100
PostDown = ip route flush table 100
[Peer]
PublicKey = <Inhalt von /etc/wireguard/seed.pub auf dem Seed>
Endpoint = 198.51.100.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Die Einstellungen im Einzelnen:
AllowedIPs = 0.0.0.0/0erlaubt Pakete von jeder Absenderadresse durch den Tunnel. Das ist nötig, weil die Spieler mit ihren echten Adressen ankommen.Table = offverhindert, dass WireGuard deshalb den gesamten Traffic Ihres Servers durch den Tunnel schickt. Ohne diese Zeile wäre Ihr Server nach dem Start nicht mehr erreichbar.- Die
PostUp-Zeilen legen die Routing-Regel an: Pakete mit Absender10.100.0.2gehen in den Tunnel. Das sind genau die Antworten an die Spieler. Alles andere, etwa Paketupdates, nimmt weiter den normalen Weg. PersistentKeepalive = 25hält den Tunnel auch hinter dem Heimrouter offen.
Starten Sie den Tunnel und prüfen Sie, ob der Seed erreichbar ist:
systemctl enable --now wg-quick@wg0
ping -c 3 10.100.0.1
Der Ping läuft durch den Tunnel, von außen ist das für die DDoS-Protection nur WireGuard-Traffic. Eine geschützte Anwendung Ping brauchen Sie dafür nicht. Antwortet der Seed nicht, zeigt wg show auf beiden Seiten, ob ein Handshake zustande kam. Fehlt er, stimmen meist die Schlüssel nicht, oder WireGuard ist in der DDoS-Protection noch nicht geschützt.
Verbindung testen
Öffnen Sie Minecraft und verbinden Sie sich mit der Adresse des Seeds, im Beispiel 198.51.100.10. Auf Ihrem Server zeigt das Minecraft-Log den Spieler mit seiner echten Adresse:
[Server thread/INFO]: Steve[/203.0.113.7:51234] logged in with entity id 118
Steht dort 10.100.0.1, läuft die Weiterleitung noch mit Masquerade, oder die Routing-Regel auf Ihrem Server fehlt. Prüfen Sie ip rule und ip route show table 100.
Auf dem Seed sehen Sie die weitergeleiteten Verbindungen mit:
conntrack -L -p tcp --dport 25565
Falls conntrack fehlt: apt install conntrack.
Server abschotten und Adresse umstellen
Nach außen gibt es ab jetzt nur noch die Adresse des Seeds. Sie ist die Adresse für Ihre Nutzer, und Ihr Server soll nur noch über den Seed erreichbar sein. Am besten ist er aus dem Internet gar nicht erreichbar: Im Homelab brauchen Sie dann keine Portfreigabe am Router, bei einem Cloud-Anbieter keine öffentliche IP-Adresse. Haben Sie früher eine Portfreigabe für den Minecraft-Server eingerichtet, entfernen Sie sie jetzt.
Hat Ihr Server trotzdem eine öffentliche Adresse, richten Sie eine Firewall ein, die auf Port 25565 nur noch Verbindungen aus dem Tunnel annimmt, und geben Sie die Adresse nirgends heraus. Eine Firewall schützt nicht vor DDoS-Angriffen, sie verhindert nur, dass jemand am Proxy vorbei direkt auf Ihren Server kommt. Mit ufw sind das zwei Regeln:
ufw allow in on wg0 to any port 25565 proto tcp
ufw deny 25565/tcp
Ist ufw auf dem Server noch nicht aktiv, erlauben Sie zuerst SSH und schalten es dann ein, sonst sperren Sie sich aus:
ufw allow OpenSSH
ufw enable
Mit nftables statt ufw lässt sich dasselbe so erreichen:
nft add table inet origin
nft add chain inet origin input '{ type filter hook input priority filter; policy accept; }'
nft add rule inet origin input iifname "wg0" tcp dport 25565 accept
nft add rule inet origin input tcp dport 25565 drop
Auch hier gilt das Minecraft-Beispiel: Port und Protokoll gehören zu Ihrer Anwendung. Für einen UDP-Dienst lauten die ufw-Regeln entsprechend proto udp und 9987/udp.
Zeigen Sie anschließend den DNS-Eintrag Ihrer Domain auf die Adresse des Seeds, und löschen Sie alle Einträge, die noch direkt auf Ihren Anschluss oder Server zeigen. War die Adresse schon länger öffentlich bekannt, etwa in Serverlisten, hilft am Ende nur eine neue Adresse. Angreifer speichern sich Adressen.
Mehrere Server und Dienste schützen
Ein Seed kann beliebig viele Server schützen. Jeder weitere Server bekommt ein eigenes Schlüsselpaar, eine eigene Tunnel-Adresse und einen eigenen [Peer]-Block in der wg0.conf des Seeds:
[Peer]
PublicKey = <öffentlicher Schlüssel des zweiten Servers>
AllowedIPs = 10.100.0.3/32
Auf dem zweiten Server sieht die wg0.conf aus wie oben, nur mit Address = 10.100.0.3/24 und 10.100.0.3 in den PostUp- und PostDown-Zeilen. Jeder weitere Dienst, egal auf welchem Server, braucht dann drei Dinge: eine dnat-Regel und eine forward-Regel auf dem Seed sowie einen Eintrag bei den geschützten Anwendungen. Für einen TeamSpeak-Server auf Port 9987/UDP auf dem zweiten Server zum Beispiel:
iifname "eth0" udp dport 9987 dnat to 10.100.0.3
iifname "eth0" oifname "wg0" ip daddr 10.100.0.3 udp dport 9987 accept
Ein Port, eine Adresse. Eine öffentliche Adresse kann jeden Port nur einmal vergeben. Wollen Sie zwei Minecraft-Server schützen, haben Sie zwei Möglichkeiten:
- Der zweite Server weicht vom Standardport ab, etwa auf 25566. In der DDoS-Protection fügen Sie der Anwendung Minecraft Java diesen Port als weiteren Dienst hinzu, auf dem Seed zeigt die
dnat-Regel für Port 25566 auf den zweiten Server. Spieler müssen die Adresse dann als198.51.100.10:25566eingeben. - Lässt sich der Port nicht ändern, können Sie dem Seed eine weitere IPv4-Adresse dazubuchen. Die DDoS-Protection lässt sich im Konfigurator auf die neue Adresse kopieren, indem Sie sie unter Geschützte Ressourcen hinzufügen. Auf dem Seed müssen die Regeln dann nach Zieladresse unterscheiden, etwa
ip daddr 198.51.100.11 tcp dport 25565 dnat to 10.100.0.3.
UDP-Dienste. Die Anwendung muss ihre Antworten von der Tunnel-Adresse verschicken, damit die Routing-Regel greift. TCP-Dienste tun das automatisch, UDP-Dienste nur, wenn sie an diese Adresse gebunden sind. Bei TeamSpeak ist das die Einstellung voice_ip=10.100.0.3, bei Spielen auf der Source-Engine der Startparameter -ip 10.100.0.3. Bietet eine Anwendung keine solche Einstellung, bleibt nur die Weiterleitung mit masquerade auf dem Seed. Sie funktioniert immer, dann sieht der Dienst aber nur noch die Adresse des Seeds statt der Spieler.
Server ohne IPv4
Die IPv4-Adresse braucht nur der Seed, weil die DDoS-Protection je IPv4-Adresse gebucht wird. Die Server dahinter brauchen keine. Das gilt für das Homelab hinter DS-Lite oder Carrier-Grade-NAT genauso wie für einen Server bei einem anderen Anbieter, der nur eine IPv6-Adresse hat.
Dafür muss sich nur die Gegenstelle des Tunnels ändern: Tragen Sie als Endpoint in der wg0.conf Ihres Servers die IPv6-Adresse des Seeds ein, zum Beispiel [2001:db8::1]:51820. Jeder Seed hat eine IPv6-Adresse. WireGuard transportiert das innere Tunnel-Netz 10.100.0.0/24 dann über IPv6, am Rest der Anleitung ändert sich nichts. Teilen Sie sich per DS-Lite oder Carrier-Grade-NAT eine IPv4-Adresse mit anderen, geht auch die IPv4-Adresse des Seeds als Endpoint, der Tunnel wird ja von Ihrem Server aus aufgebaut.
Für Ihre Nutzer bleibt alles beim Alten: Die Spieler bekommen die IPv4-Adresse des Seeds, verbinden sich per IPv4, und ihre IPv4-Adressen stehen unverändert in den Logs Ihres Servers. Ein Minecraft-Server ohne eigene IPv4-Adresse ist damit öffentlich erreichbar und geschützt, was ohne den Proxy gar nicht ginge.
Fehlerbehebung
Kein Handshake in wg show:
Öffentliche Schlüssel beider Seiten vergleichen. Prüfen Sie außerdem, ob WireGuard in der DDoS-Protection als Anwendung geschützt ist. Mit der Standardaktion Blockieren kommt der Tunnel sonst nicht durch.
Ping durch den Tunnel geht, Spieler kommen nicht an:nft list ruleset auf dem Seed prüfen. Häufigste Ursache ist ein falscher Schnittstellenname in den Regeln oder ein vergessenes net.ipv4.ip_forward.
Spieler verbinden sich, fliegen aber beim Laden der Welt raus:
Die maxseg-Regel fehlt oder steht nach der accept-Regel. Sie muss davor stehen, damit sie auf neue Verbindungen angewendet wird.
Ihr Server zeigt 10.100.0.1 statt der Spieler-Adresse:
Auf dem Seed ist eine masquerade-Regel aktiv, oder auf Ihrem Server fehlt die Routing-Regel aus den PostUp-Zeilen.
Ihr Server ist nach dem Start des Tunnels nicht mehr erreichbar:Table = off fehlt in der wg0.conf. WireGuard hat dann wegen AllowedIPs = 0.0.0.0/0 den gesamten Traffic in den Tunnel geleitet. Lokal oder über die Konsole Ihres Anbieters wg-quick down wg0 ausführen und die Zeile ergänzen.
Zusammenfassung
Ihr Minecraft-Server ist jetzt nur noch über den Seed erreichbar. Die DDoS-Protection filtert den Traffic, bevor er den Seed erreicht, der Tunnel bringt die sauberen Pakete zu Ihnen nach Hause, und Ihre Spieler kommen mit ihrer echten Adresse an. Ziehen Sie den Server später um, müssen Sie nur den Tunnel anpassen. Für Ihre Spieler bleibt die Adresse gleich.
Welche Anwendungen sich für den Proxy eignen und wie er sich zu anderen Varianten verhält, beschreibt die Lösungsseite zur DDoS-Protection. Läuft Ihr Gameserver direkt auf einem Seed, brauchen Sie keinen Proxy: Die Minecraft-Anleitung zeigt, wie Sie die Anwendung dort direkt schützen.
