Configuración de una sola conexión VPN de salida desde un clúster multizona

La solución más sencilla para configurar el servicio VPN de strongSwan en un clúster multizona consiste en utilizar una única conexión VPN de salida que flote entre distintos nodos trabajadores en todas las zonas de disponibilidad del clúster.

Cuando la conexión VPN es de salida del clúster multizona, solo se necesita un despliegue de strongSwan. Si se elimina un nodo trabajador o se experimenta un tiempo de inactividad, kubelet vuelve a planificar el pod de VPN en un nuevo nodo trabajador. Si una zona de disponibilidad experimenta una interrupción, kubelet vuelve a planificar el pod de VPN en un nuevo nodo trabajador en otra zona.

1. Configurar un diagrama de Helm de VPN de strongSwan. Cuando realice los pasos de esa sección, asegúrese de que especifica los valores siguientes.

   • ipsec.auto: Cambie su valor por start. Las conexiones son de salida del clúster.
   • loadBalancerIP: No especifique una dirección IP. Deje este valor en blanco.
   • zoneLoadBalancer: Especifique una dirección IP pública de equilibrador de carga para cada zona en la que tenga nodos trabajadores. Puede comprobar las direcciones IP públicas disponibles o liberar una dirección IP usada. Puesto que el pod de VPN de strongSwan se puede planificar en un nodo trabajador de cualquier zona, la lista de las IP garantiza que se puede utilizar una IP del equilibrador de carga en cualquier zona en la que se haya planificado el pod de VPN.
   • connectUsingLoadBalancerIP: Establezca su valor en true. Cuando el pod de VPN de strongSwan se planifica en un nodo trabajador, el servicio strongSwan selecciona la dirección IP del equilibrador de carga que se encuentra en la misma zona y utiliza esta dirección IP para establecer la conexión de salida.
   • local.id: Especifique un valor fijo que reciba soporte del punto final de VPN remota. Si el punto final de VPN remoto requiere que establezca la opción local.id (valorleftid en ipsec.conf) en la dirección IP pública del túnel de VPN IPSec, establezca local.id en %loadBalancerIP. Este valor configura automáticamente el valor leftid en ipsec.conf en la dirección IP del equilibrador de carga que se utiliza para la conexión.
   • Opcional: oculte todas las direcciones IP de clúster tras una única dirección IP en cada zona estableciendo enableSingleSourceIP en true. Esta opción proporciona una de las configuraciones más seguras para la conexión VPN porque no se permiten conexiones entre la red remota y el clúster. También debe establecer local.subnet en la variable %zoneSubnet y utilizar local.zoneSubnet para especificar una dirección IP como una subred /32 para cada zona del clúster.

2. En el cortafuegos de red remota, permita las conexiones VPN entrantes de IPSec desde las direcciones IP públicas que aparecen en la lista del valor zoneLoadBalancer.

3. Configure el punto final de VPN remota de modo que permita una conexión de VPN entrante desde cada una de las posibles IP del equilibrador de carga que aparecen en la lista del valor zoneLoadBalancer.

Configuración de una sola conexión VPN de entrada a un clúster multizona

Cuando necesite conexiones VPN entrantes y el punto final de VPN remota puede volver a establecer automáticamente la conexión VPN con otra IP cuando se detecta una anomalía, puede utilizar una única conexión VPN de entrada que flote entre distintos nodos trabajadores en todas las zonas de disponibilidad del clúster.

El punto final de VPN remota puede establecer la conexión VPN con cualquiera de los equilibradores de carga de strongSwan en cualquiera de las zonas. La solicitud de entrada se envía al pod de VPN independientemente de la zona en la que se encuentre el pod de VPN. Las respuestas procedentes del pod de VPN se envían de nuevo a través del equilibrador de carga original al punto final de VPN remota. Esta opción garantiza una alta disponibilidad debido a que kubelet vuelve a planificar el pod de VPN en un nuevo nodo trabajador si se elimina un nodo trabajador o si se experimenta un tiempo de inactividad. Además, si una zona de disponibilidad experimenta una interrupción, el punto final de VPN remota puede volver a establecer la conexión VPN con la dirección IP del equilibrador de carga de otra zona para que se pueda acceder al pod de VPN.

