Einzelne ausgehende VPN-Verbindung aus einem Mehrzonencluster konfigurieren

Die einfachste Lösung für die Konfiguration des strongSwan-VPN-Service in einem Mehrzonencluster besteht in der Verwendung einer einzelnen VPN-Verbindung, die zwischen verschiedenen Workerknoten über alle Verfügbarkeitszonen in Ihrem Cluster hinweg gemeinsam genutzt wird.

Wenn die VPN-Verbindung aus dem Mehrzonencluster ausgeht, ist nur eine strongSwan-Bereitstellung erforderlich. Wenn ein Workerknoten entfernt wird oder eine Ausfallzeit erfährt, plant kubelet den VPN-Pod auf einem neuen Workerknoten erneut. Wenn eine Verfügbarkeitszone nicht verfügbar wird, plant kubelet den VPN-Pod auf einem neuen Workerknoten in einer anderen Zone erneut.

1. Konfigurieren Sie nur ein strongSwan-VPN-Helm-Chart. Achten Sie beim Ausführen der Schritte in diesem Abschnitt darauf, die folgenden Einstellungen anzugeben.

   • ipsec.auto: Ändern Sie den Wert in start. Verbindungen gehen von dem Cluster aus.
   • loadBalancerIP: Geben Sie keine IP-Adresse an. Lassen Sie diese Einstellung leer.
   • zoneLoadBalancer: Geben Sie eine öffentliche IP-Adresse für die Lastausgleichsfunktion für jede Zone an, in der Sie Workerknoten haben. Sie können Ihre verfügbaren öffentlichen IP-Adressen zur Überprüfung anzeigen oder eine bereits verwendete IP-Adresse freigeben. Da der strongSwan-VPN-Pod auf einem Workerknoten in einer beliebigen Zone geplant werden kann, stellt diese Liste von IP-Adressen sicher, dass eine IP-Adresse für die Lastausgleichsfunktion in jeder Zone verwendet werden kann, in der der VPN-Pod geplant wird.
   • connectUsingLoadBalancerIP: Setzen Sie den Wert auf true. Wenn der strongSwan-VPN-Pod auf einem Workerknoten geplant wird, wählt der strongSwan-Service die IP-Adresse der Lastausgleichsfunktion aus, die sich in derselben Zone befindet, und verwendet diese IP-Adresse, um eine ausgehende Verbindung herzustellen.
   • local.id: Geben Sie einen festen Wert an, der von Ihrem fernen VPN-Endpunkt unterstützt wird. Wenn der ferne VPN-Endpunkt erfordert, dass Sie die Option local.id (Wert leftid in ipsec.conf) auf die öffentliche IP-Adresse des VPN-IPSec-Tunnels festlegen, legen Sie local.id auf %loadBalancerIP fest. Dieser Wert konfiguriert automatisch den Wert leftid in ipsec.conf für die IP-Adresse der Lastausgleichsfunktion, die für die Verbindung verwendet wird.
   • Optional: Blenden Sie alle Cluster-IP-Adressen hinter einer einzelnen IP-Adresse in jeder Zone aus, indem Sie enableSingleSourceIP auf true festlegen. Diese Option stellt eine der sichersten Konfigurationen für die VPN-Verbindung bereit, da keine Verbindungen vom fernen Netz zurück in den Cluster zulässig sind. Des Weiteren müssen Sie für local.subnet die Variable %zoneSubnet festlegen und local.zoneSubnet verwenden, um eine IP-Adresse als /32-Teilnetz für jede Zone des Clusters anzugeben.

2. Lassen Sie in der Ihrer fernen Netzfirewall eingehende IPSec-VPN-Verbindungen von den öffentlichen IP-Adressen zu, die Sie in der Einstellung zoneLoadBalancer aufgelistet haben.

3. Konfigurieren Sie den fernen VPN-Endpunkt so, dass eine eingehende VPN-Verbindung von jeder der möglichen IP-Adressen der Lastausgleichsfunktion zugelassen wird, die Sie in der Einstellung zoneLoadBalancer aufgelistet haben.

Einzelne eingehende VPN-Verbindung zu einem Mehrzonencluster konfigurieren

Wenn Sie eingehende VPN-Verbindungen benötigen und der ferne VPN-Endpunkt automatisch die VPN-Verbindung zu einer anderen IP-Adresse wiederherstellen kann, wenn ein Fehler erkannt wird, können Sie eine einzelne eingehende VPN-Verbindung verwenden, die zwischen verschiedenen Workerknoten in allen Verfügbarkeitszonen in Ihrem Cluster gemeinsam genutzt werden kann.

Der ferne VPN-Endpunkt kann die VPN-Verbindung zu jeder der strongSwan-Lastausgleichsfunktionen in jeder der Zonen herstellen. Die eingehende Anforderung wird an den VPN-Pod unabhängig davon gesendet, in welcher Zone er sich VPN-Pod befindet. Antworten aus dem VPN-Pod werden über die ursprüngliche Lastausgleichsfunktion an den fernen VPN-Endpunkt gesendet. Diese Option stellt hohe Verfügbarkeit sicher, weil kubelet den VPN-Pod auf einem neuen Workerknoten plant, wenn der Workerknoten entfernt wird oder irgendwie ausfällt. Außerdem kann der ferne VPN-Endpunkt bei einem Ausfall der Verfügbarkeitszone die VPN-Verbindung zu der IP-Adresse der Lastausgleichsfunktion in einer anderen Zone wiederherstellen, sodass der VPN-Pod weiterhin erreichbar bleibt.

