Cloud-Networking

01

Dein eigenes Netzwerk in der Cloud: virtuelle Netzwerke und IP-Adressbereiche

In einem Cloud-Rechenzentrum laufen die Server unzähliger Kunden nebeneinander. Trotzdem sollen deine Server nur miteinander reden und von allen anderen getrennt bleiben. Deshalb gibt die Cloud jedem Kunden ein logisch isoliertes Netzwerk, ein virtuelles Netzwerk. Kabel und Switches teilen sich alle, aber Adressen, Routen und Regeln gehören nur dir.

Als Erstes legst du beim Anlegen eines virtuellen Netzwerks fest, welche IP-Adressen es nutzen soll (seinen Adressbereich). Meist wählst du ihn aus den privaten Adressbereichen, die dafür reserviert sind, dass sie im öffentlichen Internet nie vorkommen. Jede Firma und jeder Haushalt darf diese privaten Adressen wiederverwenden – genau deshalb kommen sie nicht von selbst ins Internet (wie sie hinauskommen, zeigt Kapitel 3).

CIDR: die Zahl nach dem Schrägstrich lesen

Eine IPv4-Adresse ist 32 Bit lang. 10.0.0.0/16 bedeutet: „Die ersten 16 Bit (10.0) sind fest, die restlichen 16 Bit darf dieses Netzwerk nutzen.“ Das ergibt 2^16 = 65.536 Adressen. Je größer die Zahl nach dem /, desto mehr Bits sind fest und desto kleiner ist der Bereich. Diese Schreibweise heißt CIDR, und der Bereich, den sie beschreibt, ist ein CIDR-Block. Ändere in der Szene unten die Subnetzgröße.

Den Bereich des virtuellen Netzwerks teilst du dann in Subnetze auf. Ein Subnetz ist ein Abschnitt, in dem du Server mit derselben Rolle zusammenfasst – etwa eine Webschicht, die zum Internet zeigt, und eine Datenbankschicht, die du versteckst. Jedes Subnetz kann eigene Routen (Kapitel 2) und Firewallregeln (Kapitel 4) bekommen.

Nicht jede Adresse im Subnetz gehört dir

In jedem Subnetz hält die Cloud ein paar Adressen für sich zurück: die erste Adresse (die Netzwerkadresse), das Gateway, über das es aus dem Subnetz hinausgeht, DNS und so weiter. Wie viele, hängt vom Cloud-Anbieter ab. Selbst ein /24-Subnetz bietet deinen Servern also etwas weniger als 256 Adressen.

Von Anfang an großzügig planen – und ohne Überschneidungen

Adressbereiche lassen sich nach dem Anlegen nur schwer ändern. Plan mit ein, dass Server und Dienste mehr werden, wähl einen großzügigen Bereich und achte darauf, dass er sich nicht mit deinem Firmennetz oder deinen anderen virtuellen Netzwerken überschneidet. Hier stolpern viele: Nutzt dein Büronetz 192.168.0.0/16 und dein Cloud-Netzwerk denselben Bereich, kann später beim Verbinden niemand sagen, welche 192.168.1.10 gemeint ist – die Verbindung funktioniert dann schlicht nicht (Kapitel 7).

Du hast deinen Bereich in Subnetze geteilt. Aber woher weiß ein Paket, das ein Server im Subnetz losschickt, wohin es gehen soll?

02

Subnetze und Routing: was ein Subnetz öffentlich oder privat macht

Schickt ein Server ein Paket los, entscheidet die Routingtabelle, die seinem Subnetz zugeordnet ist, wohin es geht. Eine Routingtabelle ist eine Liste von Zeilen nach dem Muster „Pakete für diesen Bereich gehen durch jene Tür hinaus“. Jedes virtuelle Netzwerk hat von Anfang an eine eingebaute lokale Route, die sagt: „Adressen im Netzwerk werden im Netzwerk zugestellt.“ Deshalb reden Subnetze ohne weitere Einrichtung miteinander.

Ziel             Nächster Hop (wohin damit)
10.0.0.0/16      Im Netzwerk (lokal)
172.16.0.0/12    VPN-Verbindung → Firmennetz
0.0.0.0/0        Internet-Gateway

