Alle Artikel

Wenn Ihr Server angegriffen wird, ist "wir werden geDDoSt" nicht umsetzbar; "SYN-Flood, vier Millionen Pakete pro Sekunde, gespoofte Quellen, Ziel Port 443" schon. Der Unterschied zwischen beidem ist ein dreißigsekündiger Mitschnitt und ein strukturierter Blick darauf. Diese Anleitung behandelt sicheres Mitschneiden auf einer bereits ausgelasteten Maschine (tcpdump, nicht die Wireshark-GUI), den Triage-Workflow in Wireshark (Protocol Hierarchy, Conversations, I/O Graphs) sowie die Display-Filter-Signaturen der gängigen Angriffsvektoren, und schließt damit, wie Sie Erkenntnisse in Mitigation umsetzen.

DDoS-Angriffe lassen sich in drei große Familien einteilen: volumetrische Floods, die Ihre Anbindung sättigen, Protokollangriffe, die den Verbindungsstatus erschöpfen, und Angriffe auf Anwendungsebene, die wie legitimer Traffic aussehen. Jede Form erschöpft eine andere Ressource, jede braucht daher eine andere Verteidigung, und keine einzelne Schicht stoppt alle drei. Dieser Leitfaden ordnet die gängigen Angriffsformen der Ressource zu, die sie angreifen, sowie der Mitigation, die tatsächlich dagegen wirkt, erklärt, was eine Firewall auf dem Server stoppen kann und was nicht, und endet mit einem praktischen Incident-Response-Runbook für den Ernstfall.

Der Ping ist nur ein Teil dessen, was ein Spieler spürt. Ein einziger Round Trip läuft durch Input-Sampling, die letzte Meile, Transit und Peering, eine Warteschlange auf dem Server und das Warten auf den nächsten Simulationstick, bevor die Welt überhaupt reagiert. Dieser Leitfaden zeigt, woher gefühlte Verzögerung kommt, wie Tickrate und Netcode das Bild verändern, warum Jitter und Paketverlust mehr schaden als ein stabiler höherer Ping, und welchen Hebel ein Host am stärksten in der Hand hat: den Server nahe an die Spieler zu stellen, auf Hardware, die ihre Tickrate hält.

Netplan ist die YAML-Schicht, die die Netzwerkkonfiguration auf Ubuntu Server übernimmt: Sie beschreiben Adressen, Routen und DNS in einer Datei, und ein Generator wandelt das in Konfiguration für systemd-networkd um. Dieser Crashkurs ist für einen Dedicated Server mit statischer öffentlicher IP, ohne WLAN und mit SSH als einzigem Zugang geschrieben. Er behandelt, wo die Dateien liegen, die Root-only-600-Berechtigungsregel, ein vollständiges Beispiel für statisches IPv4 und IPv6, die Befehle generate, try und apply, die verhindern, dass Sie sich selbst aussperren, dazu VLANs, Bonds, Bridges, und die cloud-init-Datei, die ständig aufs Neue die Änderungen der Nutzer überschreibt.

NetworkManager ist der Daemon, der auf jedem Server der RHEL-Familie das Netzwerk konfiguriert, und seit RHEL die alten network-scripts abgeschafft hat, ist es der einzige unterstützte Weg dafür. Dieser Crash Course behandelt es so, wie ein Dedicated Server es nutzt: headless, statisch, über SSH, mit nmcli und Keyfiles statt einem Desktop-Applet. Sie lernen das Device-und-Profil-Modell, das die meiste nmcli-Verwirrung auflöst, eine vollständige statische IPv4- und IPv6-Konfiguration zum Einfügen und Anpassen, wo Profile auf RHEL 8, 9 und 10 auf der Festplatte liegen, und wie Sie das Netzwerk auf einer entfernten Maschine ändern, ohne sich selbst auszusperren.

Eine virtualisierte OPNsense-Firewall auf Ihrem Proxmox-Host bringt Ihnen, wofür Appliance-Hersteller vierstellige Beträge verlangen: eine vollwertige Firewall/Router, die Ihre VMs schützt, mit Snapshots vor jedem Upgrade und ohne zusätzliche Hardware. Der Haken: Die Details der Einrichtung (Bridges, VirtIO, Offloading) entscheiden, ob sie felsenfest läuft oder rätselhaft instabil ist. Dieser Leitfaden behandelt die Netzwerkdesigns, die auf einem Dedicated Server funktionieren, die genaue VM-Konfiguration, auf die sich die Community geeinigt hat, die Installation sowie die ehrlichen Einschränkungen bei Performance und beim Schutz des Proxmox-Hosts selbst.

Beim Netzwerk scheitern die meisten neuen Proxmox-Installationen: Die Installation klappt, die erste VM startet, und dann wird aus "wie gebe ich ihr eine IP?" ein Nachmittag mit halb passenden Forenbeiträgen. Das zugrunde liegende Modell ist eigentlich klein: VMs docken an Linux-Bridges an, und alles andere sind Variationen davon. Dieser Leitfaden baut dieses Modell sauber auf: was vmbr0 wirklich ist, Bridged- versus Routed- versus NAT-Setups bei einem Hosting-Provider, VLAN-aware Bridges, richtig konfiguriertes Bonding, wo die SDN-Schicht ansetzt, und wie Sie all das ändern, ohne sich selbst auszusperren.