Die Hetzner Online GmbH ist ein Cloud-Anbieter mit Sitz in Deutschland.
Liste der Standorte und peering
geplant: 10,5ha; ~105000 m² Nähe Frankfurt Main 1)
Speedtests
ICMP-Ziele:
Rootserver („Robot“): Aus der FAQ: „Durch das Anlegen eines separaten Adminzugangs, erhalten Sie neue Robot-Zugangsdaten, die nur für den aktuell ausgewählten Server gelten.
Dieser Account verfügt nur über die Menüpunkte „Server“ und „Traffic-Statistik“ und kann nur den einen Server einsehen für den er angelegt wurde. Supportanfragen, Bestellungen und Kündigungen sind über einen Adminzugang nicht möglich.
Sie können die Zugangsdaten für den Adminzugang z.B. Ihrem Administrator zur Verfügung stellen, damit dieser über Zugriff auf Funktionen wie den Reset-Auftrag oder die Rescue-Aktivierung für den Server verfügt.“
vserver („cloud“): für jedes Projekt können per Einladung extra Benutzer hinzugefügt werden.
2FA kann bei Accounts und OTP kann beim tel. Support benutzt werden.
Vorteile: /24 Netzwerk nach IPv4 Waiting List https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list) - 2000€ einmalig - 1400€ pro Jahr (~117€ mtl.) - BGP?
Co-Location FAQ mit Rack-Beschreibungen/Abmessungen
Rack Basic (200€, 42HE, 10TB Traffic ausgehend, für ca. 65cm tiefe Server ausreichend)
10G Colocation Uplink (nicht redundant):
Optionen mit Redundanz und eigener BGP-Session kosten mehr.
ASN mit eigenen IP-Adressen (PI von RIPE) announcen: Announcement foreign IP address space (PI subnet) für Colo-Racks Nürnberg/Falkenstein 99,00 €
Private Interconnects (29€ netto) : LWL-Vorverkabelung (499 € netto) 1HE Panel in das Rack mit 6x LC-Duplex Verbindungen (Singlemode), Ziel: Patchschrank (meet-me-room). Die einmaligen Kosten für den Private Interconnect sind abhängig von der Trassenführung.
Standardmäßig kann im Layer2 das ganze Präfix benutzt werden, auch mit Subnets.
Sollte aber eine Art Firmennetz hochgezogen werden (interne Netze und firewalling wie in https://blog.matrixpost.net/set-up-your-internal-lan-and-perimeter-network-with-public-ipv6-addresses-and-pfsense/ beschrieben) dann ist die folgende Herangehensweise am besten:
Hetzner teilt auf Anfrage ein /64 Transfernetz zu, hier kann die statische (Cluster) WAN-IP der Firewall konfiguriert werden und Hetzner routet dann das zugeteilte /56 auf diese IP. Der Rest ist dann intern Sache der Firewall.
Im Prinzip ähnlich wie bei v6, über ein Transfernetz werden v4-Netze über die Firewalls geroutet.
https://blog.matrixpost.net/set-up-a-perimeter-network-with-public-ipv4-addresses-and-pfsense/
DNS mit API, ansible module Teil der Community.Dns-Collection.
Einschränkungen:
| Beispieladresse | steht für … |
|---|---|
| 1.2.3.4 | Cluster-IP |
| 5.6.7.8 | rootserver |
| 9.10.11.12 | „alte“ Hauptadresse |
Rootserver-VM
auto ens3 iface ens3 inet static address 1.2.3.4 netmask 255.255.255.255 gateway 5.6.7.8 # rootserver (traceroute $IP)
vserver:
auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.255 # broadcast 1.2.3.4 gateway 172.31.1.1 dns-nameservers 8.8.4.4 9.9.9.9 # "old" main-IP: up ip addr add 9.10.11.12/32 dev eth0 down ip addr del 9.10.11.12/32 dev eth0
bridge_hw eno1 ist ab Debian 11 notwendig, da sonst die bridge eine anderen MAC als die darunterliegende Hardware (hier eno1) bekommt und damit die Portsecurity von hetzner den Traffic nicht erlaubt. Auf ARP-Ebene geht es noch (arping $GW) aber nichts oberhalb Layer2.
iface eno1 inet manual auto br_inet iface br_inet inet static address $IP/$NETMASK gateway $GW bridge_hw eno1 bridge_ports eno1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off iface br_inet inet6 static address $IP netmask 64 gateway fe80::1 bridge_hw eno1 bridge_ports eno1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off
ansible: