Configuration d'une connexion VPN sortante unique dans un cluster multizone

La solution de configuration la plus simple pour un service VPN strongSwan dans un cluster multizone est d'utiliser une seule connexion VPN sortante flottant entre différents noeuds worker sur toutes les zones de disponibilité dans votre cluster.

Lorsqu'il s'agit d'une connexion VPN sortante dans votre cluster multizone, un seul déploiement strongSwan est requis. En cas de retrait ou d'indisponibilité d'un noeud worker, kubelet replanifie le pod VPN sur un nouveau noeud worker. Si une zone de disponibilité fait l'objet d'une défaillance, kubelet replanifie le pod VPN sur un nouveau noeud worker dans une autre zone.

1. Configurez une charte Helm de VPN strongSwan. Lorsque vous suivez la procédure indiquée dans cette section, veillez à spécifier les paramètres suivants.

   • ipsec.auto : remplacez ce paramètre par start. Les connexions sont sortantes dans le cluster.
   • loadBalancerIP : n'indiquez pas d'adresse IP. Laissez ce paramètre vide.
   • zoneLoadBalancer : spécifiez une adresse IP d'équilibreur de charge public pour chaque zone dans laquelle vous avez des noeuds worker. Vous pouvez vérifier quelles sont vos adresses IP publiques disponibles ou libérer une adresse IP utilisée. Comme le pod du VPN strongSwan peut être planifié sur un noeud worker dans n'importe quelle zone, cette liste d'adresses IP permet de garantir qu'une adresse IP d'équilibreur de charge peut être utilisée dans n'importe quelle zone où est planifié un pod VPN.
   • connectUsingLoadBalancerIP : défini sur true. Lorsque le pod VPN strongSwan est planifié sur un noeud worker, le service strongSwan sélectionne l'adresse IP de l'équilibreur de charge qui se trouve dans la même zone et utilise cette adresse IP pour établir la connexion sortante.
   • local.id : indiquez une valeur fixe prise en charge par votre point de terminaison VPN distant. Si le nœud final VPN distant nécessite que vous définissez l'option local.id (valeurleftid dans ipsec.conf) sur l'adresse IP publique du tunnel IPSec VPN, définissez local.id sur %loadBalancerIP. Cette valeur configure automatiquement la valeur leftid dans ipsec.conf sur l'adresse IP de l'équilibreur de charge qui est utilisée pour la connexion.
   • Facultatif : masquez toutes les adresses IP de cluster derrière une seule adresse IP dans chaque zone en définissant enableSingleSourceIP sur true. Cette option offre l'une des configurations les plus sécurisées pour la connexion VPN car aucune connexion de réseau distant revenant vers le cluster n'est autorisée. Vous devez également affecter au paramètre local.subnet la variable %zoneSubnet et utiliser local.zoneSubnet pour spécifier une adresse IP sous la forme d'un sous-réseau /32 pour chaque zone du cluster.

2. Dans votre pare-feu de réseau distant, autorisez les connexions VPN IPSec entrantes en provenance des adresses IP publiques que vous avez répertoriées dans le paramètre zoneLoadBalancer.

3. Configurez le point de terminaison VPN distant pour autoriser la connexion VPN entrante depuis chacune des adresses IP d'équilibreur de charge possibles que vous avez répertoriées dans le paramètre zoneLoadBalancer.

Configuration d'une connexion VPN entrante unique dans un cluster multizone

Lorsque vous avez besoin de connexions VPN entrantes et que le point de terminaison VPN distant peut rétablir automatiquement la connexion VPN sur une autre adresse IP lorsqu'une défaillance est détectée, vous pouvez utiliser une seule connexion VPN entrante flottant entre différents noeuds worker dans toutes les zones de disponibilité dans votre cluster.

Le point de terminaison VPN distant peut établir la connexion VPN à un équilibreur de charge strongSwan dans n'importe quelle zone. La demande entrante est envoyée au pod VPN quelle que soit la zone dans laquelle se trouve ce pod. Les réponses provenant du pod VPN sont renvoyées via l'équilibreur de charge d'origine au point de terminaison VPN distant. Cette option permet d'assurer la haute disponibilité car kubelet replanifie le pod VPN sur un nouveau noeud worker en cas de retrait ou d'indisponibilité d'un noeud worker. De plus, en cas de défaillance d'une zone de disponibilité, le point de terminaison VPN distant peut rétablir la connexion VPN à l'adresse IP de l'équilibreur de charge dans une autre zone de sorte que le pod VPN soit toujours joignable.

