Ich zeige dir, wie du dein hetzner netzwerk sauber planst, korrekt konfigurierst und damit Performance, Sicherheit und Skalierbarkeit gezielt steigerst. Dabei gehe ich praxisnah vor: vom Cloud-Panel über Routing-Varianten bis zu Failover-IPs, virtuellen MACs, IPv6, Sicherheit, Fehlerdiagnose und Monitoring.
Zentrale Punkte
- Adressraum wählen: RFC 1918 sauber nutzen, saubere Subnetze planen.
- Modus bestimmen: Routed, Bridge oder vSwitch je nach Einsatzziel.
- Linux-Setup: ifupdown, netplan, systemd-networkd konsistent halten.
- Failover & MAC: virtuelle MACs korrekt zuweisen, Hostrouten setzen.
- Sicherheit & Monitoring: Segmentierung, Firewalls, Logs und Checks etablieren.
Grundlagen der Hetzner-Netzwerkkonfiguration
Eine saubere Planung verhindert späteren Aufwand und liefert spürbare Performance. Ich trenne interne Systeme in ein eigenes Cloud-Netz, isoliere sensible Komponenten und halte den öffentlichen Angriffsvektor klein, was die Sicherheit deutlich erhöht. Private Netze in der Hetzner Cloud erlauben mir granulare Steuerung, klare Wege für Datenflüsse und weniger Broadcast-Rauschen. Ich definiere früh, welche Server öffentliche Adressen brauchen und welche nur intern sprechen, damit Routing, Firewalls und IP-Zuteilung logisch bleiben. Diese Klarheit zahlt sich aus, sobald Failover, Load Balancer oder Container-Orchestrierung ins Spiel kommen und ich mehrere Subnetze übersichtlich verwalte.
Hetzner Cloud-Panel: Netzwerk anlegen und Adressraum wählen
Im Cloud-Panel erstelle ich ein neues Netzwerk, vergebe einen eindeutigen Namen pro Projekt und wähle einen RFC‑1918‑Adressraum wie 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 als IP-Block. Ich plane Subnetze frühzeitig, etwa /24 für App-Layer, /28 für Verwaltungszugänge oder /26 für Datenbanken, damit Wachstum sauber abgebildet bleibt. Danach binde ich Server, Load Balancer und zusätzliche Dienste ein, damit die Kommunikation sofort steht. Für Einsteiger in die Plattform liefere ich gern den kompakten Cloud-Server Überblick, der die wichtigsten Optionen zusammenfasst. Sobald das Netz bereitsteht, teste ich grundlegende Erreichbarkeit und überprüfe Security-Gruppen, damit keine unnötigen Ports offen bleiben und meine Firewall-Regeln greifen.
Subnetz-Design und IP-Planung im Detail
Ich arbeite mit klaren Namens- und Nummernkonventionen, damit ich Subnetze später intuitiv erkenne. Jede Zone (z. B. app, db, mgmt, edge) erhält einen festen Nummernbereich und eine dokumentierte Standardgröße. Ich reserviere bewusst Pufferbereiche zwischen Subnetzen, um Erweiterungen ohne Umnummerierung zu ermöglichen. Wo Services horizontal skalieren, plane ich lieber mehrere /25 oder /26 statt eines großen /22; so bleiben ACLs und Routen schlank. Für Admin-Zugänge halte ich ein separates Management-/28 vor, das ich durchgängig härte und über VPN oder Bastion-Hosts zugänglich mache. Wenn ich externe Standorte anbinde, definiere ich von Anfang an eindeutige, nicht überlappende Bereiche und setze statische Routen gezielt, damit es keine Konflikte gibt.
Routed, Bridge oder vSwitch: der passende Modus
Ich setze auf drei Hauptvarianten: Routed für zusätzliche Subnetze und Failover-Adressen, Bridge wenn Gäste wie eigene Server auftreten sollen, sowie vSwitch für flexible Setups und NAT. Beim Routed-Modell hängen zusätzliche Adressen an der Haupt-MAC des Hosts; ich aktiviere IP-Forwarding für IPv4 und IPv6 und setze Hostrouten zum Gateway. Bei Bridge benötigen Gäste eine sichtbare MAC im Netz; ich beantrage pro zugeteilter IP eine virtuelle MAC und verknüpfe sie mit dem Gast. vSwitch kombiniere ich mit Masquerading, damit VMs mit privaten Adressen ins Internet kommen, während interne Dienste abgeschirmt bleiben. Diese Auswahl steuert später Aufwand, Transparenz und Fehlertoleranz meiner Plattform.
| Modus | Einsatz | Voraussetzungen | Vorteile | Stolperfallen |
|---|---|---|---|---|
| Routed | Zusätzliche Subnetze, Failover-IPs | IP-Forwarding, Hostroute | Klares Routing, gute Skalierung | Gateway/Hostroute sauber pflegen |
| Bridge | Gäste als „eigene Server“ | Virtuelle MAC je IP | Echte Sichtbarkeit pro Gast | MAC-Verwaltung im Robot nötig |
| vSwitch + NAT | Private VMs mit Internet | Masquerading, Firewall | Hohe Isolation intern | NAT-Regeln sauber pflegen |
Hybrid-Setups: Cloud, Dedicated und Übergänge
In hybriden Umgebungen verbinde ich Cloud-Netze mit Dedicated-Servern über explizite Router-Instanzen. Ein klar definiertes Transit-Subnetz und statische Routen sorgen dafür, dass beide Seiten nur die benötigten Präfixe sehen. Je nach Sicherheitsbedarf lasse ich Traffic per NAT durch eine Edge-Instanz gehen oder route Subnetze transparent. Wichtig ist, dass das Gateway hochverfügbar ausgelegt wird – beispielsweise mit zwei Router-VMs, die gegenseitig den Status prüfen und bei Ausfall nahtlos übernehmen. Ich halte außerdem eine Checkliste bereit: Routen im Cloud-Panel korrekt, Forwarding aktiv, Firewall-States konsistent, und Health-Checks, die nicht nur ICMP, sondern auch relevante Ports prüfen.
Linux-Setup: ifupdown, netplan und systemd-networkd richtig einsetzen
Unter Debian/Ubuntu mit ifupdown lege ich die Konfiguration in /etc/network/interfaces oder unter /etc/network/interfaces.d ab und halte die Hostroute korrekt. Für Host-IP-Adressierung nutze ich /32 (255.255.255.255) und setze das Gateway als pointopoint, damit der Kernel den Nachbarn kennt. Unter netplan (Ubuntu 18.04, 20.04, 22.04) definiere ich addresses, routes und on-link, damit die Default-Route sofort passt. Tausche ich Hardware, prüfe ich die Interface-Bezeichnung und ändere sie von eth0 beispielsweise auf enp7s0, damit die Netzwerkkarte wieder hochkommt. Für systemd-networkd verwalte ich .network- und .netdev-Dateien, lade die Dienste neu und teste anschließend immer DNS, Routing und Connectivity.
Netzwerk-Tuning: MTU, Offloading, Policy-Routing
Ich prüfe die MTU Ende-zu-Ende, besonders wenn VPNs, Overlays oder Tunnel ins Spiel kommen. Stimmen die Werte nicht, kommt es zu Fragmentierung oder Drops. Auf Gateways aktiviere ich TCP-MTU-Probing und setze MSS-Clamps an passenden Stellen, um Verbindungen robust zu halten. Offloading-Features (GRO/LRO/TSO) nutze ich bewusst: Auf Hypervisoren oder bei Paketmitschnitten deaktiviere ich sie teilweise, auf reinen Datenpfaden lasse ich sie an – abhängig von Messwerten. Habe ich mehrere Upstreams oder differenzierte Egress-Policies, setze ich Policy-Based Routing mit eigenen Routing-Tabellen und ip rules ein. Ich dokumentiere jede Sonderregel, damit spätere Änderungen nicht unbemerkt Seiteneffekte auslösen.
Failover-IPs, virtuelle MACs und Load Balancer in der Praxis
Für zusätzliche IPs beantrage ich im Hetzner Robot pro Adresse eine virtuelle MAC und ordne sie dem Gast zu, damit ARP sauber funktioniert. Beim Routed-Setup bleibt die Haupt-MAC auf dem Host und ich route Subnetze explizit zum Gast. In Bridge-Szenarien erhält der Gast seine eigene sichtbare MAC, wodurch er wie ein eigenständiger Server auftritt. Für Failover definiere ich, welche Maschine die IP aktuell announced; beim Wechsel passe ich Routing und ggf. Gratuity-ARP an, damit Traffic sofort ankommt. Mit Load Balancern entkopple ich Frontend-Traffic von Backend-Systemen, sorge für gleichmäßige Verteilung und erhöhe so die Verfügbarkeit.
IP-Umschaltungen sauber gestalten
Ich setze bei aktiven Umschaltungen auf klare Mechanismen: Entweder kündigt die aktive Instanz eine IP über ARP/NDP an und die passive bleibt stumm, oder ich ziehe gezielt die Default-Route auf die neue aktive Maschine. Tools wie VRRP-Implementierungen helfen, aber ich teste immer das gesamte Zusammenspiel inklusive Firewalls, Neighbor-Caches und möglichen ARP-Timeframes. Wichtig: Nach dem Wechsel prüfe ich Erreichbarkeit sowohl aus dem internen Netz als auch von externen Prüfpunkten. Für Services mit vielen TCP-Verbindungen plane ich kurze Grace-Perioden ein, damit offene Sessions sauber auslaufen oder schnell neu aufgebaut werden.
IPv6 einrichten: Dual-Stack sauber umsetzen
Ich aktiviere IPv6 parallel zu IPv4, damit Clients moderne Konnektivität erhalten und Firewalls doppelt greifen. Für jedes Interface setze ich die zugeteilten Präfixe, die Gateway-Route und prüfe Neighbor Discovery sowie SLAAC oder statische Zuweisung. Ich kontrolliere, ob Dienste auf :: und 0.0.0.0 lauschen sollen oder getrennte Bindings sinnvoll sind. Tests mit ping6, tracepath6 und curl über AAAA-Records zeigen mir, ob DNS und Routing stimmen. In Firewalls spiegele ich Regeln für IPv4 nach IPv6, damit keine Lücke offen bleibt und ich denselben Sicherheitsgrad erreiche.
Sicherheit: Segmentierung, Regeln, Härtung
Ich segmentiere Netze nach Funktion wie App, Daten, Management und sichere Übergänge mit klaren ACLs. Jede Abteilung bekommt nur den Zugriff, den sie benötigt, während Admin-Zugänge über VPN oder Bastion-Hosts laufen. Firewalls blocken per Default alles Eingehende, danach erlaube ich gezielt Ports für Dienste. SSH sichere ich mit Schlüsseln, Port-Kontrollen, Rate-Limits und optional Port-Knocking, um Scans zu entwerten. Änderungen teste ich kontrolliert, dokumentiere sie sofort und rolle bei Problemen zügig zurück, damit die Betriebssicherheit hoch bleibt.
Cloud- und Host-Firewalls orchestrieren
Ich kombiniere Cloud-Firewalls mit hostbasierten Regeln. Erstere geben mir eine zentrale Schicht, die verlässlich Basiszugriffe einschränkt, letztere schützen Workloads granular und lassen sich templatisieren. Wichtig ist Konsistenz: Standard-Ports und Management-Zugänge bekommen identische Regeln in allen Zonen. Egress-Policies halte ich restriktiv, damit nur definierte Ziele erreichbar sind. Für sensible Umgebungen setze ich zusätzlich auf Jump-Hosts mit kurzlebigen Zugängen und Multifaktor-Absicherung. Logs korreliere ich zentral, um Blockings schnell zu verstehen und Fehlalarme zu reduzieren.
Troubleshooting: typische Fehler schnell erkennen
Wenn ein Server nach Tausch kein Netz hat, prüfe ich zuerst den Interface-Namen und passe die Konfiguration an. Fällt Routing aus, aktiviere ich IP-Forwarding erneut und kontrolliere Hostrouten sowie das Standard-Gateway. Tippfehler in Adressen, Netmasken oder on-link führen häufig zu Nichterreichbarkeit; ich vergleiche Konfig und tatsächliche Kernel-Routen. Bei Bridge-Problemen kontrolliere ich virtuelle MACs und ARP-Tabellen, damit Zuordnungen stimmen. Logs unter /var/log/syslog, journalctl und dmesg liefern mir Hinweise auf Treiber, DHCP-Fehler oder blockierte Pakete.
Systematische Fehlersuche und Paketdiagnose
- Layer-Check: Link up, Speed/Duplex, VLAN/Bridge-Status, dann IP/Route, dann Dienste.
- Vergleich Ist/Soll: ip addr/route/rule vs. Konfigdateien, Abweichungen schriftlich festhalten.
- Paketmitschnitt: gezielt auf Interface und Host, Offloading beachten, TLS-SNI/ALPN prüfen.
- Gegenprobe: Tests aus mehreren Quellen (intern/extern), um asymmetrische Probleme zu erkennen.
- Rollback-Fähigkeit: Vor jeder Änderung einen definierten Rückweg planen.
Monitoring, Dokumentation und Skalierung gezielt aufsetzen
Ich überwache Latenz, Paketverlust und Jitter mit ICMP-Checks, Port-Checks sowie Flow-Analysen, damit ich Anomalien früh sehe und Trends erkenne. Konfigurationsstände sichere ich versioniert, beschreibe Änderungen stichpunktgenau und halte Playbooks bereit. Für DNS-Records und saubere Namenskonventionen hilft mir der kompakte DNS-Leitfaden, damit Dienste konsistent auflösbar bleiben. Wächst die Plattform, erweitere ich Subnetze, füge weitere Load Balancer hinzu und standardisiere Security-Gruppen. So skaliere ich sicher, halte Ausfälle gering und wahre dabei klare Strukturen.
Automation: Terraform, Ansible und konsistente Rollouts
Ich baue Netzwerke reproduzierbar: Naming, Subnetze, Routen, Firewalls und Server-Zuordnungen werden als Code abgebildet. So erzeuge ich identische Staging- und Produktions-Topologien, teste Änderungen vorab und reduziere Tippfehler. Auf Hostebene generiere ich Konfigurationsdateien aus Vorlagen und injiziere Parameter wie IP, Gateway, Routen und MTU pro Rolle. Cloud-init nutze ich, um direkt bei Server-Provisionierung Netz und SSH-Basics zu setzen. Bei Änderungen gilt: erst in Staging validieren, dann in kleinen Batches produktiv schalten und die Telemetrie aufmerksam beobachten.
Change- und Kapazitätsmanagement
Ich plane Wartungsfenster und definiere Rückfallebenen. Jede Netzänderung erhält einen kleinen Testplan mit Messpunkten vor/nach dem Change. Für Kapazität schaue ich auf Durchsatz pro Zone, Verbindungslasten an Gateways und die Entwicklung von Verbindungen/Minute. Frühzeitig ergänze ich zusätzliche Gateways oder trenne Verkehrswege (Ost/West vs. Nord/Süd), bevor Engpässe entstehen. Dokumentation halte ich lebendig: IP-Pläne, Routing-Skizzen, Firewall-Policies und Zuständigkeiten sind aktuell und für das Team leicht auffindbar.
Anbieter-Vergleich für netzwerkintensive Vorhaben
Ich bewerte Anbieter nach Anbindung, Funktionsumfang, Bedienbarkeit und Flexibilität. Für Projekte mit hohen Netzwerkansprüchen setze ich webhoster.de wegen dedizierter Netze und vielseitiger Anpassung an die Spitze. Hetzner liefert starke Cloud- und Dedicated-Server, die sich für viele Szenarien sehr gut eignen und klar punkten. Strato deckt Standard-Use-Cases ab, während IONOS in einigen Fällen gute Optionen bietet, aber bei Spezial-Setups weniger Spielraum liefert. Diese Einordnung hilft mir, das passende Fundament zu wählen und spätere Engpässe zu vermeiden.
| Platz | Anbieter | Netzwerkfeatures | Leistung |
|---|---|---|---|
| 1 | webhoster.de | Dedizierte Netze, schnelle Anbindung, hohe Anpassbarkeit | Herausragend |
| 2 | Hetzner | Starke Cloud und Dedicated-Server | Sehr gut |
| 3 | Strato | Standardnetzwerkfunktionen | Gut |
| 4 | IONOS | Gehobene Optionen, begrenzter Spielraum für Custom-Setups | Gut |
Kubernetes und Container-Netzwerke in der Praxis
Für Container-Orchestrierung lege ich das Fundament im Netzwerk. Die Worker erhalten Interfaces im privaten Netz, die Control-Plane ist klar segmentiert, und egresslastige Pods bekommen einen definierten NAT-Pfad. Ich wähle eine CNI, die zum Setup passt: Routing-basierte Varianten erleichtern mir die Fehlersuche und sparen Overlay-Overhead, Overlays bringen dafür oft mehr Flexibilität bei Isolierung. Load Balancer entkoppeln Ingress von Backends; Health-Checks sind identisch zu denen der App, nicht nur einfache TCP-Checks. Dual-Stack betreibe ich auch im Cluster, damit Dienste sauber via AAAA-Records erreichbar sind. Für Stateful-Services definiere ich klare Netzwerk-Policies (Ost/West), damit nur die erforderlichen Ports zwischen Pods offen sind. Ich teste Updates von CNI und Kube-Komponenten immer in einem Staging-Cluster, inklusive Durchsatz, Latenz und Failure-Szenarien.
Performance unter Last: Messbar optimieren
Ich messe regelmäßig: Basis-Latenz innerhalb der Zonen, Latenz zu öffentlichen Endpunkten, Port-zu-Port-Durchsatz, und RTO/RPO-Anforderungen für kritische Dienste. Engstellen entstehen häufig an wenigen Punkten: NAT-Gateways, überlastete Stateful-Firewalls, zu kleine Connection-Tracking-Tabellen, oder schlicht zu wenig CPU auf Routern. Ich erhöhe systematisch Kapazität, verteile Flows, aktiviere Multi-Queue auf NICs und achte auf Pinning/IRQ-Balancing, wo sinnvoll. Kritisch ist, unnötige Stateful-Inspektion auf reinen Ost/West-Backbones zu vermeiden und dort stattdessen klare ACLs zu setzen. Für TLS-Offloading trenne ich Daten- von Steuerverkehr, damit L7-Workloads nicht mit Verwaltungsverbindungen konkurrieren. All dies dokumentiere ich mit Ausgangs- und Zielwerten – Optimierungen sind erst dann „fertig“, wenn sie messbar Nutzen bringen.
Kurzbilanz: So setze ich Hetzner-Netzwerke effektiv auf
Ich starte mit einem klaren Plan, definiere Adressräume, wähle den passenden Modus und dokumentiere jeden Schritt. Danach richte ich Linux-Netzwerke konsistent ein, aktiviere IP-Forwarding bei Bedarf und teste Routing sowie DNS gründlich. Failover-IPs und virtuelle MACs binde ich strukturiert ein, damit Umschaltungen sauber klappen. Sicherheit bleibt durch Segmentierung, starke Firewalls und konsequentes Patchen hoch, während Monitoring frühzeitig Unregelmäßigkeiten zeigt. So hole ich aus dem hetzner Netzwerksetup verlässlich Leistung heraus und halte die Plattform zugleich flexibel für Wachstum.