1. Konfigurieren Sie nur ein strongSwan-VPN-Helm-Chart. Achten Sie beim Ausführen der Schritte in diesem Abschnitt darauf, die folgenden Einstellungen anzugeben.

   • ipsec.auto: Ändern Sie den Wert in add. Verbindungen gehen in den Cluster ein.
   • loadBalancerIP: Geben Sie keine IP-Adresse an. Lassen Sie diese Einstellung leer.
   • zoneLoadBalancer: Geben Sie eine öffentliche IP-Adresse für die Lastausgleichsfunktion für jede Zone an, in der Sie Workerknoten haben. Sie können Ihre verfügbaren öffentlichen IP-Adressen zur Überprüfung anzeigen oder eine bereits verwendete IP-Adresse freigeben.
   • local.id: Wenn der ferne VPN-Endpunkt erfordert, dass Sie die Option local.id (Wert leftid in ipsec.conf) auf die öffentliche IP-Adresse des VPN-IPSec-Tunnels festlegen, legen Sie local.id auf %loadBalancerIP fest. Dieser Wert konfiguriert automatisch den Wert leftid in ipsec.conf für die IP-Adresse der Lastausgleichsfunktion, die für die Verbindung verwendet wird.

2. Lassen Sie in der Ihrer fernen Netzfirewall ausgehende IPSec-VPN-Verbindungen zu den öffentlichen IP-Adressen zu, die Sie in der Einstellung zoneLoadBalancer aufgelistet haben.

Eingehende VPN-Verbindung in jede Zone eines Mehrzonenclusters konfigurieren

Wenn Sie eingehende VPN-Verbindungen benötigen und der ferne VPN-Endpunkt die VPN-Verbindung nicht zu einer anderen IP wiederherstellen kann, müssen Sie in jeder Zone einen separaten strongSwan-VPN-Service bereitstellen.

Der ferne VPN-Endpunkt muss aktualisiert werden, um eine separate VPN-Verbindung zu einer Lastausgleichsfunktion in jeder der Zonen herzustellen. Darüber hinaus müssen Sie zonenspezifische Einstellungen auf dem fernen VPN-Endpunkt konfigurieren, sodass jede dieser VPN-Verbindungen eindeutig ist. Stellen Sie sicher, dass diese mehreren eingehenden VPN-Verbindungen aktiv bleiben.

Nach der Bereitstellung aller Helm-Charts wird jede strongSwan-VPN-Bereitstellung als Kubernetes-Lastausgleichsservice in der richtigen Zone gestartet. Eingehende Anforderungen an diese öffentliche IP-Adresse werden an den VPN-Pod weitergeleitet, der sich ebenfalls in derselben Zone befindet. Wenn die Zone ausfällt, bleiben die VPN-Verbindungen, die in den anderen Zonen hergestellt wurden, davon unberührt.

1. Konfigurieren Sie ein strongSwan-VPN-Helm-Chart für jede Zone. Wenn Sie die Schritte in diesem Abschnitt ausführen, stellen Sie sicher, dass Sie die folgenden Einstellungen angeben:

   • loadBalancerIP: Geben Sie eine verfügbare öffentliche IP-Adresse für die Lastausgleichsfunktion an, die sich in der Zone befindet, in der Sie diesen strongSwan-Service bereitstellen. Sie können Ihre verfügbaren öffentlichen IP-Adressen zur Überprüfung anzeigen oder eine bereits verwendete IP-Adresse freigeben.
   • zoneSelector: Geben Sie die Zone an, in der der VPN-Pod geplant werden soll.
   • Weitere Einstellungen wie zoneSpecificRoutes, remoteSubnetNAT, localSubnetNAT oder enableSingleSourceIP sind möglicherweise erforderlich, je nachdem, welche Ressourcen über das VPN zugänglich sein müssen. Weitere Informationen finden Sie im nächsten Schritt.

2. Konfigurieren Sie zonenspezifische Einstellungen auf beiden Seiten des VPN-Tunnels, um sicherzustellen, dass jede VPN-Verbindung eindeutig ist. Abhängig von den Ressourcen, die über das VPN zugänglich sein müssen, haben Sie zwei Optionen, die Verbindungen unterscheidbar zu machen:

   • Wenn Pods in dem Cluster auf Services im fernen lokalen Netz zugreifen müssen,
     • zoneSpecificRoutes: Setzen Sie den Wert auf true. Mit dieser Einstellung wird die VPN-Verbindung auf eine einzelne Zonenregion im Cluster beschränkt. Pods in einer bestimmten Zone verwenden nur die VPN-Verbindung, die für diese bestimmte Zone eingerichtet wurde. Diese Lösung verringert die Anzahl der strongSwan-Pods, die zur Unterstützung mehrerer VPNs in einem Mehrzonencluster erforderlich sind, verbessert die VPN-Leistung, weil der VPN-Datenverkehr nur an Workerknoten fließt, die sich in der aktuellen Zone befinden, und stellt sicher, dass die VPN-Konnektivität jeder Zone von der VPN-Konnektivität, den ausgefallenen Pods sowie Zonenausfällen in anderen Zonen nicht betroffen wird. Beachten Sie, dass Sie remoteSubnetNAT nicht konfigurieren müssen. Mehrere VPNs, die die Einstellung zoneSpecificRoutes verwenden, können denselben Wert für remote.subnet haben, weil das Routing auf Zonenebene eingerichtet wird.
     • enableSingleSourceIP: Setzen Sie den Wert auf true und setzen Sie local.subnet auf eine einzelne /32 IP-Adresse. Diese Kombination von Einstellungen blendet alle privaten IP-Adressen des Clusters hinter einer einzelnen /32-IP-Adresse aus. Durch diese eindeutige /32 IP-Adresse kann das ferne Standortnetz Antworten über die richtige VPN-Verbindung an den richtigen Pod im Cluster, der die Anforderung eingeleitet hat, zurücksenden. Beachten Sie, dass die einzelne /32 IP-Adresse, die für die Option local.subnet konfiguriert wird, in jeder strongSwan-VPN-Konfiguration eindeutig sein muss.
   • Wenn Anwendungen in dem lokalen fernen Netz auf Services im Cluster zugreifen müssen,
     • localSubnetNAT: Stellen Sie sicher, dass eine Anwendung im fernen Standortnetz eine bestimmte VPN-Verbindung auswählen kann, um Datenverkehr an den Cluster zu senden und vom Cluster zu empfangen. Verwenden Sie in jeder strongSwan-Helm-Konfiguration die Einstellung localSubnetNAT, um die Clusterressourcen eindeutig anzugeben, auf die von der fernen Anwendung am Standort zugegriffen werden kann. Da mehrere VPNs vom fernen lokalen Netz zum Cluster eingerichtet werden, müssen Sie der Anwendung im lokalen Netz Logik hinzufügen, damit sie auswählen kann, welches VPN beim Zugriff auf Services im Cluster verwendet werden soll. Beachten Sie, dass die Services im Cluster abhängig von der Konfiguration für localSubnetNAT in jeder strongSwan-VPN-Konfiguration über mehrere verschiedene Teilnetze zugänglich sind.
     • remoteSubnetNAT: Stellen Sie sicher, dass ein Pod in Ihrem Cluster dieselbe VPN-Verbindung verwendet, um Datenverkehr an das ferne Netz zurückzugeben. Ordnen Sie in jeder strongSwan-Bereitstellungsdatei das ferne Standortnetz einem eindeutigen Teilnetz mit der Einstellung remoteSubnetNAT zu. Datenverkehr, der von einem Pod im Cluster aus einem VPN-spezifischen fernen Teilnetz (remoteSubnetNAT) empfangen wird, wird an dasselbe ferne VPN-spezifische Teilnetz (remoteSubnetNAT) und dann über dieselbe VPN-Verbindung zurückgesendet.
   • Wenn Pods im Cluster auf Services im fernen lokalen Netz zugreifen müssen und Anwendungen im fernen lokalen Netz auf Services im Cluster zugreifen müssen, konfigurieren Sie die Einstellungen localSubnetNAT und remoteSubnetNAT, die im zweiten Listenpunkt aufgelistet sind. Wenn ein Pod im Cluster eine Anforderung an das ferne lokale Netz einleitet, müssen Sie dem Pod Logik hinzufügen, damit er auswählen kann, welche VPN-Verbindung für den Zugriff auf die Services im fernen lokalen Netz verwendet werden soll.

