Site-to-site VPN und Cloud Native

Cloud Native und herkömmliche On-Premise Services im Zusammenspiel

In unseren Digitalisierungsprojekten begegnen wir häufig Kunden, die viele ihrer Services On-Premise selbst hosten. In der Natur unserer Projekte ist häufig die Integration dieser Services mindestens zu Teilen notwendig um neue Werte zu liefern. Bei CloudNative-Projekten ist die klassische Antwort für die Verbindungsfrage aus der Kunden-IT-Abteilung zu den On-Premise Services fast immer Site-to-Site VPN.

Basis Setup

Damit eine solche Verbindung funktioniert, müssen Parameter zwischen beiden Sites vereinbart werden:

  • Public IP Cloud & OnPremise
  • IPsec / IKE policy sowie dem dazugehörigen Pre-Shared key (PSK)
  • geroutete OnPremise-Site Endpunkte/Netze (IP / Port), ggf. zugehörige Hostnames für die SSL Zertifikatsauthentifizierung
  • Das Netz aus dem die Cloud-Services über das VPN die OnPremise-Services erreichen dürfen

Ein Beispiel für ein solches Setup:

Example Setup

Virtuelle Netze

Damit es nicht zu Konflikten kommt verwaltet die Kunden-IT normalerweise die OnPremise-Netzzuweisung und geht daher sparsam mit Netzen um. Im Beispiel wurde den Cloud-Diensten ein 8bit-Netz zugewiesen. Damit stehen der Cloud-Infrastruktur 253 IP-Adressen zur Verfügung. Die VPN-Infrastruktur innerhalb der Cloud benötigt selbstverständlich ebenfalls einige IP-Adressen. Je nach Hyperscaler (Amazon, Google, Azure, ...) muss die VPN Infrastruktur in einem eigenen Subnetz leben und benötigt eine gewisse Anzahl an IP-Adressen. Bei Azure sind dies z.B. 5 zuzüglich Netz- und Broadcast-Adresse. Damit benötigen wir also mindestens ein 3-bit Subnetz.

Das Netz muss in Subnetze aufgeteilt werden. Bei maximaler Ausnutzung können folgende Subnetze konfiguriert werden:

Adressraum Rolle
192.168.88.0/25 primäres Subnetz für die Cloudservices
192.168.88.128/26 optionales Subnetz
192.168.88.192/27 optionales Subnetz
192.168.88.224/28 optionales Subnetz
192.168.88.240/29 VPN Gateway Subnetz

Kubernetes und Subnetze

Wir tendieren zu Kubernetes als Abstraktionsschicht um einen Vendor-Lock-In zu minimieren. Im Falle von Azure Kubernetes (AKS) können dem Cluster Nodepools zugewiesen werden, die wiederum einem Subnetz zugewiesen werden können. Weisen wir das größte Subnetz einem AKS Nodepool zu würde dies so aussehen:

Kubernetes Networking

Auch wenn die Services in den Pods innerhalb des KubeNets laufen, können sie dennoch die On-Premise Services erreichen, da der Netzwerktraffic über die Nodes geroutet wird, welche wiederum in einem Subnetz leben, dessen Traffic über das VPN geroutet werden darf.

Effekte

Neben dem offensichtlichen Vorteil Zugriff auf die OnPremise-Services zu haben bietet dieser Ansatz jedoch einige Nachteile:

  • Die Anzahl der Nodepools, die über das VPN kommunizieren können ist durch die Anzahl der Subnetze im zugewiesen Netz begrenzt (hier maximal 4 Nodepools).
  • Die theoretische maximale Größe eines Nodepools wird durch die Anzahl der verfügbaren IP-Adressen im jeweiligen Subnetz begrenzt (im größten Nodepool maximal 126 Nodes)
  • Einschränkungen durch rolling Kubernetes updates: Bei einem Udpate werden parallel neue Nodes mit dem neusten AKS Image hochgefahren, bis der gesamte Cluster mit der neuen Version verfügbar ist. Anschließend werden die Nodes der alten Version runtergefahren. Dadurch wird die praktische Größe der Nodepools nochmals halbiert (Im größten Nodepool maximal 63 Nodes).
  • Man kann parallel keinen weiteren Cluster hochfahren, ohne dem neuen Cluster ein neues Netz und entsprechende Subnetzaufteilung zuzuweisen. Dies erfordert einen weiteren Abstimmungszyklus mit der Kunden-IT. Somit wird eine Desaster-Recovery erschwert.
  • Im Falle von AKS konnten wir Problem mit einem gestoppten Cluster und einem gestarteten Cluster mit gleicher Subnetzkonfiguration beobachten: Die Routingtabelle (AKS-managed) des gestoppten Clusters wurde vom zweiten aktiven Cluster verwendet. Das Abreißen des gestoppten Clusters war daher in Produktion nicht möglich, da die resultierenden Effekte auf den aktiven Cluster unklar waren.

Fazit

Ein Site-to-Site VPN macht genau das was es soll: Services zweier Netze einander verfügbar zu machen. Man unterwirft jedoch die CloudServices einem recht strengen Korsett. Zwar sind 63 Nodes – je nach Maschinentyp – für mittlere Digitalisierungsprojekte in der Regel ausreichend, bei größeren Unterfangen kann dieses Limit jedoch problematisch werden. Kritisch sehen wir die Einschränkung der Flexibilität. In einem Desasterfall nicht schnell reagieren zu können ist unserer Meinung nach nicht mehr zeitgemäß und kann durch andere Lösungsansätze wie Hub and Spoke- oder API-Gateway-Architekturen besser adressiert werden.