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.

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.

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

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)