Architektur

Innerhalb von Hetzner Netzwerken routen

Dieser Abschnitt geht davon aus, dass sie den Unterschied zwischen Switches und Routern kennen und mit den Schichten im OSI-Modell vertraut sind.

Innerhalb des Hetzner Netzwerks erfolgt die Kommunikation über zwei verschiedene Schichten, abhängig vom Subnetztyp:

• vSwitch-Subnetz über Schicht 2 (Ethernet / Data Link Layer):

  On-link (direkte) Kommunikation

  Quelle
  Dedicated Server

  →

  Ziel
  Dedicated Server
  
  

  Beide Dedicated Server sind über eine Switch direkt miteinander verbunden. Dadurch kann die Quelle über ARP die MAC-Adresse des Ziels ermitteln und das Paket direkt, ohne zusätzliche Hops, an das Ziel senden.

• Cloud-Subnetz über Schicht 3 (IP / Network Layer):

  Off-link (geroutete) Kommunikation

  
  

  Nur Cloud Server:

  Quelle
  Cloud Server

  →

  Cloud
  Gateway

  →

  Ziel
  Cloud Server
  
  

  Cloud Server und Dedicated Server:

  Quelle / Ziel
  Dedicated Server

  ↔

  vSwitch
  Gateway

  ↔

  Cloud
  Gateway

  ↔

  Ziel / Quelle
  Cloud Server
  
  

  Die Server sind nicht direkt miteinander verbunden. Die Quelle muss über ARP die MAC-Adresse des Gateways ermitteln und das Paket an das Gateway senden. Das Gateway leitet das Paket an das Ziel, bzw. den nächsten Hop in Richtung des Ziels, weiter.

Beispiel-Visualisierung

10.0.0.0/16
10.0.0.0/24
10.0.1.0/24
↕
⚯
Netzwerk
Subnetz
Subnetz von Typ vSwitch
direkt verbunden
direkt verbunden über switch

Beispiel-Routen

Folgend wird gezeigt, welche Routen benötigt werden, um die privaten IPs in der obenstehenden Visualisierung zu erreichen.

Auf dem Cloud Server:

Auf dem Dedicated Server A:

Durch mehrere Netzwerke routen

Wenn ein Paket zwischen dem Internet und dem Client geroutet wird, läuft dieses durch zwei Netzwerke — das private Netzwerk und das öffentliche Netzwerk.

Wie in dem FAQ über technische Details erklärt, besitzen Hetzner Cloud Server unterschiedliche MTU-Einstellungen für private und öffentliche Netzwerkschnittstellen.

Im oberen Beispiel sollte ein eingehendes Paket mit einer MTU von 1500 Bytes den Cloud Server router problemlos erreichen. Wenn der router allerdings keine IP-Fragmentierung durchführen kann, kann das Paket nicht über das private Interface weitergeleitet werden und wird stattdessen verworfen.

Mit ip link show können Sie sich die MTUs aller Schnittstellen auf dem System anzeigen lassen.

Aus einer Umgebung mit isoliertem Netzwerk routen

Wenn auf Ihrem System eine Umgebung mit isoliertem Netzwerk läuft (z.B. Docker Container oder LXC), besitzt diese normalerweise seine eigenen Schnittstelleneinstellungen.

Im folgenden Beispiel können zwischen der Umgebung mit isoliertem Netzwerk und dem darunterliegenden Host Pakete mit einer MTU von 1500 Bytes übermittelt werden:

Wenn die Umgebung mit isoliertem Netzwerk den darunterliegenden Host als Router verwendet, wird der Host aus dem oberen Beispiel das Paket über das private Interface mit einer MTU von 1450 Bytes weiterleiten.

Wenn die Umgebung mit isoliertem Netzwerk ein Paket mit einer MTU von 1500 Bytes übermittelt, sollte es den darunterliegenden Host problemlos erreichen. Wenn der Host allerdings keine IP-Fragmentierung durchführen kann, kann das Paket nicht über das private Interface weitergeleitet werden und wird stattdessen verworfen.

Konfiguration von Multi-Netzwerk-Routen

Wenn die Routen richtig eingerichtet wurden, sollte das Setup in etwa so aussehen:

Bevor man in einem NAT/Client-Setup die Routen wie in der obenstehenden Visualisierung einrichtet, ist es wichtig zu verstehen, wie Pakete durch das Netzwerk geroutet werden sollen.

Beispiel:

Ein privater Client mit der privaten IP 10.0.0.3 sendet eine Anfrage an die öffentliche IP 203.0.13.1.

Auf Cloud-Seite wurde konfiguriert, dass Traffic über den NAT-Server (private IP 10.0.0.2, öffentliche IP 198.51.9.1) geroutet wird. Client-Server sind über das Gateway des privaten Netzwerks mit dem NAT-Server verbunden.

Anfrage an öffentliches Ziel:

• Der Client-Server muss eine Route besitzen, die Pakete an IP-Adressen außerhalb des eigenen Netzwerks (z.B. öffentliche IPs wie 203.0.13.1 oder private IPs wie 192.168.0.3) an das Gateway des privaten Netzwerks sendet, in diesem Beispiel 10.0.0.1.

  # Default-Route für öffentliche IPs
  ip route add default via 10.0.0.1
  
  # Statische Route für Traffic zu privaten Netzwerken außerhalb des Servers eigenen Subnetzes
  ip route add 192.168.0.0/16 via 10.0.0.1

• Das private Netzwerk muss eine Route besitzen, die Pakete an IP-Adressen außerhalb des eigenen Netzwerks (z.B. öffentliche IPs wie 203.0.13.1 oder private IPs wie 192.168.0.3) an die private IP des NAT-Servers sendet, in diesem Beispiel 10.0.0.2. Sie können dafür Hetzner Console oder die Hetzner API verwenden.

  Default-Route für öffentliche IPs

  • Ziel: 0.0.0.0/0
  • Gateway: private IP des NAT-Servers

  Route für Traffic zu privaten Netzwerken außerhalb des eigenen Subnetzes

  • Ziel: 192.168.0.0/16
  • Gateway: private IP des NAT-Servers

Zusätzlich muss der NAT-Server noch so konfiguriert werden, dass Traffic korrekt weitergeleitet wird.

Antwort an privaten Client:

Hierfür müssen keine zusätzlichen Routen eingerichtet werden. Für die Antwort benötigt der NAT-Server nur eine Route, die Pakete mit privater Ziel-IP, wie 10.0.0.3 über das Gateway des privaten Netzwerks 10.0.0.1 leitet. Diese Route wird auf Servern innerhalb eines privaten Netzwerks automatisch eingerichtet.