1. Configurar un diagrama de Helm de VPN de strongSwan. Cuando realice los pasos de esa sección, asegúrese de que especifica los valores siguientes.

   • ipsec.auto: Cambie su valor por add. Las conexiones son de entrada en el clúster.
   • loadBalancerIP: No especifique una dirección IP. Deje este valor en blanco.
   • zoneLoadBalancer: Especifique una dirección IP pública de equilibrador de carga para cada zona en la que tenga nodos trabajadores. Puede comprobar las direcciones IP públicas disponibles o liberar una dirección IP usada.
   • local.id: Si el punto final de VPN remoto requiere que establezca la opción local.id (valor leftid en ipsec.conf) en la dirección IP pública del túnel de VPN IPSec, establezca local.id en %loadBalancerIP. Este valor configura automáticamente el valor leftid en ipsec.conf en la dirección IP del equilibrador de carga que se utiliza para la conexión.

2. En el cortafuegos de red remota, permita las conexiones VPN de salida de IPSec a las direcciones IP públicas que aparecen en la lista del valor zoneLoadBalancer.

Configuración de una conexión VPN de entrada en cada zona de un clúster multizona

Si necesita conexiones VPN entrantes y el punto final de VPN remoto no puede volver a establecer la conexión VPN en otra IP, debe desplegar un servicio VPN strongSwan por separado en cada zona.

El punto final de VPN remota se debe actualizar para que establezca una conexión VPN independiente con un equilibrador de carga en cada una de las zonas. Además, debe configurar valores específicos de zona en el punto final de VPN remota para que cada una de estas conexiones VPN sea exclusiva. Asegúrese de que estas diversas conexiones VPN de entrada permanezcan activas.

Después de desplegar cada diagrama de Helm, cada despliegue de VPN de strongSwan se inicia como un servicio de equilibrador de carga de Kubernetes en la zona correcta. Las solicitudes de entrada a dicha IP pública se reenvían al pod de VPN que también está asignado a la misma zona. Si la zona experimenta una interrupción, las conexiones VPN que se establecen en las otras zonas no se ven afectadas.

1. Configure un diagrama de Helm de VPN de strongSwan para cada zona. Cuando siga los pasos de dicha sección, asegúrese de especificar los valores siguientes:

   • loadBalancerIP: Especifique una dirección IP pública disponible de equilibrador de carga que esté en la zona en la que despliega este servicio strongSwan. Puede comprobar las direcciones IP públicas disponibles o liberar una dirección IP usada.
   • zoneSelector: Especifique la zona en la que desea planificar el pod de VPN.
   • Es posible que se necesiten valores adicionales, como por ejemplo zoneSpecificRoutes, remoteSubnetNAT, localSubnetNAT o enableSingleSourceIP, en función de los recursos a los que se debe acceder a través de la VPN. Consulte el paso siguiente si desea información más detallada.