Die Routingtabelle sucht die Zeile, zu der die Zieladresse des Pakets passt, und schickt es an den nächsten Hop dieser Zeile. Angenommen, ein Webserver schickt ein Paket an einen Datenbankserver im selben Netzwerk (10.0.2.15). 10.0.2.15 liegt in 10.0.0.0/16, passt also zur ersten Zeile. 0.0.0.0/0 bedeutet aber „jede Adresse“ – also passt auch die letzte Zeile.

Passen mehrere Zeilen, gewinnt die spezifischste – die mit der größeren Zahl nach dem /. Das nennt man Longest Prefix Match (Übereinstimmung mit dem längsten Präfix). Ein /16 ist spezifischer als ein /0, also wird dieses Paket im Netzwerk zugestellt. Eine Website im Internet (203.0.113.10) passt dagegen nicht zu den ersten beiden Zeilen. Sie passt nur zu 0.0.0.0/0 und geht deshalb ans Internet-Gateway. Darum heißt 0.0.0.0/0 die Standardroute: Dort landet jede Adresse, zu der sonst nichts passt. Ändere in der Szene unten das Ziel und die Art des Subnetzes.

Öffentliche und private Subnetze

Ein Subnetz mit einer Route Richtung Internet (0.0.0.0/0 → Internet) heißt öffentliches Subnetz, eines ohne diese Route privates Subnetz. Hier stolpern viele: Es entscheidet die Route, nicht der Name, den du dem Subnetz gegeben hast. Und selbst im öffentlichen Subnetz braucht ein Server eine öffentliche IP, um direkt mit dem Internet zu reden. Ein Server, der nur eine private IP hat, ist aus dem Internet nicht erreichbar, auch wenn er in einem öffentlichen Subnetz steht.

Ein typischer Webdienst ist so aufgeteilt.

Deine Datenbank und deine App-Server stecken jetzt in privaten Subnetzen. Sicherheitsupdates brauchen sie aber trotzdem, und an den Speicherdienst der Cloud müssen sie auch. Wie kommen sie ohne Internetroute hinaus?

03

Raus aus dem privaten Subnetz: NAT und private Endpunkte

NAT (Network Address Translation, Netzwerkadressübersetzung) handelt im Auftrag deiner privaten Server. Schickt ein Server ein Paket ins Internet, ersetzt NAT die Quelladresse des Pakets durch seine eigene öffentliche IP und schickt es hinaus. Kommt die Antwort zurück, weiß NAT noch, wer gefragt hat, und reicht die Antwort an den richtigen Server weiter.

Entscheidend ist die Richtung. NAT kümmert sich nur um Verbindungen, die von innen beginnen. Eine Verbindung, die draußen beginnt, wird verworfen, weil NAT keine Ahnung hat, für welchen Server sie gedacht ist. Steht in einer Frage also „Die Server müssen Updates bekommen, dürfen aber aus dem Internet nicht erreichbar sein“, lautet die Antwort NAT. Musst du dagegen Anfragen aus dem Internet annehmen, brauchst du einen Load Balancer (Kapitel 5) oder eine öffentliche IP am Server.

Meist nutzt du NAT als Dienst, den die Cloud für dich verwaltet. Du kannst auch einen eigenen Server zur NAT-Instance machen, aber fällt er aus, verliert das ganze private Subnetz seinen Weg nach draußen – Hochverfügbarkeit und Pflege liegen dann bei dir. Wo ein verwaltetes NAT sitzt (in einer einzelnen Zone oder in der ganzen Region), hängt vom Anbieter ab.

Cloud-Dienste ohne Internet erreichen: private Endpunkte

Verwaltete Cloud-Dienste wie Speicher, Warteschlangen oder Schlüsselverwaltung haben meist öffentliche, zum Internet zeigende Adressen. Ruft ein privater Server sie einfach auf, geht der Verkehr über NAT ins Internet und wieder herein. Mit einem privaten Endpunkt bleibt dieser Weg in deinem Netzwerk. Es gibt zwei Arten.

Jetzt wissen die Pakete, wohin sie sollen. Aber nur weil es eine Straße gibt, lässt du nicht jeden darauf fahren. Du brauchst einen Torwächter, der entscheidet, welche Pakete hineindürfen und welche blockiert werden.