https://marius.bloggt-in-braunschweig.de/2025/04/26/teil-2-einen-ganzen-server-rsyncen/
Bei Hetzner seine Server hinstellen, ist echt eine Herausforderung für den Admin, da kommen wir ohne Advanced Routing gar nicht hin.
Teil 3: Advanced Routing
Wir haben einen Hotstand-By Server, der muß 2 IPs haben, damit er genau so funktioniert wie der Originalserver. Wenn man jetzt bei Hetzner einen Server mietet oder hinstellt, dann gibt es eine Hürde man braucht für eine VM min. eine Zusatz IP, in dem Fall 2, und die kommen aus dem gleichen Netzwerksegment, haben aber andere MAC-Adressen, weil Hetzner es nicht erlaubt, zwei (oder alle) IPs auf der gleichen MAC zu haben. Die drohen einem glatt mit Sperren, wenn man sich nicht daran hält. Dazu habe ich noch einen bösen Kommentar am Ende für Euch 😉
„Mehr als ein Interface, aber gleiche Netze? WTF??“
Ja, das geht… ist aber nicht so einfach. Erstmal muß man dazu wissen, wie VMs auf einem Host i.d.R. ans Netz angeschlossen werden: per Bridgeinterface.
Das Bridgeinterface ist eine Art virtueller Switch, bei dem das echte Netzwerkinterface des Hosts mit
dem der VM verbunden wird, so daß da Daten langgehen können. Beispiel:
vmbr0 8000.a8a159c0d0c0 no enp41s0 fwpr104p0 fwpr104p1
Die Brücke heißt „vmbr0“ und das echte Interface ist „enp41s0„. Die zwei Interface der VM sind p0 und p1.
In der VM sieht das dann so aus:
# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:00:da:8b brd ff:ff:ff:ff:ff:ff
altname enp0s18
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:00:98:bd brd ff:ff:ff:ff:ff:ff
altname enp0s19
Die IPs sollen mal „1.1.100.4/26“ und „1.1.100.39/26“ sein, beide fiktiv, sonst kommt noch wer auf dumme Ideen 😉
Was wir jetzt brauchen ist eine priorisierte Route für das zweite Interface, weil sonst der Traffic des zweiten Interfaces ens19 durchs erste Interface ens18 geht, aber wegen der „falschen“ MAC, nicht geroutet oder beachtet wird!
Dazu brauchen wir ip_route2
Wer noch kein Verzeichnis hat, legt es einfach an:
mkdir /etc/iproute2
echo 100 if2 > /etc/iproute2/rt_tables
Dann priorisieren wir alles, was von IP2 kommt, über das Interface 2, damit es nicht durch die Defaultroute über Interface 1 geht:
ip rule add from 1.1.100.39 table if2 prio 1
ip route add 1.1.100.0/26 dev ens19 src 1.1.100.39 prio 1
ip route add default via 1.1.100.1 dev ens19 table if2
Dann können wir eine zweite Defaultroute anlegen, was vorher nicht ging. Das sieht dann so aus:
# ip r
default via 1.1.100.1 dev ens18
1.1.100.0/26 dev ens18 proto kernel scope link src 1.1.100.4
1.1.100.0/26 dev ens19 proto kernel scope link src 1.1.100.39
1.1.100.0/26 dev ens19 scope link src 1.1.100.39 metric 1
169.254.0.0/16 dev ens18 scope link metric 1002
169.254.0.0/16 dev ens19 scope link metric 1003
Damit das permanent so bleibt, was es einfach so nicht möchte, kann man es in ein Script schreiben und das nach dem Start des Netzwerkes aufrufen. Wie Ihr das macht, bleibt Euch überlassen.
Der Kommentar
Hetzner legt nicht ganz zu unrecht Wert auf einen MAC Filter und besteht darauf, daß jede IP eine eigene, von denen vorgegebene MAC hat. Das ist nötig, weil Jeder Jeden im Netz sehen kann, so bekam unsere VM da 3,5Mb/s Broadcasttraffic ab, weil andere Leute keinen Plan von Netzwerken haben und wie man die richtig konfiguriert. Natürlich könnten wir auch Macs als Kunden vorgeben und die akzeptieren die, aber das wäre denen zu viel Aufwand, was Schade ist, weil der Beitrag hier dann überflüssig gewesen wäre 😀
Kann Jeder Jeden sehen, kann man dem seine IPs hochfahren und kapern, deswegen der MAC Filter. Wenn man da aber drauf besteht, anstatt die ganzen Server in VLans zu isolieren, so daß das die sich eben nicht mit Fake ARPs beglücken können, dann muß man das auch überwachen und den Verursacher des Datenmülls stoppen. Das haben die Kollegen bei Hetzner erst gemacht, nachdem ich denen mitgeteilt hatte, daß es wohl ein DDOS Angriff sein könnte ( weil es auch so aussah ) 😀 Jetzt sind wir über Ostern bei 400Kb/s, das klingt schon normaler.