2. Configure valores específicos de zona en ambos lados del túnel de VPN para asegurarse de que cada conexión VPN sea exclusiva. En función de los recursos a los que se debe acceder a través de la VPN, tiene dos opciones para conseguir que las conexiones se puedan distinguir:

   • Si los pods del clúster deben acceder a servicios en la red local remota,
     • zoneSpecificRoutes: Establezca su valor en true. Esta configuración restringe la conexión VPN a una única región de zona del clúster. Los pods de una zona específica solo utilizan la conexión VPN que se ha configurado para dicha zona específica. Esta solución reduce el número de pods de strongSwan que se necesitan para dar soporte a varias VPN en un clúster multizona, mejora el rendimiento de VPN porque el tráfico de VPN solo fluye a los nodos trabajadores ubicados en la zona actual y garantiza que la conectividad VPN para cada zona no se vea afectada por la conectividad VPN, la interrupción de pods o las detenciones de zona de otras zonas. Tenga en cuenta que no hace falta configurar remoteSubnetNAT. Varias VPN que utilicen el valor zoneSpecificRoutes pueden tener el mismo valor de remote.subnet porque el direccionamiento se configura por zona.
     • enableSingleSourceIP: Establezca este valor en true y establezca el valor de local.subnet en una única dirección IP /32. Esta combinación de valores oculta todas las direcciones IP privadas del clúster tras una única dirección IP /32. Esta dirección IP /32 exclusiva permite a la red local remota devolver respuestas sobre la conexión VPN correcta al pod correcto en el clúster que ha iniciado la solicitud. Tenga en cuenta que la única dirección IP /32 que se configura para la opción local.subnet debe ser exclusiva en cada configuración de VPN de strongSwan.
   • Si las aplicaciones de la red local remota deben acceder a servicios del clúster,
     • localSubnetNAT: Asegúrese de que una aplicación de la red remota local pueda seleccionar una conexión VPN específica a la que enviar y de la que recibir tráfico del clúster. En cada configuración de Helm de strongSwan, utilice localSubnetNAT para identificar de forma exclusiva los recursos del clúster a los que puede acceder la aplicación local remota. Dado que se establecen varias VPN desde la red local remota al clúster, debe añadir lógica a la aplicación en la red local para que pueda seleccionar qué VPN se utiliza cuando accede a los servicios del clúster. Tenga en cuenta que se puede acceder a los servicios del clúster a través de varias subredes distintas en función de lo que haya configurado para localSubnetNAT en cada configuración de VPN de strongSwan.
     • remoteSubnetNAT: Asegúrese de que un pod del clúster utilice la misma conexión VPN para devolver el tráfico a la red remota. En cada archivo de despliegue strongSwan, correlacione la subred local remota con una subred exclusiva mediante el valor remoteSubnetNAT. El tráfico que recibe un pod del clúster desde un remoteSubnetNAT específico de VPN se vuelve a enviar a ese mismo remoteSubnetNAT específico de VPN y se transmite a través de esa misma conexión VPN.
   • Si los pods del clúster deben acceder a los servicios de la red local remota y las aplicaciones de la red local remota deben acceder a los servicios del clúster, configure los valores localSubnetNAT y remoteSubnetNAT listados en el segundo punto. Tenga en cuenta que si un pod del clúster inicia una solicitud a la red local remota, debe añadir lógica al pod para que pueda seleccionar qué conexión VPN utilizar para acceder a los servicios en la red local remota.

3. Configure el software de punto final de VPN remota de modo que establezca una conexión VPN independiente con la IP del equilibrador de carga en cada zona.

Paso 1: Obtenga el diagrama de Helm strongSwan

Instale Helm y obtenga el diagrama de Helm strongSwan para ver las posibles configuraciones.

1. Siga las instrucciones para instalar el cliente Helm versión 3 en la máquina local.

2. Guarde los valores de configuración predeterminados para el diagrama de Helm de strongSwan en un archivo YAML local.

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

3. Abra el archivo config.yaml.

Paso 2: Configure los valores básicos de IPSec

Para controlar el establecimiento de la conexión VPN, modifique los siguientes valores básicos de IPSec.

Para obtener más información sobre cada valor, lea la documentación que se proporciona en el archivo config.yaml para el diagrama de Helm.

1. Si el punto final de túnel VPN local no admite ikev2 como protocolo para inicializar la conexión, cambie el valor de ipsec.keyexchange por ikev1.
2. Establezca ipsec.esp como una lista de algoritmos de autenticación y cifrado de ESP que el punto final de túnel de VPN local utiliza para la conexión.
   • Si ipsec.keyexchange se establece en ikev1, se debe especificar este valor.
   • Si ipsec.keyexchange se establece en ikev2, este valor es opcional.
   • Si deja este valor en blanco, se utilizan para la conexión los algoritmos predeterminados de strongSwan aes128-sha1,3des-sha1.
3. Establezca ipsec.ike como una lista de algoritmos de autenticación y cifrado de IKE/ISAKMP que el punto final de túnel de VPN local utiliza para la conexión. Los algoritmos deben ser específicos en el formato encryption-integrity[-prf]-dhgroup.
   • Si ipsec.keyexchange se establece en ikev1, se debe especificar este valor.
   • Si ipsec.keyexchange se establece en ikev2, este valor es opcional.
   • Si deja este valor en blanco, se utilizan para la conexión los algoritmos predeterminados de strongSwan aes128-sha1-modp2048,3des-sha1-modp1536.
4. Cambie el valor de local.id por la serie que desee utilizar para identificar el lado del clúster de Kubernetes local que utiliza el punto final de túnel VPN. El valor predeterminado es ibm-cloud. Algunas implementaciones de VPN requieren que utilice la dirección IP pública para el punto final local.
5. Cambie el valor de remote.id por la serie que desee utilizar para identificar el lado local remoto que utiliza el punto final de túnel VPN. El valor predeterminado es on-prem. Algunas implementaciones de VPN requieren que utilice la dirección IP pública para el punto final remoto.
6. Cambie el valor de preshared.secret por el secreto precompartido que la pasarela de punto final de túnel VPN local utiliza para la conexión. Este valor se almacena en ipsec.secrets.
7. Opcional: establezca remote.privateIPtoPing en cualquier dirección IP privada de la subred remota para ejecutar ping como parte de la prueba de validación de conectividad de Helm.

