Zum Inhalt springen

IPv4 mit Einzeladressen und IPv6 bei Hetzner

Es gibt mehrere Wege Ipv6 bei Hetzner einzurichten und je nach Weg erhält man verschiedene Möglichkeiten.
Im folgenden beschreibe ich die Einrichtung von einzelnen IPv4-Adresse und des IPv6 Subnetzes, welches mit jedem Server daherkommt.
Jede virtuelle Maschine erhält genau eine IPv4 und eine IPv6 Adresse. Es ist jedoch auch möglich das /64 Subnetz, welches man von Hetzner erhält, in weitere kleinere Blöcke zu unterteilen und diese Blöcke je einer Maschine zuzuweisen. Ebenso ist es möglich einer Maschine einfach mehrere IP-Adresse zuzuweisen.

Voraussetzungen

In der folgenden Konfiguration setze ich KVM auf Debian 10 (Buster) ein. Das System ist über eine Netzwerkkarte ans Netzwerk angebunden und erhält dort direkt eine öffentliche IP-Adresse. Die Netzwerkkarte ist Teil einer Bridge (vmbr0).
Die IP-Adresse des Hauptsystems ist: 5.9.136.34 (ipv4), 2a01:4f8:190:101d::2 (ipv6)
IPv6: 2a01:4f8:190:101d:: / 64

Achtung (Bullseye): ab Debian Bullseye ist die Angabe der MAC-Adresse notwendig, da Debian nicht mehr die MAC der ersten Netzwerkkarte übernimmt und das GW von Hetzner nach MAC-Adresse filtern. Die zufällig für die Bridge erzeugte MAC-Adresse kann dem GW natürlich nicht bekannt sein. Pakete von ihr werden demnach verworfen. Vielen Dank für den Hinweis von Christian in den Kommentaren). Ein zweiter Lösungsweg ist von ihm in den Kommentaren verlinkt.
Den technischen Hintergrund dazu gibt es hier.

/etc/network/interfaces trägt folgenden Inhalt

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp4s0
iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
  hwaddress aa:bb:cc:dd
  #hier ist bei Debian Bullseye die Angabe der Mac erforderlich! (s. Kommentare)
  address 5.9.136.34
  netmask 255.255.255.224
  gateway 5.9.136.33
  # route 5.9.136.32/27 via 5.9.136.33
  up route add -net 5.9.136.32 netmask 255.255.255.224 gw 5.9.136.33 dev enp4s0
  bridge_ports enp4s0
  bridge_waitport 0

iface vmbr0 inet6 static
  address 2a01:4f8:190:101d::2
  netmask 64
  gateway fe80::1

ufw ist aktiviert mit folgenden Regeln:

root@sb35 / # /sbin/ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
443/tcp                    ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                                 
22/tcp (v6)                ALLOW       Anywhere (v6)             
443/tcp (v6)               ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             

Anmerkungen

Subnetz /56

Es gibt die Möglichkeit bei Hetzner zusätzlich zum /64 Subnetz ein /56 zu bestellen. Dies kostet einmalig je Server ca. 50€. Jedoch kann dies Subnetz bei Wechsel des Servers, so mein Erlebnis vor einigen Monaten, nicht auf die neue Maschine übernommen werden. Es fallen dann erneut ca. 50€ an, aktuell (11.2021) liegt der Preis bei 15€ für ein /56 Subnetz. Vielen Dank für Hinweis.
Warum beides, auch die Zuweisung eines /48 Blockes, nicht unbedingt Adressenverschwendung sein muss, kann man hier in englisch nachlesen.

Subnetz IpV4?

Dazu gibt es hier eine Dokumentation von mir. Privat setze ich auf einzelne Ip-Adresse. Hier scheint mir derzeit für meine Zwecke das Preis/Leistungsverhältnis besser und es gibt weniger „Adressverschnitt“.

echte Adresse(n) in der Doku?

In dieser Dokumentation verwende ich die echten produktiven Adressen meines privaten Servers. Warum auch nicht? Sie stehen im DNS-Record und sind damit ohnehin weltweit einsehbar, überdies habe ich beim letzten Mal beim Übertragen auf erdachte Adressen ein Fehler gemacht. So weiß ich, dass diese Konfiguration läuft und eliminiere eine mögliche, unnötige, Fehlerquelle.

Einrichtung des Hauptsystems (Host)

In der Datei /etc/sysctl.conf setze folgende Zeilen um das IP-forwarding für IPv4 und IPv6 zu aktivieren.

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Weitere Änderungen auf dem Hauptsystem führe ich nicht durch.

Konfiguration IPv4 je zusäzliche IP-Adresse im Robot

Zuerst lege ich zu jeder Ip-Adresse eine Mac-Adresse an. Dazu gehe ich in den Hetzner-Robot auf „Server“ und wähle die entsprechende Ip-Adresse aus. Der Vorteil ist, dass ich mir so die IPv4 Konfiguration einfach via DHCP holen kann.

Hetzner Robot Ansicht Ip-Adresse

Dazu klicke auf das kleine Symbol direkt hinter der Ip-Adresse, und im folgenden Bildschirm auf „neu anlegen“.
Hier kann ich auch die Mac-Adresse auslesen, falls schon eine vergeben war.

Mac-Adresse virtuelle Maschine

Damit ist die Konfiguration im Robot fast abgeschlossen. Was noch fehlt sind die Reverse-DNS-Einträge für die jeweiligen IPv6-Adressen.

Reverse-DNS-Eintrag Ipv6
Reverse-DNS-Eintrag Ipv6

Konfiguration je IP-Adresse je virtuelle Maschine

In die jeweilige Konfigurationsdatei trage ich nun die Netzwerkkarte an, welche mit der Bridge verbunden ist. Wichtig
ist hier die Mac-Adresse aus dem Robot einzutragen