3. Konfigurieren Sie die Software für den fernen VPN-Endpunkt so, dass eine separate VPN-Verbindung zu der IP-Adresse der Lastausgleichsfunktion in jeder Zone hergestellt wird.

Schritt 1: strongSwan-Helm-Chart abrufen

Installieren Sie Helm und holen Sie sich das strongSwan-Helm-Chart, um mögliche Konfigurationen anzuzeigen.

1. Befolgen Sie die Anweisungen zum Installieren von Version 3 des Helm-Clients auf Ihrer lokalen Maschine.

2. Speichern Sie die Standardkonfigurationseinstellungseinstellungen für das strongSwan-Helm-Chart in einer lokalen YAML-Datei.

   helm show values iks-charts/strongswan > config.yaml
   

3. Öffnen Sie die Datei config.yaml.

Schritt 2: Grundlegende IPSec-Einstellungen konfigurieren

Ändern Sie zum Steuern der Einrichtung der VPN-Verbindung die folgenden grundlegenden IPSec-Einstellungen.

Weitere Informationen zu den einzelnen Einstellungen finden Sie in der Dokumentation, die in der Datei config.yaml für das Helm-Chart bereitgestellt wird.

1. Wenn Ihr lokaler VPN-Tunnelendpunkt ikev2 als Protokoll für die Initialisierung der Verbindung nicht unterstützt, ändern Sie den Wert von ipsec.keyexchange in ikev1.
2. Legen Sie als ipsec.esp die Liste von ESP-Verschlüsselungs-/Authentifizierungsalgorithmen fest, die Ihr lokaler VPN-Tunnelendpunkt für die Verbindung verwendet.
   • Wenn ipsec.keyexchange auf ikev1 festgelegt ist, muss diese Einstellung angegeben werden.
   • Wenn ipsec.keyexchange auf ikev2 festgelegt ist, ist diese Einstellung optional.
   • Wenn Sie diese Einstellung leer lassen, wird der Standardwert für strongSwan-Algorithmen aes128-sha1,3des-sha1 für die Verbindung verwendet.
3. Legen Sie als ipsec.ike die Liste von IKE/ISAKMP-SA-Verschlüsselungs-/Authentifizierungsalgorithmen fest, die Ihr lokaler VPN-Tunnelendpunkt für die Verbindung verwendet. Die Algorithmen müssen im Format encryption-integrity[-prf]-dhgroup angegeben werden.
   • Wenn ipsec.keyexchange auf ikev1 festgelegt ist, muss diese Einstellung angegeben werden.
   • Wenn ipsec.keyexchange auf ikev2 festgelegt ist, ist diese Einstellung optional.
   • Wenn Sie diese Einstellung leer lassen, wird der Standardwert für strongSwan-Algorithmen aes128-sha1-modp2048,3des-sha1-modp1536 für die Verbindung verwendet.
4. Ändern Sie den Wert von local.id in eine beliebige Zeichenfolge, die Sie zum Identifizieren der lokalen Seite des Kubernetes-Clusters verwenden möchten, die Ihr VPN-Tunnelendpunkt verwendet. Der Standardwert ist ibm-cloud. Für einige VPN-Implementierungen ist es erforderlich, dass Sie für den lokalen Endpunkt die öffentliche IP-Adresse verwenden.
5. Ändern Sie den Wert von remote.id in eine beliebige Zeichenfolge, die Sie zum Identifizieren der fernen lokalen Seite verwenden möchten, die Ihr VPN-Tunnelendpunkt verwendet. Der Standardwert ist on-prem. Für einige VPN-Implementierungen ist es erforderlich, dass Sie für den fernen Endpunkt die öffentliche IP-Adresse verwenden.
6. Ändern Sie den Wert von preshared.secret in den vorab verteilten geheimen Schlüssel, den Ihr lokaler VPN-Tunnelendpunkt für die Verbindung verwendet. Dieser Wert wird in ipsec.secrets gespeichert.
7. Optional: Legen Sie für remote.privateIPtoPing eine beliebige private IP-Adresse im fernen Teilnetz fest, die im Rahmen des Helm-Tests zur Konnektivitätsprüfung mit Ping überprüft wird.

Schritt 3: Eingehende oder ausgehende VPN-Verbindung auswählen

Wenn Sie eine strongSwan-VPN-Verbindung konfigurieren, wählen Sie aus, ob die VPN-Verbindung für den Cluster eingehend oder ausgehend ist.

Ankommend

Der lokale VPN-Endpunkt des fernen Netzes initialisiert die VPN-Verbindung und der Cluster ist für die Verbindung empfangsbereit.

Ausgehend

Der Cluster initialisiert die VPN-Verbindung und der lokale VPN-Endpunkt des fernen Netzes ist für die Verbindung empfangsbereit.

Ändern Sie die folgenden Einstellungen, um eine ausgehende VPN-Verbindung herzustellen.

1. Überprüfen Sie, dass für ipsec.auto die Einstellung add festgelegt ist.
2. Optional: Legen Sie für loadBalancerIP eine portierbare öffentliche IP-Adresse fest, die für den strongSwan-VPN-Service gilt. Die Angabe einer IP-Adresse ist nützlich, wenn Sie eine fixe IP-Adresse benötigen, z. B. wenn Sie festlegen müssen, welche IP-Adressen von einer lokalen Firewall zugelassen werden. Der Cluster muss über mindestens eine verfügbare öffentliche IP-Adresse der Lastausgleichsfunktion verfügen. Sie können Ihre verfügbaren öffentlichen IP-Adressen zur Überprüfung anzeigen oder eine bereits verwendete IP-Adresse freigeben.
   • Wenn Sie diese Einstellung leer lassen, wird eine der verfügbaren und portierbaren öffentlichen IP-Adressen verwendet.
   • Sie müssen auch die öffentliche IP-Adresse konfigurieren, die Sie für den VPN-Endpunkt des Clusters im lokalen VPN-Endpunkt auswählen oder die diesem VPN-Endpunkt des Clusters im lokalen VPN-Endpunkt zugewiesen ist.

Ändern Sie die folgenden Einstellungen, um eine ausgehende VPN-Verbindung herzustellen.

1. Ändern Sie ipsec.auto in start.
2. Legen Sie für remote.gateway die öffentliche IP-Adresse für den lokalen VPN-Endpunkt im fernen Netz fest.
3. Wählen Sie als IP-Adresse für den VPN-Endpunkt des Clusters eine der folgenden Optionen:

   • Öffentliche IP-Adresse des privaten Gateways des Clusters: Wenn Ihre Arbeitsknoten nur mit einem privaten VLAN verbunden sind, wird die ausgehende VPN-Anfrage über das private Gateway geleitet, um das Internet zu erreichen. Die öffentliche IP-Adresse des privaten Gateways wird für die VPN-Verbindung verwendet.

   • Öffentliche IP-Adresse des Workerknotens, auf dem der strongSwan-Pod ausgeführt wird: Wenn der Workerknoten, auf dem der strongSwan-Pod ausgeführt wird, mit einem öffentlichen VLAN verbunden ist, wird für die VPN-Verbindung die öffentliche IP-Adresse des Workerknotens verwendet.

     • Wenn der strongSwan-Pod gelöscht und auf einem anderen Workerknoten im Cluster neu geplant wird, ändert sich die öffentliche IP-Adresse des VPNs. Der lokale VPN-Endpunkt des fernen Netzes muss zulassen, dass die VPN-Verbindung über die öffentliche IP-Adresse eines der Workerknoten des Clusters hergestellt wird.
     • Wenn der ferne VPN-Endpunkt keine VPN-Verbindungen von mehreren öffentlichen IP-Adressen verarbeiten kann, begrenzen Sie die Knoten, auf denen der strongSwan-VPN-Pod bereitgestellt wird. Legen Sie für nodeSelector die IP-Adressen bestimmter Workerknoten oder eine Workerknotenbezeichnung fest. Der Wert kubernetes.io/hostname: 10.232.xx.xx lässt beispielsweise nur zu, dass der VPN-Pod auf diesem Workerknoten bereitgestellt wird. Der Wert strongswan: vpn beschränkt die Ausführung des VPN-Pods auf alle Workerknoten mit dieser Bezeichnung. Sie können eine beliebige Workerknotenbezeichnung auswählen. Um die Verwendung unterschiedlicher Workerknoten mit verschiedenen Helm-Diagrammbereitstellungen zuzulassen, verwenden Sie strongswan: <release_name>. Wählen Sie für hohe Verfügbarkeit mindestens zwei Workerknoten aus.

   • Öffentliche IP-Adresse des strongSwan-Service: Zum Herstellen einer Verbindung mithilfe der IP-Adresse des strongSwan-VPN-Service legen Sie für connectUsingLoadBalancerIP die Einstellung true fest. Die IP-Adresse des strongSwan-Service ist entweder eine portierbare öffentliche IP-Adresse, die Sie in der Einstellung loadBalancerIP angeben können, oder eine verfügbare portierbare öffentliche IP-Adresse, die dem Service automatisch zugeordnet wird.

     • Wenn Sie wählen, eine IP-Adresse mithilfe der Einstellung loadBalancerIP auszuwählen, muss der Cluster über mindestens eine verfügbare öffentliche IP-Adresse der Lastausgleichsfunktion verfügen. Sie können Ihre verfügbaren öffentlichen IP-Adressen zur Überprüfung anzeigen oder eine bereits verwendete IP-Adresse freigeben.
     • alle Cluster-Workerknoten müssen sich in demselben öffentlichen VLAN befinden. Andernfalls müssen Sie die Einstellung nodeSelector verwenden, um sicherzustellen, dass der VPN-Pod auf einem Workerknoten in demselben öffentliche VLAN wie loadBalancerIP bereitgestellt wird.
     • Wenn für connectUsingLoadBalancerIP die Einstellung true festgelegt wurde und für ipsec.keyexchange die Einstellung ikev1 gewählt wurde, müssen Sie für enableServiceSourceIP die Einstellung true festlegen.

Schritt 4: Über die VPN-Verbindung auf Clusterressourcen zugreifen

Ermitteln Sie, welche Clusterressourcen für das ferne Netz über die VPN-Verbindung zugänglich sein müssen.

1. Fügen Sie die CIDRs mindestens eines Cluster-Teilnetzes zur Einstellung local.subnet hinzu. Sie müssen die CIDRs des lokalen Teilnetzes im lokalen VPN-Endpunkt konfigurieren. Diese Liste kann die folgenden Teilnetze enthalten.

   • Das Teilnetz-CIDR des Kubernetes-Pods: 172.30.0.0/16. Die bidirektionale Kommunikation ist zwischen allen Cluster-Pods und jedem der Hosts in den Teilnetzen des fernen Netzes aktiviert, die Sie in der Einstellung remote.subnet auflisten. Wenn Sie aus Sicherheitsgründen verhindern müssen, dass remote.subnet-Hosts auf Clusterpods zugreifen, fügen Sie das Kubernetes-Podteilnetz nicht zur Einstellung local.subnet hinzu.
   • Das Teilnetz-CIDR des Kubernetes Service: 172.21.0.0/16. Service-IP-Adressen bieten die Möglichkeit, mehrere App-Pods verfügbar zu machen, die auf mehreren Workerknoten mit einer einzigen IP bereitgestellt sind.
   • Wenn Ihre Apps über einen NodePort-Service im privaten Netz oder in einer privaten Ingress-ALB (ALB – Application Load Balancer) zugänglich gemacht werden, müssen Sie die private Teilnetz-CIDR des Workerknotens hinzufügen. Rufen Sie die ersten drei Oktette der privaten IP-Adresse Ihres Workers ab, indem Sie ibmcloud ks worker <cluster_name> ausführen. Beispiel: Bei 10.176.48.xx notieren Sie sich 10.176.48. Rufen Sie als Nächstes das private Teilnetz des Workers CIDR ab, indem Sie den Befehl <xxx.yyy.zz> durch das Oktett ersetzen, das Sie zuvor abgerufen haben: ibmcloud sl subnet list | grep <xxx.yyy.zzz>. Hinweis: Wenn ein Workerknoten in einem neuen privaten Teilnetz hinzugefügt wird, müssen Sie die neue private Teilnetz-CIDR zur local.subnet-Einstellung und zum lokalen VPN-Endpunkt hinzufügen. Anschließend muss die VPN-Verbindung erneut gestartet werden.
   • Wenn Sie Apps über LoadBalancer-Services im privaten Netz zugänglich machen, müssen Sie die private benutzerverwaltete Teilnetz-CIDR des Clusters hinzufügen. Führen Sie ibmcloud ks cluster get --cluster <cluster_name> --show-resources aus, um diese Werte zu suchen. Suchen Sie im Abschnitt VLANs nach CIDRs, die für Public den Wert false aufweisen. Hinweis: Wenn ipsec.keyexchange auf ikev1 festgelegt ist, können Sie nur ein Teilnetz angeben. Sie können jedoch die Einstellung localSubnetNAT verwenden, um mehrere Teilnetze eines Clusters zu einem einzigen Teilnetz zu kombinieren.

2. Optional: Ordnen Sie Teilnetze eines Clusters erneut zu, indem Sie die Einstellung localSubnetNAT verwenden. Network Address Translation (NAT) für Teilnetze bietet eine Ausweichlösung für Teilnetzkonflikte zwischen dem Clusternetz und dem lokalen fernen Netz. Sie können NAT verwenden, um die privaten lokalen IP-Teilnetze des Clusters, das Pod-Teilnetz (172.30.0.0/16) oder das Teilnetz des Pod-Service (172.21.0.0/16) zu einem anderen privaten Teilnetz zuzuordnen. Der VPN-Tunnel erkennt erneut zugeordnete IP-Teilnetze, die an Stelle der ursprünglichen Teilnetze treten. Die erneute Zuordnung erfolgt vor dem Senden der Pakete über den VPN-Tunnel sowie nach dem Eintreffen der Pakete aus dem VPN-Tunnel. Sie können sowohl erneut zugeordnete als auch nicht erneut zugeordnete Teilnetze gleichzeitig über VPN bereitstellen. Um NAT aktivieren zu können, können Sie entweder ein vollständiges Teilnetz oder einzelne IP-Adressen hinzufügen.

   • Wenn Sie ein vollständiges Teilnetz im Format 10.171.42.0/24=10.10.10.0/24 hinzufügen, erfolgt die Neuzuordnung 1-zu-1:, d. h. alle IP-Adressen im internen Teilnetz werden dem externen Teilnetz zugeordnet und umgekehrt.
   • Wenn Sie einzelne IP-Adressen im Format 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32 zuordnen, werden nur diese internen IP-Adressen den angegebenen externen IP-Adressen zugeordnet.

3. Optional für strongSwan Helm-Diagramme ab Version 2.2.0: Blenden Sie alle Cluster-IP-Adressen hinter einer einzelnen IP-Adresse aus, indem Sie enableSingleSourceIP auf true festlegen. Diese Option stellt eine der sichersten Konfigurationen für die VPN-Verbindung bereit, da keine Verbindungen vom fernen Netz zurück in den Cluster zulässig sind.

   • Diese Einstellung erfordert, dass der gesamte Datenfluss über die VPN-Verbindung ausgehend sein muss; dies ist unabhängig davon, ob die VPN-Verbindung vom Cluster oder vom fernen Netz eingerichtet wird.
   • Wenn Sie strongSwan in einem Einzelzonencluster installieren, dann müssen Sie für local.subnet eine einzelne IP-Adresse als /32-Teilnetz angeben. Wenn Sie strongSwan in einem Mehrzonencluster installieren, können Sie für local.subnet die Variable %zoneSubnet festlegen und local.zoneSubnet verwenden, um eine IP-Adresse als /32-Teilnetz für jede Zone des Clusters anzugeben.

4. Optional für strongSwan-Helm-Charts der Version 2.2.0 und höher: Aktivieren Sie den strongSwan-Service, sodass eingehende Anforderungen des fernen Netzes an einen Service weitergeleitet werden, der sich außerhalb des Clusters befindet. Verwenden Sie dazu die Einstellung localNonClusterSubnet.

   • Der nicht zum Cluster gehörende Service muss im selben privaten Netz oder in einem privaten Netz vorhanden sein, das für die Workerknoten erreichbar ist.
   • Der Nicht-Cluster-Workerknoten kann keinen Datenverkehr zum fernen Netz über die VPN-Verbindung einleiten, aber der Nicht-Cluster-Knoten kann das Ziel eingehender Anforderungen vom fernen Netz sein.
   • Sie müssen die CIDRs der nicht zum Cluster gehörenden Teilnetze in der Einstellung local.subnet auflisten.

Schritt 5: Über die VPN-Verbindung auf ferne Netzressourcen zugreifen

Ermitteln Sie, welche fernen Netzressourcen für das Cluster über die VPN-Verbindung zugänglich sein müssen.

1. Fügen Sie die CIDRs mindestens eines lokalen privaten Teilnetzes zur Einstellung remote.subnet hinzu. Hinweis: Wenn ipsec.keyexchange auf ikev1 festgelegt ist, können Sie nur ein Teilnetz angeben.
2. Optional für strongSwan-Helm-Charts der Version 2.2.0 und höher: Ordnen Sie Teilnetze des fernen Netzes neu zu, indem Sie die Einstellung remoteSubnetNAT verwenden. Network Address Translation (NAT) für Teilnetze bietet eine Ausweichlösung für Teilnetzkonflikte zwischen dem Clusternetz und dem lokalen fernen Netz. Sie können NAT verwenden, um die IP-Teilnetze des fernen Netzes einem anderen privaten Teilnetz zuzuordnen. Die erneute Zuordnung erfolgt vor dem Senden der Pakete über den VPN-Tunnel. Pods im Cluster erkennen die erneut zugeordneten IP-Teilnetze, die an Stelle der ursprünglichen Teilnetze treten. Bevor die Pods Daten über den VPN-Tunnel zurücksenden, wird das neu zugeordnete IP-Teilnetz wieder auf das tatsächliche Teilnetz zurückgestellt, das vom fernen Netz verwendet wird. Sie können sowohl erneut zugeordnete als auch nicht erneut zugeordnete Teilnetze gleichzeitig über VPN bereitstellen.

Schritt 6 (optional): Überwachung mit der Slack-Webhook-Integration aktivieren

Um den Status des strongSwan-VPN zu überwachen, können Sie einen Webhook zum automatischen Posten von VPN-Konnektivitätsnachrichten an einen Slack-Kanal einrichten.

1. Melden Sie sich bei Ihrem Slack-Arbeitsbereich an.

2. Rufen Sie die Seite der App Eingehend WebHooks auf.

3. Klicken Sie auf Installationsanforderung. Falls diese App nicht in Ihrer Slack-Konfiguration aufgeführt ist, wenden Sie sich an den Eigner Ihres Slack-Arbeitsbereichs.

4. Nachdem Ihre Installationsanforderung genehmigt wurde, klicken Sie auf Konfiguration hinzufügen.

5. Wählen Sie einen Slack-Kanal aus oder erstellen Sie einen neuen Kanal, an den die VPN-Nachrichten gesendet werden sollen.

6. Kopieren Sie die Webhook-URL, die generiert wird. Das URL-Format sieht wie folgt aus:

   https://hooks.slack.com/services/A1AA11A1A/AAA1AAA1A/a1aaaaAAAaAaAAAaaaaaAaAA
   

7. Um zu verifizieren, dass der Slack-Webhook installiert wurde, senden Sie eine Testnachricht an Ihre Webhook-URL, indem Sie den folgenden Befehl ausführen:

   curl -X POST -H 'Content-type: application/json' -d '{"text":"VPN test message"}' <webhook_URL>
   

8. Wechseln Sie zu dem Slack-Kanal, den Sie ausgewählt haben, um zu verifizieren, dass die Testnachricht erfolgreich ist.

9. Konfigurieren Sie in der Datei config.yaml für das Helm-Chart den Webhook zum Überwachen Ihrer VPN-Verbindung.

   1. Ändern Sie monitoring.enable in true.
   2. Fügen Sie private IP-Adressen oder HTTP-Endpunkte in dem fernen Teilnetz hinzu, für die Sie sicherstellen möchten, dass sie über die VPN-Verbindung zu monitoring.privateIPs oder monitoring.httpEndpoints erreichbar sind. Sie können beispielsweise die IP aus der Einstellung remote.privateIPtoPing zu monitoring.privateIPs hinzufügen.
   3. Fügen Sie die Webhook-URL zu monitoring.slackWebhook hinzu.
   4. Ändern Sie andere optionale Überwachungseinstellungen (monitoring) nach Bedarf.

Schritt 7: Helm-Chart bereitstellen

Stellen Sie das strongSwan-Helm-Chart in Ihrem Cluster mit den Konfigurationen, die Sie zuvor ausgewählt haben, bereit.

1. Beachten Sie die Dokumentation, die für jede Einstellung im Helm-Chart bereitgestellt ist, wenn Sie weitere erweiterte Einstellungen konfigurieren müssen.

2. Speichern Sie die aktualisierte Datei config.yaml.

3. Installieren Sie das Helm-Chart auf Ihrem Cluster mit der aktualisierten Datei config.yaml.

   Wenn Sie über mehrere VPN-Bereitstellungen in einem einzelnen Cluster verfügen, können Sie Namenskonflikte vermeiden und zwischen Ihren Bereitstellungen unterscheiden, indem Sie aussagekräftigere Releasenamen als vpn verwenden. Um das Abschneiden des Releasenamens zu vermeiden, begrenzen Sie den Releasenamen auf maximal 35 Zeichen.

   helm install vpn iks-charts/strongswan -f config.yaml
   

4. Prüfen Sie den Status der Chartbereitstellung. Wenn das Diagramm fertig ist, hat das Feld STATUS in der Nähe der Ausgabe einen Wert von DEPLOYED.

   helm status vpn
   

5. Überprüfen Sie nach der Bereitstellung des Diagramms, dass die aktualisierten Einstellungen in der Datei config.yaml verwendet wurden.

   helm get values vpn
   

Es werden nur die Versionen des StrongSwan-Helm-Charts unterstützt, die in den letzten 6 Monaten veröffentlicht wurden. Stellen Sie sicher, dass das strongSwan-Helm-Chart fortlaufend mit aktuellen Features und Sicherheitskorrekturen aktualisiert wird.

strongSwan-VPN-Datenverkehr nach Namensbereich

Wenn Sie über ein Single-Tenant-Cluster verfügen oder über ein Multi-Tenant-Cluster verfügen, können Sie den VPN-Datenverkehr auf Pods in bestimmten Namensbereichen beschränken.

Nehmen wir beispielsweise an, dass Pods nur in einem bestimmten Namensbereich, my-secure-namespace, Daten über das VPN senden und empfangen sollen. Sie möchten nicht, dass Pods in anderen Namensbereichen wie kube-system, ibm-system oder default auf Ihr lokales Netz zugreifen. Um den VPN-Datenverkehr auf my-secure-namespace zu beschränken, können Sie globale Calico-Netzrichtlinien erstellen.

Prüfen Sie die folgenden Überlegungen und Einschränkungen, bevor Sie diese Lösung einsetzen.

• Sie müssen das strongSwan Helm-Diagramm nicht im angegebenen Namensbereich bereitstellen. Der strongSwan-VPN-Pod und die Routen-Dämongruppe können im Namensbereich kube-system oder in einem beliebigen anderen Namensbereich bereitgestellt werden. Wenn das strongSwan-VPN nicht im angegebenen Namensbereich bereitgestellt wird, schlägt der Helm-Test für vpn-strongswan-ping-remote-ip-1 fehl. Dieser Fehler wird erwartet und ist zulässig. Der Test setzt ein Pingsignal an die private IP-Adresse remote.privateIPtoPing des lokalen VPN-Gateways von einem VPN-Pod ab, der sich nicht in dem Namensbereich mit direktem Zugriff auf das ferne Teilnetz befindet. Der VPN-Pod kann jedoch weiterhin Datenverkehr an Pods in den Namensbereichen weiterleiten, die über Routen zu dem fernen Teilnetz verfügen, und der Datenverkehr kann weiter ordnungsgemäß fließen. Der VPN-Status lautet immer noch ESTABLISHED und die Pods im angegebenen Namensbereich können über das VPN eine Verbindung herstellen.

• Die globalen Calico-Netzrichtlinien in den folgenden Schritten verhindern nicht, dass Kubernetes-Pods, die Hostnetzbetrieb verwenden, Daten über das VPN senden und empfangen. Wenn ein Pod mit Hostnetzbetrieb konfiguriert wird, kann die in dem Pod ausgeführte App an den Netzschnittstellen des Workerknotens, auf dem sie sich befindet, empfangsbereit sein. Diese Hostnetzbetrieb-Pods können in allen Namensbereichen vorhanden sein. Um festzustellen, welche Pods über Hostvernetzung verfügen, führen Sie kubectl get pods --all-namespaces -o wide aus und suchen Sie nach Pods, die keine 172.30.0.0/16-Pod-IP-Adresse haben. Wenn Sie ausschließen möchten, dass Hostnetzbetrieb-Pods Daten über das VPN senden und empfangen, können Sie die folgenden Optionen in Ihrer Bereitstellungsdatei values.yaml festlegen: local.subnet: 172.30.0.0/16 und enablePodSNAT: false. Diese Konfigurationseinstellungen machen alle Kubernetes-Pods über die VPN-Verbindung für das ferne Netz zugänglich. Es sind jedoch nur die Pods über das VPN erreichbar, die sich im angegebenen sicheren Namensbereich befinden.

Vorbereitende Schritte

• Stellen Sie das strongSwan-Helm-Chart bereit und stellen Sie sicher, dass die VPN-Konnektivität ordnungsgemäß funktioniert.
• Installieren und konfigurieren Sie die Calico-CLI.

Zum Begrenzen des VPN-Datenverkehrs für einen bestimmten Namensbereich

1. Erstellen Sie eine globale Calico-Netzrichtlinie namens allow-non-vpn-outbound.yaml. Diese Richtlinie ermöglicht es allen Namensbereichen, weiterhin ausgehenden Datenverkehr an alle Ziele zu senden, mit Ausnahme des fernen Teilnetzes, auf das das strongSwan-VPN zugreift. Ersetzen Sie <remote.subnet> durch die remote.subnet, die Sie in der Helm values.yaml-Konfigurationsdatei angegeben haben. Um mehrere entfernte Subnetze anzugeben, siehe die Dokumentation Calico.

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-non-vpn-outbound
   spec:
     selector: has(projectcalico.org/namespace)
     egress:
     - action: Allow
       destination:
         notNets:
         - <remote.subnet>
     order: 900
     types:
     - Egress
   

2. Wenden Sie die Richtlinie an.

   calicoctl apply -f allow-non-vpn-outbound.yaml --config=filepath/calicoctl.cfg
   

3. Erstellen Sie eine weitere globale Calico-Netzrichtlinie namens allow-vpn-from-namespace.yaml. Diese Richtlinie ermöglicht es nur einem bestimmten Namensbereich, ausgehenden Datenverkehr an das ferne Teilnetz zu senden, auf das das strongSwan-VPN zugreift. Ersetzen Sie <namespace> durch den Namensbereich, der auf das VPN zugreifen kann, und <remote.subnet> durch die remote.subnet, die Sie in der Helm values.yaml-Konfigurationsdatei angegeben haben. Um mehrere Namensräume oder entfernte Subnetze anzugeben, siehe die Dokumentation Calico.

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-vpn-from-namespace
   spec:
     selector: projectcalico.org/namespace == "<namespace>"
     egress:
     - action: Allow
       destination:
         nets:
         - <remote.subnet>
   order: 900
   types:
     - Egress
   

4. Wenden Sie die Richtlinie an.

   calicoctl apply -f allow-vpn-from-namespace.yaml --config=filepath/calicoctl.cfg
   

5. Verifizieren Sie, dass die globalen Netzrichtlinien in Ihrem Cluster erstellt werden.

   calicoctl get GlobalNetworkPolicy -o wide --config=filepath/calicoctl.cfg
   

strongSwan-VPN-Datenverkehr nach Workerknoten beschränken

Wenn Sie über mehrere strongSwan-VPN-Bereitstellungen in einem Multi-Tenant-Cluster verfügen, können Sie den VPN-Datenverkehr für jede Bereitstellung auf bestimmte Workerknoten beschränken, die den einzelnen Tenants zugeordnet sind.

Wenn Sie ein strongSwan-Helm-Chart bereitstellen, wird eine strongSwan-VPN-Bereitstellung erstellt. Die strongSwan-VPN-Pods werden auf allen Workerknoten ohne Taints bereitgestellt. Außerdem wird eine Kubernetes-Dämongruppe erstellt. Diese Dämongruppe konfiguriert automatisch Routen auf allen Workerknoten ohne Taint in dem Cluster zu den jeweiligen fernen Teilnetzen. Der strongSwan-VPN-Pod verwendet die Routen auf Workerknoten, um Anforderungen an das ferne Teilnetz in dem lokalen Netz weiterzuleiten.

Routen werden nicht für Knoten mit Taint konfiguriert, es sei denn, Sie geben den Taint in der Einstellung für Tolerierungen (tolerations) in der Datei value.yaml ein. Indem Sie Workerknoten mit Taints versehen, können Sie verhindern, dass auf diesen Workern VPN-Routen konfiguriert werden. Anschließend können Sie den Taint in der Einstellung für Tolerierungen (tolerations) nur für die VPN-Bereitstellung angeben, die Sie auf den Workern mit Taint zulassen möchten. Auf diese Weise verwenden die strongSwan-VPN-Pods für die Bereitstellung des Helm-Charts eines Tenants nur die Routen auf den Workerknoten dieses Tenants, um Datenverkehr über die VPN-Verbindung an das ferne Teilnetz weiterzuleiten.

Prüfen Sie die folgenden Überlegungen und Einschränkungen, bevor Sie diese Lösung einsetzen.

• Standardmäßig platziert Kubernetes App-Pods auf allen verfügbaren Workerknoten ohne Taints. Um sicherzustellen, dass diese Lösung ordnungsgemäß funktioniert, muss jeder Tenant zunächst sicherstellen, dass ihre App-Pods nur auf Workern bereitgestellt werden, die mit einem Taint für den richtigen Tenant versehen sind. Außerdem muss jeder Workerknoten mit Taint auch über eine Tolerierung verfügen, damit die App-Pods auf dem Knoten platziert werden können. Weitere Informationen über Färbungen und Toleranzen finden Sie in der Dokumentation Kubernetes.
• Clusterressourcen werden möglicherweise nicht optimal genutzt, weil keiner der Tenants App-Pods auf den gemeinsam genutzten Knoten ohne Taints platzieren kann.

In den folgenden Schritten zum Einschränken des strongSwan-VPN-Datenverkehrs nach Workerknoten wird dieses Beispielszenario verwendet: Angenommen, Sie verfügen über einen Multi-Tenant-Cluster von IBM Cloud Kubernetes Service mit sechs Workerknoten. Der Cluster unterstützt Tenant A und Tenant B. Die Workerknoten werden wie folgt mit einem Taint versehen.

• Zwei Workerknoten haben Taints, sodass nur Tenant A-Pods auf den Workern geplant sind.
• Zwei Workerknoten haben Taints, sodass nur Tenant B-Pods auf den Workern geplant sind.
• Zwei Workerknoten haben keine Taints, weil mindestens zwei Workerknoten erforderlich sind, damit die strongSwan-VPN-Pods und die IP der Lastausgleichsfunktion ausgeführt werden können.

Zum Begrenzen des VPN-Datenverkehrs an mit Taint versehene Knoten für jeden Tenant.

1. Zum Begrenzen des VPN-Datenverkehrs nur auf dedizierte Worker für Tenant A geben Sie im vorliegenden Beispiel die folgende toleration in der Datei values.yaml für das strongSwan-Helm Chart für Tenant A an.

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantA"
   effect: "NoSchedule"
   

   Diese Tolerierung ermöglicht das Ausführen der Routing-Dämongruppe auf den beiden Workerknoten mit dem Taint dedicated="tenantA" und auf den beiden Workerknoten ohne Taints. The strongSwan VPN pods for this deployment run on the two untainted worker nodes.

2. Zum Begrenzen des VPN-Datenverkehrs nur auf dedizierte Worker für Tenant B geben Sie im vorliegenden Beispiel die folgende toleration in der Datei values.yaml für das strongSwan-Helm-Chart für Tenant B an.

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantB"
   effect: "NoSchedule"
   

   Diese Tolerierung ermöglicht das Ausführen der Routing-Dämongruppe auf den beiden Workerknoten mit dem Taint dedicated="tenantB" und auf den beiden Workerknoten ohne Taints. Die strongSwan-VPN-Pods für diese Bereitstellung werden auch auf den beiden Workerknoten ohne Taints ausgeführt.