1. Configurez une charte Helm de VPN strongSwan. Lorsque vous suivez la procédure indiquée dans cette section, veillez à spécifier les paramètres suivants.

   • ipsec.auto : remplacez ce paramètre par add. Les connexions sont entrantes dans le cluster.
   • loadBalancerIP : n'indiquez pas d'adresse IP. Laissez ce paramètre vide.
   • zoneLoadBalancer : spécifiez une adresse IP d'équilibreur de charge public pour chaque zone dans laquelle vous avez des noeuds worker. Vous pouvez vérifier quelles sont vos adresses IP publiques disponibles ou libérer une adresse IP utilisée.
   • local.id: si le noeud final VPN distant nécessite que vous définissez l'option local.id (valeurleftid dans ipsec.conf) sur l'adresse IP publique du tunnel IPSec VPN, définissez local.id sur %loadBalancerIP. Cette valeur configure automatiquement la valeur leftid dans ipsec.conf sur l'adresse IP de l'équilibreur de charge qui est utilisée pour la connexion.

2. Dans votre pare-feu de réseau distant, autorisez les connexions VPN IPSec sortantes à destination des adresses IP publiques que vous avez répertoriées dans le paramètre zoneLoadBalancer.

Configuration d'une connexion VPN entrante dans chaque zone d'un cluster multizone

Lorsque vous avez besoin de connexions VPN entrantes et que le noeud final VPN distant ne peut pas rétablir la connexion VPN à une adresse IP différente, vous devez déployer un service VPN distinct de strongSwan dans chaque zone.

Le point de terminaison VPN distant doit être mis à jour pour établir une connexion VPN distincte à un équilibreur de charge dans chaque zone. De plus, vous devez configurer des paramètres spécifiques à chaque zone sur le point de terminaison VPN distant pour que chaque connexion VPN de ce type soit unique. Vérifiez que ces connexions VPN entrantes restent actives.

Après avoir déployé chaque charte Helm, chaque déploiement de VPN strongSwan démarre sous forme de service d'équilibreur de charge Kubernetes dans la zone concernée. Les demandes entrantes à cette adresse IP publiques sont transmises au pod VPN qui est également alloué dans la même zone. Si la zone devient indisponible, il n'y a aucune incidence sur les connexions VPN établies dans les autres zones.

1. Configurez une charte Helm de VPN strongSwan dans chaque zone. Lorsque vous suivez la procédure indiquée dans cette section, veillez à spécifier les paramètres suivants :

   • loadBalancerIP : spécifiez une adresse IP d'équilibreur de charge public disponible située dans la zone dans laquelle vous déployez ce service strongSwan. Vous pouvez vérifier quelles sont vos adresses IP publiques disponibles ou libérer une adresse IP utilisée.
   • zoneSelector : indiquez la zone dans laquelle vous voulez que le pod VPN soit planifié.
   • D'autres paramètres, tels que zoneSpecificRoutes, remoteSubnetNAT, localSubnetNAT ou enableSingleSourceIP, peuvent être requis en fonction des ressources qui doivent être accessibles via le VPN. Voir l'étape suivante pour obtenir plus de détails.

2. Configurez des paramètres spécifiques à une zone des deux côtés du tunnel VPN pour vous assurer que chaque connexion VPN est unique. Selon les ressources qui doivent être accessibles via le VPN, vous disposez de deux options pour rendre les connexions différenciables :

   • Si les pods du cluster doivent accéder à des services sur le réseau sur site à distance,
     • zoneSpecificRoutes : défini sur true. Ce paramètre limite la connexion VPN à une seule région de la zone dans le cluster. Les pods d'une zone spécifique utilisent uniquement la connexion VPN configurée pour cette zone spécifique. Cette solution réduit le nombre de pods strongSwan nécessaires pour prendre en charge plusieurs VPN dans un cluster multizone, améliore les performances du VPN car le trafic du VPN passe uniquement par les noeuds worker situés dans la zone actuelle et garantit que la connectivité VPN pour chaque zone n'est pas impactée par la connectivité VPN, les pods en panne ou l'indisponibilité de zone dans les autres zones. Notez que vous n'avez pas besoin de configurer remoteSubnetNAT. Plusieurs VPN qui utilisent le paramètre zoneSpecificRoutes peuvent avoir le même paramètre remote.subnet car le routage est configuré par zone.
     • enableSingleSourceIP : définissez ce paramètre sur true et le paramètre local.subnet sur une adresse IP /32 unique. Cette combinaison de paramètres masque toutes les adresses IP privées du cluster derrière une adresse IP unique /32. Cette adresse IP /32 unique permet au réseau sur site à distance de renvoyer des réponses via la connexion VPN adéquate au pod approprié dans le cluster ayant initié la demande. Notez que l'adresse IP /32 unique configurée pour l'option local.subnet doit être unique dans chaque configuration de VPN strongSwan.
   • Si des applications dans le réseau sur site à distance doivent accéder aux services dans le cluster,
     • localSubnetNAT : vérifiez qu'une application dans le réseau distant sur site peut sélectionner une connexion VPN spécifique pour l'envoi et la réception de trafic dans le cluster. Dans chaque configuration Helm strongSwan, utilisez le paramètre localSubnetNAT pour identifier de manière unique les ressources de cluster accessibles à l'application sur site distante. Étant donné que plusieurs VPN sont établis à partir du réseau local distant vers le cluster, vous devez ajouter une logique à l'application sur le réseau sur site pour qu'il puisse sélectionner le VPN à utiliser lorsqu'il accède aux services du cluster. Notez que les services du cluster sont accessibles via plusieurs sous-réseaux distincts en fonction de ce que vous avez configuré pour le paramètre localSubnetNAT dans chaque configuration de VPN strongSwan.
     • remoteSubnetNAT: vérifiez qu'un pod de votre cluster utilise la même connexion VPN pour renvoyer le trafic au réseau distant. Dans chaque fichier de déploiement strongSwan, mappez le sous-réseau sur site distant à un sous-réseau unique en utilisant le paramètre remoteSubnetNAT. Le trafic reçu par un pod dans le cluster à partir du paramètre remoteSubnetNAT spécifique à un VPN est renvoyé à ce même paramètre remoteSubnetNAT, puis via cette même connexion VPN.
   • Si les pods du cluster doivent accéder aux services sur le réseau sur site distant et que les applications du réseau sur site distant doivent accéder aux services du cluster, configurez les paramètres localSubnetNAT et remoteSubnetNAT répertoriés dans le deuxième point. Notez que si un pod du cluster lance une demande sur le réseau distant sur site, vous devez ajouter une logique au pod afin qu'il puisse sélectionner la connexion VPN à utiliser pour accéder aux services sur le réseau distant sur site.

3. Configurez le logiciel du point de terminaison VPN distant pour établir une connexion VPN distincte à l'adresse IP de l'équilibreur de charge dans chaque zone.

Etape 1 : Obtenez la charte Helm strongSwan

Installez Helm et récupérez la charte Helm strongSwan pour afficher les configurations possibles.

1. Suivez les instructions pour installer le client Helm version 3 sur votre machine locale.

2. Sauvegardez les paramètres de configuration par défaut pour la charte Helm strongSwan dans un fichier YAML local.

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

3. Ouvrez le fichier config.yaml.

Etape 2 : Configurez les paramètres de base IPSec

Pour contrôler si la connexion VPN est établie, modifiez les paramètres de base IPSec suivants.

Pour plus d'informations sur chacun de ces paramètres, lisez la documentation fournie dans le fichier config.yaml de la charte Helm.

1. Si votre point de terminaison de tunnel VPN sur site ne prend pas en charge ikev2 comme protocole d'initialisation de la connexion, remplacez la valeur de ipsec.keyexchange par ikev1.
2. Définissez ipsec.esp par une liste d'algorithmes de chiffrement et d'authentification ESP utilisés par votre point de terminaison de tunnel VPN pour la connexion.
   • Si ipsec.keyexchange est défini avec ikev1, ce paramètre doit être spécifié.
   • Si ipsec.keyexchange est défini avec ikev2, ce paramètre est facultatif.
   • Si vous laissez ce paramètre vide, les algorithmes strongSwan par défaut aes128-sha1,3des-sha1 sont utilisés pour la connexion.
3. Définissez ipsec.ike par une liste d'algorithmes de chiffrement et d'authentification IKE/ISAKMP utilisés par votre point de terminaison de tunnel VPN pour la connexion. Ces algorithmes doivent être spécifiés au format encryption-integrity[-prf]-dhgroup.
   • Si ipsec.keyexchange est défini avec ikev1, ce paramètre doit être spécifié.
   • Si ipsec.keyexchange est défini avec ikev2, ce paramètre est facultatif.
   • Si vous laissez ce paramètre vide, les algorithmes strongSwan par défaut aes128-sha1-modp2048,3des-sha1-modp1536 sont utilisés pour la connexion.
4. Remplacez la valeur de local.id par une chaîne de votre choix que vous voulez utiliser pour identifier le côté du cluster Kubernetes local utilisé par votre point de terminaison de tunnel VPN. La valeur par défaut est ibm-cloud. Certaines mises en oeuvre de VPN nécessitent l'utilisation de l'adresse IP publique du point de terminaison local.
5. Remplacez la valeur de remote.id par une chaîne de votre choix que vous voulez utiliser pour identifier le côté du site distant utilisé par votre point de terminaison de tunnel VPN. La valeur par défaut est on-prem. Certaines mises en oeuvre de VPN nécessitent l'utilisation de l'adresse IP publique du point de terminaison distant.
6. Remplacez la valeur preshared.secret par le secret pré-partagé que votre passerelle de point de terminaison de tunnel VPN utilise pour la connexion. Cette valeur est stockée dans ipsec.secrets.
7. Facultatif : définissez remote.privateIPtoPing avec une adresse IP privée du sous-réseau distant à interroger par commande ping dans le cadre du test de validation de connectivité Helm.

Etape 3 : Sélectionnez une connexion VPN entrante ou sortante

Lorsque vous configurez une connexion VPN strongSwan, vous déterminez si la connexion VPN est une connexion entrant dans le cluster ou sortant du cluster.

Entrant

Le point de terminaison VPN sur site du réseau distant initie la connexion VPN et le cluster est à l'écoute de la connexion.

Sortant

Le cluster initie la connexion VPN, et le point de terminaison VPN sur site du réseau distant est à l'écoute de la connexion.

Pour établir une connexion VPN entrante, modifiez les paramètres suivants :

1. Vérifiez que le paramètre ipsec.auto est défini avec la valeur add.
2. Facultatif : définissez loadBalancerIP avec une adresse IP publique portable pour le service VPN strongSwan. La spécification d'une adresse IP est utile lorsque vous avez besoin d'une adresse IP stable, par exemple lorsque vous devez désigner quelles sont les adresses IP autorisées via un pare-feu local. Le cluster doit disposer d'au moins une adresse IP d'équilibreur de charge publique disponible. Vous pouvez vérifier quelles sont vos adresses IP publiques disponibles ou libérer une adresse IP utilisée.
   • Si vous laissez ce paramètre vide, une des adresses IP publiques portables disponibles est utilisée.
   • Vous devez également configurer l'adresse IP publique que vous sélectionnez ou l'adresse IP publique affectée pour le point de terminaison VPN du cluster sur le point de terminaison VPN sur site.

Pour établir une connexion VPN sortante, modifiez les paramètres suivants.

1. Remplacez ipsec.auto par start.
2. Définissez remote.gateway avec l'adresse IP publique du point de terminaison VPN sur site du réseau distant.
3. Sélectionnez l'une des options suivantes pour l'adresse IP du point de terminaison VPN du cluster :

   • Adresse IP publique de la passerelle privée du cluster: Si vos nœuds de travail sont connectés à un VLAN privé uniquement, la requête VPN sortante est acheminée via la passerelle privée pour atteindre l'internet. L'adresse IP publique de la passerelle privée est utilisée pour la connexion VPN.

   • Adresse IP publique du noeud worker sur lequel s'exécute le pod strongSwan : si le noeud worker sur lequel s'exécute le pod strongSwan est connecté à un VLAN public, l'adresse IP publique du noeud worker est utilisée pour la connexion VPN.

     • Si le pod strongSwan est supprimé ou replanifié sur un autre noeud worker du cluster, l'adresse IP publique du VPN change. Le point de terminaison VPN sur site du réseau distant doit autoriser l'établissement de la connexion VPN à partir d'une adresse IP publique de n'importe quel noeud worker du cluster.
     • Si le nœud final VPN distant ne peut pas gérer les connexions VPN à partir de plusieurs adresses IP publiques, limitez les nœuds sur lequel se déploie le réseau VPN de strongSwan. Définissez nodeSelector avec les adresses IP des noeuds worker spécifiques ou avec le libellé d'un noeud worker. Par exemple, la valeur kubernetes.io/hostname: 10.232.xx.xx autorise le pod VPN à se déployer uniquement sur ce noeud worker. La valeur strongswan: vpn limite l'exécution du pod aux noeuds worker ayant ce libellé. Vous pouvez utiliser n'importe quel libellé de noeud worker. Pour autoriser l'utilisation de différents nœuds worker avec différents déploiements de graphique Helm, utilisez strongswan: <release_name>. Pour garantir la haute disponibilité, sélectionnez au moins deux noeuds worker.

   • Adresse IP publique du service strongSwan : pour établir la connexion à l'aide d'une adresse IP du service VPN strongSwan, définissez connectUsingLoadBalancerIP avec la valeur true. L'adresse IP du service strongSwan est une adresse IP publique portable que vous pouvez spécifier dans le paramètre loadBalancerIP ou une adresse IP publique portable disponible qui est automatiquement affectée au service.

     • Si vous optez pour la sélection d'une adresse IP à l'aide du paramètre loadBalancerIP, le cluster doit disposer d'au moins une adresse IP du service LoadBalancer public. Vous pouvez vérifier quelles sont vos adresses IP publiques disponibles ou libérer une adresse IP utilisée.
     • Tous les nœuds worker de cluster doivent être sur le même réseau local virtuel public. Sinon, vous devez utiliser le paramètre nodeSelector pour vous assurer que le pod VPN se déploie sur un noeud worker du même VLAN public que l'adresse IP loadBalancerIP.
     • Si connectUsingLoadBalancerIP est défini avec la valeur true et ipsec.keyexchange avec la valeur ikev1, vous devez définir enableServiceSourceIP avec la valeur true.

Etape 4 : Accédez aux ressources du cluster via la connexion VPN

Déterminez les ressources du cluster qui doivent être accessibles au réseau distant via la connexion VPN.

1. Ajoutez les routages CIDR d'un ou de plusieurs sous-réseaux du cluster dans le paramètre local.subnet. Vous devez configurer les CIDR des sous-réseaux locaux sur le point de terminaison VPN sur site. Cette liste peut inclure les sous-réseaux suivants.

   • CIDR de sous-réseau du pod Kubernetes : 172.30.0.0/16. La communication bidirectionnelle est activée entre les pods du cluster et un hôte figurant dans les sous-réseaux distants que vous avez répertoriés dans le paramètre remote.subnet. Si vous devez empêcher les hôtes remote.subnet d'accéder aux pods de cluster pour des raisons de sécurité, n'ajoutez pas le sous-réseau Kubernetes pod au paramètre local.subnet.
   • CIDR de sous-réseau du service Kubernetes : 172.21.0.0/16. Les adresses IP du service permettent d'exposer plusieurs pods d'application déployés sur plusieurs noeuds worker derrière une seule adresse IP.
   • Si vos applications sont exposées par un service NodePort sur le réseau privé ou sur un équilibreur de charge d'application (ALB) Ingress privé, ajoutez le CIDR de sous-réseau privé du noeud worker. Extrayez les trois premiers octets de l'adresse IP privée de votre worker en exécutant ibmcloud ks worker <cluster_name>. Par exemple, pour l'adresse IP 10.176.48.xx, notez 10.176.48. Ensuite, récupérez le sous-réseau de sous-réseau privé CIDR en exécutant la commande suivante, en remplaçant <xxx.yyy.zz> par l'octet que vous avez précédemment extrait : ibmcloud sl subnet list | grep <xxx.yyy.zzz>. Remarque : si un noeud worker est ajouté dans un nouveau sous-réseau privé, vous devez ajouter le CIDR de ce sous-réseau dans le paramètre local.subnet et le point de terminaison VPN sur site. Ensuite, la connexion VPN doit être relancée.
   • Si vous disposez d'applications exposées par des services LoadBalancer sur le réseau privé, ajoutez les CIDR des sous-réseaux privés gérés par l'utilisateur du cluster. Pour rechercher ces valeurs, exécutez ibmcloud ks cluster get --cluster <cluster_name> --show-resources. Dans la section VLANs, recherchez des CIDR avec la valeur ** pour **Publicfalse. Remarque : si ipsec.keyexchange est défini avec ikev1, vous ne pouvez indiquer qu'un seul sous-réseau. Vous pouvez toutefois utiliser le paramètre localSubnetNAT pour combiner plusieurs sous-réseaux de cluster dans un seul sous-réseau.

2. Facultatif : remappez les sous-réseaux du cluster en utilisant le paramètre localSubnetNAT. La conversion d'adresses réseau NAT pour les sous-réseaux fournit une solution de contournement en cas de conflit entre le réseau du cluster et le réseau distant sur site. Vous pouvez utiliser la conversion NAT pour remapper les sous-réseaux IP locaux privés du cluster, le sous-réseau du pod (172.30.0.0/16) ou le sous-réseau du service de pod (172.21.0.0/16) vers un autre sous-réseau privé. Le tunnel VPN voit les sous-réseaux IP remappés au lieu des sous-réseaux d'origine. Le remappage intervient avant l'envoi des paquets via le tunnel VPN et après l'arrivée des paquets en provenance du tunnel VPN. Vous pouvez exposer les sous-réseaux remappés et non remappés en même temps via le VPN. Pour activer la conversion NAT, vous pouvez ajouter un sous-réseau complet ou des adresses IP individuelles.

   • Si vous ajoutez un sous-réseau entier au format 10.171.42.0/24=10.10.10.0/24, le re-mappage est 1 sur 1 : toutes les adresses IP du sous-réseau du réseau interne sont mappées sur le sous-réseau du réseau externe et vice versa.
   • Si vous ajoutez des adresses IP individuelles au format 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32, seules ces adresses IP internes sont mappées aux adresses IP externes spécifiées.

3. Facultatif pour les graphiques Helm version 2.2.0 et versions ultérieures : masquez toutes les adresses IP de cluster derrière une seule adresse IP en définissant enableSingleSourceIP sur true. Cette option offre l'une des configurations les plus sécurisées pour la connexion VPN car aucune connexion de réseau distant revenant vers le cluster n'est autorisée.

   • Ce paramètre nécessite que tous les flux de données passant par la connexion VPN soient sortants quelle que soit la connexion VPN établie depuis le cluster ou le réseau distant.
   • Si vous installez strongSwan dans un cluster à zone unique, vous devez affecter au paramètre local.subnet une seule adresse IP en tant que sous-réseau /32. Si vous installez strongSwan dans un cluster multizone, vous pouvez affecter au paramètre local.subnet la variable %zoneSubnet et utiliser local.zoneSubnet pour spécifier une adresse IP en tant que sous-réseau /32 pour chacune des zones du cluster.

4. Facultatif pour les chartes Helm strongSwan à partir de la version 2.2.0 et versions ultérieures : activez le service strongSwan pour acheminer les demandes entrantes du réseau distant vers un service externe au cluster en utilisant le paramètre localNonClusterSubnet.

   • Le service externe au cluster doit exister sur le même réseau privé ou sur un réseau privé accessible aux noeuds worker.
   • Le noeud worker non-cluster ne peut pas initier le trafic au réseau distant via la connexion VPN, mais le noeud non-cluster peut être la cible des demandes entrantes provenant du réseau distant.
   • Vous devez répertorier les CIDR des sous-réseaux externes au cluster dans le paramètre local.subnet.

Etape 5 : Accédez aux ressources du réseau distant via la connexion VPN

Déterminez les ressources du réseau distant qui doivent être accessibles au cluster via la connexion VPN.

1. Ajoutez les routages CIDR d'un ou de plusieurs sous-réseaux privés sur site dans le paramètre remote.subnet. Remarque : si ipsec.keyexchange est défini avec ikev1, vous ne pouvez indiquer qu'un seul sous-réseau.
2. Facultatif pour les chartes Helm strongSwan à partir de la version 2.2.0 et versions ultérieures : remappez les sous-réseaux du réseau distant en utilisant le paramètre remoteSubnetNAT. La conversion d'adresses réseau NAT pour les sous-réseaux fournit une solution de contournement en cas de conflit entre le réseau du cluster et le réseau distant sur site. Vous pouvez utiliser la conversion NAT pour remapper les sous-réseaux IP du réseau distant à un sous-réseau privé différent. Le remappage intervient avant l'envoi des paquets via le tunnel VPN. Les pods dans le cluster voient les sous-réseaux IP remappés au lieu des sous-réseaux d'origine. Avant que le pod renvoie les données via le tunnel VPN, le sous-réseau IP remappé repasse au sous-réseau réel utilisé par le réseau distant. Vous pouvez exposer les sous-réseaux remappés et non remappés en même temps via le VPN.

Etape 6 (facultatif) : Activez la surveillance avec l'intégration du webhook Slack

Pour surveiller le statut du VPN strongSwan, vous pouvez configurer un webhook pour publier automatiquement des messages de connectivité VPN sur un canal Slack.

1. Connectez-vous à votre espace de travail Slack.

2. Allez sur la page de l'application Incoming WebHooks.

3. Cliquez sur Request to Install. Si cette application n'est pas répertoriée dans votre configuration Slack, contactez le propriétaire de votre espace de travail Slack.

4. Une fois votre demande d'installation approuvée, cliquez sur Add Configuration.

5. Choisissez un canal Slack ou créez un nouveau canal auquel envoyer les messages VPN.

6. Copiez l'URL du webhook qui a été générée. Le format de l'URL ressemble à ceci :

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

7. Pour vérifier que le webhook Slack est installé, envoyez un message de test à l'URL de votre webhook en exécutant la commande suivante :

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

8. Accédez au canal Slack que vous avez choisi pour vérifier que le message de test est bien passé.

9. Dans le fichier config.yaml correspondant à la charte Helm, configurez le webhook pour surveiller votre connexion VPN.

   1. Remplacez monitoring.enable par true.
   2. Ajoutez les adresses IP privées ou les noeuds finaux HTTP dans le sous-réseau distant que vous souhaitez accessible via une connexion VPN dans les zones monitoring.privateIPs ou monitoring.httpEndpoints. Par exemple, vous pouvez ajouter l'adresse IP du paramètre remote.privateIPtoPing dans monitoring.privateIPs.
   3. Ajoutez l'URL du webhook dans monitoring.slackWebhook.
   4. Modifiez éventuellement d'autres paramètres de surveillance monitoring selon les besoins.

Etape 7 : Déployez la charte Helm

Déployez la charte Helm strongSwan dans votre cluster avec les configurations que vous avez choisies précédemment.

1. Si vous devez configurer d'autres paramètres avancés, suivez la documentation fournie pour chaque paramètre dans la charte Helm.

2. Enregistrez le fichier config.yaml mis à jour.

3. Installez la charte Helm dans votre cluster avec le fichier config.yaml mis à jour.

   Si vous avez plusieurs déploiements VPN dans un seul cluster, vous pouvez éviter les conflits de noms et effectuer la distinction entre différents déploiements en choisissant des noms d'édition plus descriptifs que vpn. Pour éviter que le nom d'édition soit tronqué, limitez-le à 35 caractères ou moins.

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