<interface type="bridge">
  <mac address="00:50:56:00:3a:cd"/>
  <source bridge="vmbr0"/>
  <target dev="vnet3"/>
  <model type="virtio"/>
  <alias name="net0"/>
  <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
</interface>

Konfiguration innerhalb der virtuellen Maschine

In der virtuellen Maschine richte ich nun nur noch das Netzwerk ein. Dazu setze ich folgende Einträge in /etc/network/interfaces

allow-hotplug enp1s0
iface enp1s0 inet dhcp

iface enp1s0 inet6 static
address 2a01:4f8:190:101d::3
subnet 64
gateway fe80::1

und starte die Maschine neu. Danach teste ich die Erreichbarkeit von außen mittels eines einfachen Dienstes, z.B. via ssh.
Ab hier geht es „normal“ weiter, d.h. Absichern des Systems, Einrichten der Dienste, et cetera.

Aktuelles Problem und Workaround

Nach einiges Updates und einem Neustart für die Dokumentation (heute) war mit einmal keine Maschine mehr via IPv6 erreichbar.
Folgendes Skript löst das Problem:

# ! /bin/bash
#

ip addr add 2a01:4f8:190:101d::2/64 dev vmbr0
ip route add default via fe80::1 dev vmbr0

Warum es das tut ist eine interessante Frage, der ich mich beim nächsten Update widmen werde.
Aktuell brauche ich die Systeme für die produktive Arbeit und habe wenig Zeit für eine genauere Fehlersuche mit mehreren Neustarts.

Update auf Bullseye

Nach einem Update auf Debian Bullseye leitet die Bridge derzeit keine Packete mehr weiter. Ich schaue mir das Problem, da es für mich nicht drängend ist, in nächster Zeit auf einem Testsystem an.
Sicherheitsupdate für Debian 10 Buster gibt es immerhin noch bis ca. 8.2022 (Quelle:https://wiki.debian.org/DebianReleases)

7 Gedanken zu „IPv4 mit Einzeladressen und IPv6 bei Hetzner“

  1. Manchmal steht man wirklich auf dem Schlauch:

    up route add -net IPV6/64 gw fe80::1 dev vmbr0

    an das Ende des Abschnittes
    iface vmbr0 inet6 static
    address 2a01:4f8:190:101d::2
    netmask 64
    gateway fe80::1

    hilft weiter. Ich aktualisiere den Post, bzw. schreibe ihn komplett neu.

    1. Ich habe es mit Proxmox nie getest, aber da es ein Debian als Basis hatte sollte das prinzipiell möglich sein.
      Ich selbst habe Proxmox nur ein einziges Mal eingesetzt und hatte damit eher durchwachsene Erfahrungen und lasse es sei dem links liegen.

      Ich denke aber es wäre über die nächsten Feiertage mal einen Versuch wert 🙂

  2. Bezgl Update auf Bullseye: systemd ändert ab bullseye die MAC der bridge in einen Zufallswert und nicht mehr in die eines der bridged interfaces. Das gibt dann vermutlich entweder Stress mit bei Hetzner hoch eingestellten ARP-Cache TTLs (warum auch nicht, üblicherweise ändern sich da keine MAC-Adressen) oder deren Gateway filtert auf die MAC. Beides ist möglich, wobei sich das Problem in ersterem Fall nach Ablauf der TTL von selbst lösen dürfte. Verursacher ist eine ziemlich arrogante Änderung in systemd, die beim Upgrade auf bullseye so einige bridges dysfunktional hinterlassen dürfte.

    Lösung (ist nicht von mir, sondern stammt von hier: https://github.com/FreifunkHochstift/ffho-salt-public/commit/1c6d5423bd63a421f0a4636c8806ed213e6eac91 ):

    in /etc/systemd/network eine Datei ’90-unfuck-mac-overwrite.link‘ mit dem nachfolgenden Inhalt anlegen, danach einmal systemctl-daemon-reload, danach läuft’s wieder…

    #
    # Overwrite MACAddressPolicy=persistent which is set in defautl config file
    # /lib/systemd/network/99-default.link so systemd-udevd will NOT fiddle
    # around with interfaces it has no businss in touching at all.
    #

    [Match]
    OriginalName=*

    [Link]
    MACAddressPolicy=none

    1. Vielen Dank Dir für Deine Mühe, das ist wirklich gut und hilfreich und erklärt alle Phänomene.
      Das Hetzner GW filtert nach MAC-Adressen, trifft das Zusammen damit, dass die Bridge nicht mehr automatisch die MAC des ersten (und in meiner config einzigen) physikalischen Gerätes erhält, tritt der Fehler auf.
      Das erklärt auch warum es als workaround half bei der Bridge den Parameter
      hwaddress gefolgt von der Mac der Netzwerkkarte zu ergänzen.
      Das lief aber nur auf 3 von 4 Systemen. 2 davon waren Testsysteme, eins ein produktives. Auf dem zweiten produktiven System läuft es nicht, da werde ich nun noch einmal ein Testsystem heranziehen und den Fehler versuchen zu rekonstruieren.
      Hier also nochmal die Erklärung (englisch):

      With the systemd version in Debian Bullseye systemd-udevd will by default
      change MAC addresses of interfaces with a random MAC (bridges, veth, tun/tap,
      etc.) to a persistent MAC based on the machine-id as well as the interface
      name. As a consequence bridges will not get the MAC address of the first
      interfaces added anymore. This commit restores the old behaviour to ensure
      nothing will break unexpectedly down the line.

      See systemd/systemd#21185 for more context.

      (Quelle: https://github.com/FreifunkHochstift/ffho-salt-public/commit/1c6d5423bd63a421f0a4636c8806ed213e6eac91 )

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert