Wir haben in mehrjähriger Arbeit einen eigenen Netzwerk-Stack auf Basis von eBPF geplant und entwickelt, der den Weg für zukünftige Netzwerkfunktionen ebnen wird. Auf dieser Seite möchten wir dir die Features und Unterschiede zum aktuellen Netzwerk-Stack gerne vorstellen und erklären, wie du deine Cloud Server umstellen kannst, um hcnet zu testen. Ebenfalls erklären wir, wie du an der Beta-Phase teilnehmen kannst. Wir sind gespannt auf dein Feedback.
Die Migration der Load Balancer haben wir am 9. Juli 2026 begonnen; seit dem 21. August 2026 laufen alle Load Balancer mit hcnet. Nun ist es an der Zeit, dir die Möglichkeit zu geben, auch deine Server auf den neuen Stack umzustellen.
Ändere den Netzwerk-Stack deines Cloud Servers
Den Abschnitt Bekannte Einschränkungen findest du am Ende der Seite.
Um den Netzwerk-Stack deines Cloud Servers auf hcnet umzustellen, öffne bitte dein Projekt in der Hetzner Console und gehe wie folgt vor:
- Wähle in der linken Menüleiste den Punkt Server aus.
- Wähle den Cloud Server aus, dessen Netzwerk-Stack du umstellen möchtest.
- Wechsle auf den Reiter Networking.
- Wähle unter Netzwerk-Stack die Option „Neuen Netzwerk-Stack ausprobieren“ aus.
Falls du aus irgendeinem Grund zum vorherigen Netzwerk-Stack zurückkehren möchtest, wähle „Standard-Netzwerk-Stack wiederherstellen“. Sollte etwas nicht wie erwartet funktionieren, teile uns dies bitte über das Feedback-Formular mit.
Bitte beachte, dass beide Aktionen die Verbindung zu deinem Server kurzzeitig unterbrechen und bei aktiver Firewall bestehende Verbindungen getrennt werden können.
Im Folgenden werden die Unterschiede zwischen hcnet und dem aktuellen Netzwerk-Stack erklärt.
Cloud Firewalls
Bei den Cloud Firewalls handelt es sich um stateful Firewalls und hcnet implementiert diese mittels eBPF. Wenn eine Cloud Firewall auf einen Cloud Server angewendet wird, wird die Firewall zunächst optimiert und danach in ein eigenständiges eBPF Programm kompiliert. Danach wird es in den Kernel geladen, verifiziert, und JIT kompiliert bevor es anschließend direkt vor die virtuelle Netzwerkkarte deines Cloud Servers geschaltet wird. Dies macht unsere Firewall effizienter als vorher.
Da hcnet eine neue, eigene Firewall-Implementierung mitbringt, die sich von der des aktuellen Netzwerk-Stacks unterscheidet, kann sich das Verhalten beim Connection Tracking ebenfalls im Detail unterscheiden. In der Praxis sollten diese Unterschiede aber kaum bemerkbar sein.
Connection Tracking
Damit die Firewalls stateful sein können, müssen die einzelnen Verbindungen getrackt werden. Das sorgt dafür, dass Pakete die nicht explizit durch Firewall-Regeln erlaubt sind, dennoch durch die Firewall gelassen werden, solange die Pakete eine Antwort auf ein vorher erlaubtes Paket sind, oder solange die Pakete zu einer aktiven Verbindung gehören. Das Limit an gleichzeitig getrackten Verbindungen wurde von 80.000 für IPv4 und IPv6 zusammen, auf 120.000 für IPv4 sowie zusätzlich 120.000 Verbindungen für IPv6 erhöht.
Ein weiterer Unterschied zum aktuellen Netzwerk-Stack ist das verbesserte Verhalten, wenn die Connection Tracking Tabelle voll ist. Aktuell ist es nicht möglich, neue Verbindungen zum Cloud Server herzustellen, da Pakete für neue Verbindungen einfach verworfen werden. Mit hcnet wird in diesem Fall die Connection Tracking Tabelle übersprungen, und das Paket wird ausschließlich auf Basis der Firewall-Regeln evaluiert. Das ist ein angemesseneres Verhalten, welches unerwünschten Traffic weiterhin wie erwartet unterbindet, während Traffic, der auf die Connection Tracking Tabelle nicht angewiesen ist, nun ebenfalls weiterhin funktioniert. Allerdings hat diese Änderung zur Folge, dass Traffic, der auf Connection Tracking angewiesen ist, in diesem Fall eventuell fehlschlägt, da für Antwortpakete nicht in der Tabelle nachgeschaut wird und der Traffic somit je nach Firewall-Regeln verworfen wird.
Wie mit dem aktuellen Netzwerk-Stack auch, ist Connection Tracking für einen Cloud Server nur dann aktiv, wenn dieser eine Firewall vorgeschaltet hat.
Fragment Tracking
Bei der nächsten Änderung geht es um das Tracken von fragmentierten Paketen. Damit ein fragmentiertes IPv4-Paket von der Firewall korrekt gematcht werden kann, muss das erste Fragment als erstes ankommen. Nur dann ist der Layer 4 Header für alle folgenden Fragmente bekannt. Passiert dies nicht, können diese Fragmente nur von Firewall-Regeln evaluiert werden, die keine Layer 4 Informationen benötigen.
Für IPv6 wird kein Fragment Tracking durchgeführt.
DHCP
DHCP-Anfragen werden nun von einer eigenen Implementierung beantwortet, und damit nicht mehr wie bisher von zwei verschiedenen Implementierungen. Des Weiteren ändert sich das Routing zum Metadata Server. Dies ist nicht mehr durch eine Default-Route abgedeckt (sofern sie denn existiert). Stattdessen bekommt mit hcnet jedes öffentliche und private Interface eine explizite Route zum Metadata Server. Je nachdem, welchen DHCP Client du in deinem Cloud Server verwendest, kann es sein, dass nicht alle Routen angezeigt werden.
ICMP
Der neue Netzwerk-Stack bietet ein genaueres Melden von Fehlern mittels ICMP und ICMPv6. Für von deinem Cloud Server ausgehende IPv4- und IPv6-Pakete können die folgenden ICMP/ICMPv6 Antworten auftreten:
| ICMP/ICMPv6 Typ | ICMP Code | ICMPv6 Code | Beschreibung |
|---|---|---|---|
Echo Reply |
Als Antwort auf ein Echo Request. |
||
Destination Unreachable |
Communication Administratively Prohibited |
Source address failed ingress/egress policy |
Wenn versucht wird, von einer gespooften IP Adresse zu senden. |
Reject route to destination |
Wenn versucht wird, eine nicht global routbare IP Adresse zu erreichen. | ||
Host Unreachable |
N/A | Für Private Networks mit einer unbekannten Ziel IP Adresse. | |
Time Exceeded |
Wenn das TTL Feld den Wert 0 erreicht. | ||
Neighbor Advertisement |
N/A | Als Antwort auf ein Neighbor Solicitation. |
IPv6 Multicast
Der neue Netzwerk-Stack unterstützt ein Subset an IPv6-Multicast und antwortet nun auf Echo Requests an folgende well-known IPv6-Multicast-Adressen:
ff02::1: Link-local scope, alle Hosts.ff02::2: Link-local scope, alle Router.
Metadaten-Server
Der Metadaten-Server ist neben der bereits bestehenden IPv4-Adresse
169.254.169.254 nun auch über die IPv6-Adresse fe80:a9fe:a9fe erreichbar.
Zusätzlich sind beide Adressen von jedem öffentlichen und privaten Interface
erreichbar.
Offloads
Der neue Netzwerk-Stack reicht die Pakete nun genauso an den Cloud Server weiter wie er sie empfangen hat. Solltest du die eingehende Paketrate messen, kann es sein, dass du dadurch mehr Pakete siehst, obwohl die Bandbreite gleich bleibt. Stattdessen kann dein Cloud Server, sofern aktiviert, GRO (Generic Receive Offload) durchführen.
Checksum und Segmentation Offloads auf dem Egress Pfad sind weiterhin unterstützt.
Bekannte Einschränkungen
DHCP
Da wir keine Möglichkeit haben, DHCP in deinem Cloud Server zu triggern, und je nachdem, welchen DHCP Client du nutzt, kann es sein, dass nach dem Wechsel zu hcnet die dedizierten Routen zum Metadata Server nicht angezeigt werden.
Ähnliches gilt für den Wechsel zurück zum aktuellen Netzwerk-Stack. Dies kann zu veralteten DHCP-Routen führen. In diesem Fall kann es sein, dass der Metadaten- Server nicht mehr erreichbar ist, sofern die dedizierte Route für das private Netzwerk Interface bestehen bleibt und der Server ein öffentliches Interface besitzt.
Beide Probleme können durch Erneuern der DHCP-Lease oder durch einen Neustart des Cloud Servers behoben werden.