4. Vérifiez le statut de déploiement de la charte. Lorsque le graphique est prêt, le champ STATUS proche de la sortie a une valeur de DEPLOYED.

   helm status vpn
   

5. Une fois la charte déployée, vérifiez que les paramètres mis à jour dans le fichier config.yaml ont bien été utilisés.

   helm get values vpn
   

Seules les versions de charte Helm strongSwan qui ont été publiées au cours des 6 derniers mois sont prises en charge. Prenez soin de mettre à niveau votre charte Helm strongSwan de façon régulière afin d'obtenir les fonctionnalités et les correctifs de sécurité les plus récents.

Limitation du trafic VPN strongSwan par espace de noms

Si vous disposez d'un cluster à service exclusif ou à service partagé, vous pouvez limiter le trafic VPN aux pods de certains espaces de noms uniquement.

Par exemple, admettons que vous souhaitiez des pods uniquement dans un espace de noms spécifique nommé my-secure-namespace pour envoyer et recevoir des données via le réseau privé virtuel (VPN). Vous ne voulez pas de pods dans d'autres espaces de nom, tels que kube-system, ibm-systemou default, pour accéder à votre réseau sur site. Pour limiter le trafic VPN uniquement à l'espace de noms my-secure-namespace, vous pouvez créer des règles réseau globales Calico.

Avant d'utiliser cette solution, consultez les remarques et limitations suivantes.

• Vous n'avez pas besoin de déployer le graphique strongSwan Helm dans l'espace de nom spécifique. Le pod VPN strongSwan et l'ensemble de démons (daemonSet) routes peuvent être déployés dans kube-system ou n'importe quel autre espace de noms. Si le VPN strongSwan n'est pas déployé dans l'espace de noms spécifié, le test Helm vpn-strongswan-ping-remote-ip-1 échoue. Cet échec est prévisible et acceptable. Le test envoie une commande ping à l'adresse IP privée remote.privateIPtoPing de la passerelle VPN sur site depuis un pod qui ne figure pas dans l'espace de noms ayant un accès direct au sous-réseau distant. Cependant, le pod VPN est toujours capable d'acheminer le trafic vers les pods dans les espaces de noms qui n'ont pas de routes vers le sous-réseau distant et le trafic peut encore circuler correctement. Le VPN est toujours à l'état ESTABLISHED et les pods dans l'espace de noms spécifié peuvent se connecter via le VPN.

• Les règles de réseau global Calico dans les étapes suivantes n'empêchent pas les pods Kubernetes qui utilisent le réseau hôte d'envoyer et de recevoir des données sur le réseau privé virtuel. Lorsqu'un pod est configuré avec un réseau d'hôte, l'application qui s'exécute dans le pod peut être en mode écoute sur les interfaces réseau du noeud worker sur lequel elle se trouve. Ces pods de réseau d'hôte peuvent exister dans n'importe quel espace de noms. Pour déterminer les pods qui possèdent un réseau hôte, exécutez kubectl get pods --all-namespaces -o wide et recherchez les pods qui n'ont pas d'adresse IP 172.30.0.0/16 pod. Si vous souhaitez empêcher les pods de réseau d'hôte d'envoyer et de recevoir des données via le VPN, vous pouvez définir les options suivantes dans votre fichier de déploiement values.yaml : local.subnet: 172.30.0.0/16 et enablePodSNAT: false. Ces paramètres de configuration exposent tous les pods Kubernetes sur la connexion VPN au réseau distant. Cependant, seuls les pods situés dans l'espace de noms sécurisé indiqué sont accessibles via le VPN.

Avant de commencer

• Déployez la charte Helm strongSwan et vérifiez que la connectivité VPN fonctionne correctement.
• Installez et configurez l'interface de ligne de commande de Calico.

Pour limiter le trafic VPN à un espace de noms spécifique,

1. Créez une règle réseau globale Calico nommée allow-non-vpn-outbound.yaml. Cette règle autorise tous les espaces de noms à continuer à envoyer du trafic sortant à toutes les destinations, sauf au sous-réseau distant auquel accède le VPN strongSwan. Remplacez <remote.subnet> par le remote.subnet que vous avez spécifié dans le fichier de configuration Helmvalues.yaml. Pour spécifier plusieurs sous-réseaux distants, voir la documentation de 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. Appliquez la politique.

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

3. Créez une autre règle réseau globale Calico nommée allow-vpn-from-namespace.yaml. Cette règle n'autorise qu'un espace de noms spécifié à envoyer du trafic sortant au sous-réseau distant auquel accède le VPN strongSwan. Remplacez <namespace> par l'espace de nom qui peut accéder au réseau privé virtuel et à <remote.subnet> avec le remote.subnet que vous avez spécifié dans le fichier de configuration Helm values.yaml. Pour spécifier plusieurs espaces de noms ou sous-réseaux distants, voir la documentation de 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. Appliquez la politique.

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

5. Vérifiez que les règles réseau globales ont bien été créées dans votre cluster.

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

Limitation du trafic VPN strongSwan par noeud worker

Lorsque vous disposez de plusieurs déploiements de VPN strongSwan dans un cluster à service partagé, vous pouvez limiter le trafic VPN de chaque déploiement à des noeuds worker spécifiques dédiés à chaque locataire.

Lorsque vous déployez une charte Helm strongSwan, un déploiement de VPN strongSwan est créé. Les pods du VPN strongSwan sont déployés sur n'importe quel noeud worker auquel aucune tache n'est appliquée. En outre, un ensemble de démons (daemonSet) Kubernetes est créé. Cet ensemble de démons configure automatiquement des routes sur tous les noeuds worker auxquels aucune tache n'est appliquée dans le cluster sur chaque sous-réseau distant. Le pod VPN strongSwan utilise les routes sur les noeuds worker pour transférer les demandes au sous-réseau distant dans le réseau sur site.

Les routes ne sont pas configurées sur des noeuds auxquels une tache est appliquée sauf si vous spécifiez la tache dans le paramètre tolerations dans le fichier value.yaml. En appliquant une tache aux noeuds worker, vous pouvez empêcher la configuration de routes VPN sur ces noeuds worker. Vous pouvez ensuite indiquer la tache dans le paramètre tolerations uniquement pour le déploiement VPN que vous voulez autoriser sur les noeuds worker auxquels une tache est appliquée. Ainsi, les pods VPN strongSwan d'un déploiement de charte Helm pour un locataire utilisent uniquement les routes sur les noeuds worker de ce locataire pour transférer le trafic via la connexion VPN au sous-réseau distant.

Avant d'utiliser cette solution, consultez les remarques et limitations suivantes.

• Par défaut, Kubernetes met des pods d'application sur tout noeud worker disponible auquel aucune tache n'est appliquée. Pour s'assurer que cette solution fonctionne correctement, chaque locataire doit d'abord vérifier que ses pods sont déployés uniquement sur des noeuds worker auxquels une tache est appliquée pour le locataire approprié. De plus, chaque noeud worker auquel une tache est appliquée doit également disposer d'une tolérance pour autoriser la mise en place des pods d'application sur le noeud. Pour plus d'informations sur les taches et les tolérances, voir la documentation Kubernetes.
• Les ressources de cluster ne sont pas forcément utilisées de manière optimale car aucun locataire ne peut mettre de pods d'application sur les noeuds partagés auxquels aucune tache n'est appliquée.

La procédure suivante utilisée pour limiter le trafic VPN strongSwan par noeud worker, utilise cet exemple de scénario : admettons que vous disposez d'un cluster IBM Cloud Kubernetes Service à service partagé doté de six noeuds worker. Le cluster prend en charge le locataire A et le locataire B. Vous avez tacher les nœuds worker de la manière suivante.

• Une tache est appliquée à deux noeuds worker de sorte que seuls les pods du locataire tenantA soient planifiés sur les noeuds worker.
• Une tache est appliquée à deux noeuds worker de sorte que seuls les pods du locataire tenantB soient planifiés sur les noeuds worker.
• Aucune tache n'est appliquée à deux noeuds worker car au moins 2 noeuds worker sont nécessaires pour l'exécution des pods VPN strongSwan et de l'adresse IP de l'équilibreur de charge.

Pour limiter le trafic VPN aux noeuds auxquels une tache est appliquée pour chaque locataire :

1. Pour limiter le trafic VPN aux noeuds worker dédiés au locataire tenantA dans cet exemple, vous indiquez les paramètres toleration suivants dans le fichier values.yaml de la charte Helm strongSwan du locataire tenantA :

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

   Cette tolérance autorise le démon route à s'exécuter sur les deux noeuds worker auxquels la tache dedicated="tenantA" est appliquée et sur les deux noeuds worker auxquels aucune tache n'est appliquée. Dans le cadre de ce déploiement, les pods VPN strongSwan s'exécutent sur les deux noeuds worker auxquels aucune tache n'est appliquée.

2. Pour limiter le trafic VPN uniquement aux noeuds worker dédiés au locataire tenantB dans cet exemple, vous indiquez le paramètre toleration suivant dans le fichier values.yaml de la charte Helm strongSwan du locataire tenantB :

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

   Cette tolérance autorise le démon route à s'exécuter sur les deux noeuds worker auxquels la tache dedicated="tenantB" est appliquée et sur les deux noeuds worker auxquels aucune tache n'est appliquée. Dans le cadre de ce déploiement, les pods VPN strongSwan s'exécutent également sur les deux noeuds worker auxquels aucune tache n'est appliquée.