Paso 3: Seleccione una conexión VPN de entrada o de salida

Cuando configure una conexión VPN de strongSwan, debe elegir si la conexión VPN es de entrada al clúster o de salida del clúster.

Entrada

El punto final VPN local de la red remota inicia la conexión VPN y el clúster escucha la conexión.

De salida

El clúster inicia la conexión VPN y el punto final VPN local de la red remota escucha la conexión.

Para establecer una conexión VPN de entrada, modifique los valores siguientes.

1. Verifique que ipsec.auto esté establecido en add.
2. Opcional: establezca loadBalancerIP en una dirección IP pública portátil para el servicio VPN de strongSwan. Especificar una dirección IP es útil cuando necesita una dirección IP estable como, por ejemplo, cuando debe designar las direcciones IP permitidas a través de un cortafuegos local. El clúster debe tener disponible al menos una dirección IP pública de equilibrador de carga. Puede comprobar las direcciones IP públicas disponibles o liberar una dirección IP usada.
   • Si deja este valor en blanco, se utilizará una de las direcciones IP públicas portátiles disponibles.
   • También debe configurar la dirección IP pública que seleccione o la dirección IP pública que se asigna al punto final de VPN del clúster en el punto final VPN local.

Para establecer una conexión VPN de salida, modifique los valores siguientes.

1. Cambie ipsec.auto por start.
2. Establezca remote.gateway en la dirección IP pública para el punto final VPN local en la red remota.
3. Elija una de las opciones siguientes para la dirección IP para el punto final VPN del clúster:

   • Dirección IP pública de la pasarela privada del clúster: Si los nodos de sus trabajadores están conectados únicamente a una VLAN privada, la solicitud de VPN saliente se enruta a través de la puerta de enlace privada para llegar a Internet. La dirección IP pública de la pasarela privada se utiliza para la conexión VPN.

   • Dirección IP pública del nodo trabajador en el que se ejecuta el pod strongSwan: si el nodo trabajador en el que se ejecuta el pod strongSwan está conectado a una VLAN pública, se utiliza la dirección IP pública del nodo trabajador para la conexión VPN.

     • Si el pod strongSwan se suprime y se vuelve a planificar en otro nodo trabajador del clúster, la dirección IP pública de VPN cambia. El punto final VPN local de la red remota debe permitir que se establezca la conexión VPN a partir de la dirección IP pública de cualquiera de los nodos trabajadores del clúster.
     • Si el punto final de VPN remoto no puede manejar conexiones VPN procedentes de varias direcciones IP públicas, limite los nodos en los que se despliega el pod de VPN strongSwan. Establezca nodeSelector en las direcciones IP de nodos trabajadores específicos o en una etiqueta de nodo trabajador. Por ejemplo, el valor kubernetes.io/hostname: 10.232.xx.xx permite que el pod de VPN se despliegue únicamente en ese nodo trabajador. El valor strongswan: vpn restringe la ejecución del pod de VPN a los nodos trabajadores que tengan esa etiqueta. Puede utilizar cualquier etiqueta de nodo trabajador. Para permitir que se utilicen distintos nodos de trabajador con distintos despliegues de diagrama de helm, utilice strongswan: <release_name>. Para obtener una alta disponibilidad, seleccione al menos dos nodos trabajadores.

   • Dirección IP pública del servicio strongSwan: para establecer la conexión utilizando la dirección IP del servicio VPN strongSwan, establezca connectUsingLoadBalancerIP en true. La dirección IP del servicio strongSwan es una dirección IP pública portátil que puede especificar en el valor loadBalancerIP o bien una dirección IP pública portátil disponible que se asigna automáticamente al servicio.

     • Si elige seleccionar una dirección IP mediante el valor loadBalancerIP, el clúster debe tener al menos una dirección IP pública de equilibrador de carga disponible. Puede comprobar las direcciones IP públicas disponibles o liberar una dirección IP usada.
     • Todos los nodos de trabajador de clúster deben estar en la misma VLAN pública. De lo contrario, debe utilizar el valor nodeSelector para asegurarse de que el pod de VPN se despliega en un nodo trabajador en la misma VLAN pública que loadBalancerIP.
     • Si connectUsingLoadBalancerIP tiene el valor true e ipsec.keyexchange tiene el valor ikev1, debe establecer para enableServiceSourceIP el valor true.

Paso 4: Acceda a recursos de clúster a través de la conexión VPN

Determinar los recursos de clúster a los que debe poder acceder la red remota a través de la conexión VPN.

1. Añada los CIDR de una o varias subredes del clúster a la configuración local.subnet. Debe configurar los CIDR de subred locales en el punto final VPN local. Esta lista puede incluir las subredes siguientes.

   • El CIDR de subred del pod de Kubernetes: 172.30.0.0/16. La comunicación bidireccional está habilitada entre todos los pods del clúster y cualquiera de los hosts de las subredes de red remotas que se muestran en el valor remote.subnet. Si debe impedir que algún host de remote.subnet acceda a los pods de clúster por motivos de seguridad, no añada la subred de pod de Kubernetes al valor local.subnet.
   • El CIDR de subred del servicio de Kubernetes: 172.21.0.0/16. Las direcciones IP de servicio proporcionan una forma de exponer varios pods de app que se despliegan en varios nodos trabajadores detrás de una única IP.
   • Si las apps están expuestas por un servicio NodePort en una red privada en un Ingress ALB privado, añada el CIDR de subred privada del nodo trabajador. Recupere los tres primeros octetos de la dirección IP privada del trabajador ejecutando ibmcloud ks worker <cluster_name>. Por ejemplo, si es 10.176.48.xx, anote 10.176.48. A continuación, obtenga el CIDR de subred privada de trabajador ejecutando el mandato siguiente, sustituyendo <xxx.yyy.zz> por el octeto que ha recuperado anteriormente: ibmcloud sl subnet list | grep <xxx.yyy.zzz>. Nota: si se añade un nodo trabajador en una nueva subred privada, debe añadir el nuevo CIDR de subred privada al valor local.subnet y al punto final VPN local. Luego se debe reiniciar la conexión VPN.
   • Si tiene apps expuestas por los servicios de LoadBalancer en la red privada, añada el CIDR de subred privada gestionada por el usuario del clúster. Para encontrar estos valores, ejecute ibmcloud ks cluster get --cluster <cluster_name> --show-resources. En la sección VLAN, busque los CIDR que tengan los valores Public o false. Nota: Si ipsec.keyexchange se establece en ikev1, solo puede especificar una subred. Sin embargo, puede utilizar el valor localSubnetNAT para combinar varias subredes de clúster en una única subred.

2. Opcional: vuelva a correlacionar las subredes del clúster utilizando el valor localSubnetNAT. NAT (conversión de direcciones de red) para subredes supone una solución temporal para los conflictos de subred entre la red del clúster y la red remota local. Puede utilizar NAT para volver a correlacionar las subredes IP locales privadas del clúster, la subred del pod (172.30.0.0/16) o la subred del servicio del pod (172.21.0.0/16) a una subred privada diferente. El túnel VPN ve subredes IP correlacionadas en lugar de las subredes originales. La correlación ocurre antes de que los paquetes se envíen a través del túnel VPN, así como después de que lleguen del túnel VPN. Puede exponer las redes correlacionadas y las no correlacionadas al mismo tiempo a través de la VPN. Para habilitar NAT, puede añadir una subred entera o direcciones IP individuales.

   • Si añade una subred completa en el formato 10.171.42.0/24=10.10.10.0/24, la correlación es de 1 a 1: todas las direcciones IP de la subred de red interna se correlacionan con la subred de red externa, y viceversa.
   • Si añade direcciones IP individuales en el formato 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32, solo estas direcciones IP internas se correlacionan con las direcciones IP externas especificadas.

3. Opcional para diagramas de Helm strongSwan de la versión 2.2.0 y posteriores: oculte todas las direcciones IP del clúster tras una única dirección IP estableciendo enableSingleSourceIP en true. Esta opción proporciona una de las configuraciones más seguras para la conexión VPN porque no se permiten conexiones entre la red remota y el clúster.

   • Este valor requiere que todo el flujo de datos a través de la conexión VPN sea de salida, independientemente de si la conexión VPN se establece desde el clúster o desde la red remota.
   • Si instala strongSwan en un clúster de una sola zona, debe establecer local.subnet en una sola dirección IP como una subred /32. Si instala strongSwan en un clúster multizona, puede establecer local.subnet en la variable %zoneSubnet y utilizar local.zoneSubnet para especificar una dirección IP como una subred /32 para cada zona del clúster.

4. Opcional para diagramas de Helm strongSwan de versión 2.2.0 y posteriores: habilite el servicio strongSwan para direccionar las solicitudes de entrada procedentes de la red remota a un servicio que exista fuera del clúster utilizando el valor localNonClusterSubnet.

   • El servicio que no es de clúster debe existir en la misma red privada o en una red privada a la que puedan acceder los nodos trabajadores.
   • El nodo de trabajador que no es de clúster no puede iniciar el tráfico a la red remota a través de la conexión VPN, pero el nodo que no es de clúster puede ser el destino de las solicitudes entrantes de la red remota.
   • Debe obtener una lista de los CIDR de las subredes que no son de clúster en el valor local.subnet.

Paso 5: Acceda a recursos de red remotos a través de la conexión VPN

Determine los recursos de red remotos a los que debe poder acceder el clúster a través de la conexión VPN.

1. Añada los CIDR de una o varias subredes privadas locales al valor remote.subnet. Nota: Si ipsec.keyexchange se establece en ikev1, solo puede especificar una subred.
2. Opcional para los diagramas de Helm strongSwan de la versión 2.2.0 y posteriores: vuelva a correlacionar las subredes de red remota utilizando el valor remoteSubnetNAT. NAT (conversión de direcciones de red) para subredes supone una solución temporal para los conflictos de subred entre la red del clúster y la red remota local. Puede utilizar NAT para volver a correlacionar las subredes IP remotas con otra subred privada. La correlación ocurre antes de que los paquetes se envíen a través del túnel VPN. Los pods del clúster ven las subredes IP correlacionadas en lugar de las subredes originales. Antes de que los pods envíen de nuevo los datos a través del túnel de VPN, la subred IP que se ha vuelto a correlacionar se cambia de nuevo a la subred real que está utilizando la red remota. Puede exponer las redes correlacionadas y las no correlacionadas al mismo tiempo a través de la VPN.

Paso 6 (opcional): Habilite la supervisión con la integración del webhook de Slack

Para supervisar el estado de la VPN de strongSwan, puede configurar un webhook para publicar automáticamente mensajes de conectividad de VPN en un canal de Slack.

1. Inicie sesión en el espacio de trabajo de Slack.

2. Vaya a la página de la aplicación Incoming WebHooks.

3. Pulse Solicitud de instalación. Si esta app no aparece en la configuración de Slack, póngase en contacto con el propietario del espacio de trabajo de Slack.

4. Una vez que se haya aprobado la solicitud e instalación, pulse Añadir configuración.

5. Elija un canal de Slack o cree un canal nuevo al que enviar los mensajes de VPN.

6. Copie del URL de webhook que se genera. El formato de URL tiene un aspecto similar al siguiente:

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

7. Para verificar que el webhook de Slack está instalado, envíe un mensaje de prueba al URL de webhook ejecutando el mandato siguiente:

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

8. Vaya al canal de Slack que haya elegido para verificar que el mensaje de prueba se envía correctamente.

9. En el archivo config.yaml del diagrama de Helm, configure el webhook para supervisar su conexión VPN.

   1. Cambie monitoring.enable por true.
   2. Añada las direcciones IP privadas o puntos finales HTTP de la subred remota a monitoring.privateIPs o monitoring.httpEndpoints, para los cuales desea asegurarse de que sean accesibles a través de la conexión VPN. Por ejemplo, puede añadir la IP del valor remote.privateIPtoPing a monitoring.privateIPs.
   3. Añada el URL de webhook a monitoring.slackWebhook.
   4. Cambie los demás valores de monitoring opcionales según sea necesario.

Paso 7: Despliegue el diagrama de Helm

Despliegue el diagrama de Helm strongSwan en el clúster con las configuraciones que ha elegido anteriormente.

1. Si necesita configurar valores más avanzados, siga la documentación que se proporciona para cada valor en el diagrama de Helm.

2. Guarde el archivo config.yaml actualizado.

3. Instale el diagrama de Helm en el clúster con el archivo config.yaml actualizado.

   Si tiene varios despliegues de VPN en un solo clúster, puede evitar conflictos de denominación y diferenciar entre los despliegues eligiendo nombres de release más descriptivos que vpn. Para evitar el truncamiento del nombre de release, limite el nombre de release a 35 caracteres o menos.

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

4. Compruebe el estado de despliegue del diagrama. Cuando el gráfico está listo, el campo ESTADO cerca en la salida tiene un valor de DEPLOYED.

   helm status vpn
   

5. Una vez que se haya desplegado el diagrama, verifique que se hayan utilizado los valores actualizados del archivo config.yaml.

   helm get values vpn
   

Solo se admiten las versiones del diagrama de Helm strongSwan que se han publicado en los últimos 6 meses. Asegúrese de actualizar el diagrama de Helm de strongSwan consecuentemente para ver las características más recientes y los arreglos de seguridad.

Limitación del tráfico de VPN de strongSwan por espacio de nombres

Cuando dispone de un clúster de un solo arrendatario o multiarrendatario, puede limitar el tráfico de VPN a los pods en determinados espacios de nombres únicamente.

Por ejemplo, digamos que desea que los pods de un solo espacio de nombres específico, my-secure-namespace, envíen y reciban datos a través de la VPN. No desea que los pods de otros espacios de nombres, como kube-system, ibm-system o default accedan a la red local. Para limitar el tráfico de VPN únicamente a my-secure-namespace, puede crear políticas de red globales de Calico.

Antes de utilizar esta solución, revise las siguientes consideraciones y limitaciones.

• No es necesario desplegar el diagrama de Helm de strongSwan en el espacio de nombres especificado. El pod de VPN de strongSwan y el conjunto de daemons de rutas se pueden desplegar en kube-system o en cualquier otro espacio de nombres. Si la VPN de strongSwan no se despliega en el espacio de nombres especificado, la prueba de Helm vpn-strongswan-ping-remote-ip-1 fallará. Este error es esperado y aceptable. La prueba ejecuta ping sobre la dirección IP privada remote.privateIPtoPing de la pasarela VPN local desde un pod que no está en el espacio de nombres que tiene acceso directo a la subred remota. Sin embargo, el pod de VPN sigue siendo capaz de reenviar tráfico a los pods de los espacios de nombres que no tienen rutas a la subred remota, y el tráfico puede seguir fluyendo correctamente. El estado de VPN sigue siendo ESTABLISHED y los pods del espacio de nombres especificado se pueden conectar a través de la VPN.

• Las políticas de red global de Calico en los siguientes pasos no impiden que los los pods de Kubernetes que utilizan redes de host envíen y reciban datos a través de la VPN. Cuando se configura un pod con redes de host, la app que se ejecuta en el pod puede estar a la escucha en las interfaces de red del nodo trabajador en el que se encuentra. Estos pods de redes de host pueden existir en cualquier espacio de nombres. Para determinar qué pods tienen redes de host, ejecute kubectl get pods --all-namespaces -o wide y busque los pods que no tengan ninguna dirección IP de pod de 172.30.0.0/16. Si desea evitar que los pods de redes de host puedan enviar y recibir datos a través de la VPN, puede establecer las opciones siguientes en el archivo de despliegue values.yaml: local.subnet: 172.30.0.0/16 y enablePodSNAT: false. Estos valores de configuración exponen todos los pods de Kubernetes a través de la conexión VPN en la red remota. No obstante, únicamente serán accesibles a través de la VPN aquellos pods que se encuentren en el espacio de nombres seguro especificado.

Antes de empezar

• Despliegue el diagrama de Helm strongSwan y asegúrese de que la conectividad de VPN funciona correctamente.
• Instale y configure la CLI de Calico.

Para limitar el tráfico de VPN a un espacio de nombres determinado,

1. Cree una política de red global de Calico denominada allow-non-vpn-outbound.yaml. Esta política permite que todos los espacios de nombres puedan seguir enviando tráfico de salida a todos los destinos, excepto a la subred remota a la que accede la VPN de strongSwan. Sustituya <remote.subnet> por el valor de remote.subnet que ha especificado en el archivo de configuración values.yaml de Helm. Para especificar varias subredes remotas, consulte la documentación 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. Aplique la política.

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

3. Cree otra política de red global de Calico denominada allow-vpn-from-namespace.yaml. Esta política permite que únicamente un espacio de nombres especificado pueda enviar tráfico saliente a la subred remota a la que accede la VPN de strongSwan. Sustituya <namespace> por el espacio de nombres que puede acceder a la VPN y <remote.subnet> por el valor de remote.subnet que ha especificado en el archivo de configuración values.yaml de Helm. Para especificar varios espacios de nombres o subredes remotas, consulte la documentación 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. Aplique la política.

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

5. Verifique que se crean las políticas de red globales en el clúster.

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

Limitación del tráfico de VPN de strongSwan por nodo trabajador

Cuando tiene varios despliegues de VPN de strongSwan en un clúster multiarrendatario, puede limitar el tráfico de VPN para cada despliegue a nodos trabajadores específicos que estén dedicados a cada arrendatario.

Al desplegar un diagrama de Helm strongSwan, se crea un despliegue de VPN de strongSwan. Los pods de VPN de strongSwan se despliegan en cualquier nodo trabajador no marcado. Además, se crea un conjunto de daemons de Kubernetes. Este conjunto de daemons configura automáticamente rutas en todos los nodos trabajadores no marcados del clúster con cada una de las subredes remotas. El pod de VPN de strongSwan utiliza las rotas en los nodos trabajadores para reenviar solicitudes a la subred remota en la red local.

No se configuran rutas en nodos marcados a menos que especifique la marca en el valor tolerations del archivo value.yaml. Al aplicar una marca a los nodos trabajadores, puede evitar que se configuren rutas VPN en dichos trabajadores. A continuación, puede especificar la marca en el valor tolerations únicamente para el despliegue de VPN que desea permitir en los trabajadores marcados. De este modo, los pods de VPN de strongSwan del despliegue del diagrama de Helm de un arrendatario solo utilizan las rutas en los nodos trabajadores de dicho arrendatario para reenviar el tráfico a través de la conexión VPN con la subred remota.

Antes de utilizar esta solución, revise las siguientes consideraciones y limitaciones.

• De forma predeterminada, Kubernetes coloca los pods de app en los nodos trabajadores no marcados que estén disponibles. Para asegurarse de que esta solución funciona correctamente, cada arrendatario debe asegurarse primero de desplegar sus pods de app únicamente en trabajadores a los que se haya aplicado la marca correspondiente al arrendatario correcto. Además, cada nodo trabajador marcado debe tener también una tolerancia para permitir que los pods de app se puedan colocar en el nodo. Para más información sobre manchas y tolerancias, consulte la documentación de Kubernetes.
• Es posible que los recursos del clúster no se utilicen de manera óptima debido a que ningún arrendatario puede colocar pods de app los nodos compartidos no marcados.

Los pasos siguientes para limitar el tráfico de VPN de strongSwan por nodo trabajador utilizan este caso de ejemplo: digamos que tiene un clúster de IBM Cloud Kubernetes Service multiarrendatario con seis nodos trabajadores. El clúster da soporte al arrendatario A y al arrendatario B. Puede marcar los nodos de trabajador de las maneras siguientes.

• Se aplica una marca a dos nodos trabajadores de manera que solo se planifican en los trabajadores los pods del arrendatario A.
• Se aplica una marca a dos nodos trabajadores de manera que solo se planifican en los trabajadores los pods del arrendatario B.
• No se aplica ninguna marca a dos nodos trabajadores, ya que se necesitan al menos 2 nodos trabajadores para los pods de VPN de strongSwan y la IP del equilibrador de carga en el que se ejecuta.

Para limitar el tráfico de VPN a los nodos marcados para cada arrendatario.

1. Para limitar el tráfico de VPN solo a los trabajadores dedicados a arrendatario A en este ejemplo, especifique la siguiente toleration en el archivo values.yaml para el diagrama de Helm strongSwan del arrendatario A.

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

   Esta tolerancia permite que se ejecute el conjunto de daemons de ruta en los dos nodos trabajadores que tienen el antagonismo dedicated="tenantA" y en los dos nodos trabajadores no antagónicos. The strongSwan VPN pods for this deployment run on the two untainted worker nodes.

2. Para limitar el tráfico de VPN solo a los trabajadores dedicados a arrendatario B en este ejemplo, especifique la siguiente toleration en el archivo values.yaml para el diagrama de Helm strongSwan del arrendatario B.

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

   Esta tolerancia permite que se ejecute el conjunto de daemons de ruta en los dos nodos trabajadores que tienen el antagonismo dedicated="tenantB" y en los dos nodos trabajadores no antagónicos. Los pods de VPN de strongSwan para este despliegue también se ejecutan en los dos nodos trabajadores no marcados.