Digital Developer Conference: Hybrid Cloud 2021 | Capacitaciones gratuitas por expertos y partners | 21 de Setiembre ¡Inscríbete Ahora!

Establecer conexión VPN con StrongSwan desde un clúster de Kubernetes/Openshift

Introducción

La tecnología strong Swan es una implementación IPsec de código abierto. Está basado en el proyecto descontinuado FreeS/WAN y el parche X.509. Fue originalmente desarrollado para Linux, pero desde entonces se ha hecho compatible con Android, FreeBSD, Mac OS X, Windows y otras plataformas.

Originalmente solo soportaba el deamon IKEv2 pero como su adopción ha tomado tanto tiempo, se añadió soporte a IKEv1 desde la versión 5 de stronSwan.

StrongSwan se concentra en:

  • Simplicidad en la configuración
  • Métodos fuertes de encriptación y autenticación
  • Poderosas políticas IPsec que forman parte de grandes y complejas redes VPN
  • Diseño modular con gran capacidad de expansión

El desarrollador de StronSwan es Andreas Steffen, profesor de seguridad y comunicaciones y líder del Instituto para soluciones de redes en la University of Applied Sciences Rapperswil.

StrongSwan se encuentra disponible en los clústers de Kubernetes y Openshift en IBM Cloud en despliegues de infraestructura clásica para poder conectarse con ambientes on-premise e interactuar con sistemas legados; ya sea como, BackEnd o FrontEnd de los aplicativos de cualquier empresa sin costo adicional al clúster que se tenga disponible en IBM Cloud.

Requerimientos

Requisitos mínimos para utilizar strongSwan en un clúster de kubernetes:

  • cpu: “5m”
  • memory: “10Mi”

Los recursos que utiliza son estáticos por lo que ,un aumento en el tráfico de la VPN no requiere de más recursos dentro del clúster para el funcionamiento de StrongSwan.

Limitaciones StrongSwan

  • El diagrama de Helm strongSwan solo se admite para clústeres clásicos y no se admite para clústeres de VPC Gen 1 o Gen 2.
  • El diagrama de Helm strongSwan requiere que el punto final VPN remoto haya habilitado el cruce de NAT. El cruce de NAT requiere el puerto UDP 4500, además del puerto IPSec de IPSec predeterminado de 500. Los dos puertos UDP deben estar permitidos a través de cualquier cortafuegos que esté configurado.
  • El diagrama de Helm strongSwan no da soporte a VPN IPSec basadas en rutas, solo en las que están basadas en políticas.
  • El diagrama de Helm strongSwan da soporte a VPN IPSec que utilizan claves precompartidas, pero no da soporte a VPN IPSec que requieren certificados.
  • Cada diagrama de Helm strongSwan funciona exclusivamente para un solo clúster.
  • El diagrama de Helm strongSwan se ejecuta como un pod de Kubernetes dentro del clúster. El rendimiento de VPN se ve afectado por el uso de memoria y de red por parte de Kubernetes y de otros pods que se ejecuten en el clúster. Si tiene un entorno en el que el rendimiento sea un factor clave, tenga en cuenta la posibilidad de utilizar una solución VPN que se ejecute fuera del clúster en hardware dedicado.
  • El diagrama de Helm strongSwan ejecuta un solo pod de VPN como punto final de túnel IPSec. Si el pod falla, el clúster reinicia el pod. Sin embargo, puede experimentar un breve periodo de tiempo mientras se inicia el nuevo pod y se restablece la conexión VPN. Si necesita una recuperación de errores más rápida o una solución de alta disponibilidad más elaborada, tenga en cuenta la posibilidad de utilizar una solución VPN que se ejecute fuera del clúster en hardware dedicado.
  • El diagrama de Helm strongSwan no proporciona métricas ni supervisión del tráfico de red que fluye a través de la conexión VPN. Para ver una lista de las herramientas de supervisión a las que se da soporte, consulte servicios de registro y de supervisión.
  • 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 Helm de strongSwan consecuentemente para ver las características más recientes y los arreglos de seguridad.

Referencia sobre limitaciones de strongSwan en el siguiente link

Prerrequisitos antes de empezar la configuración

Para realizar la conexión con strongSwan se requiere de lo siguiente:

  1. Clúster de Kubernetes/Openshift en IBM Cloud
  2. Ambiente on-premise que tenga

    • Gateway Appliance para establecer conexiones VPN
    • Subred para establecer la comunicación con el clúster en la nube
    • Una máquina para desplegar una aplicación web para realizar pruebas
  3. Debe contar con una máquina Linux desde la cual ejecutar todos los comandos de la guía, con lo siguiente instalado:

NOTA: En esta guía utilizaremos VPC en lugar de un ambiente on-premise y los pasos que se mencionan deben adaptarse a su propio ambiente

Guía de Configuración de Strong Swan y on-premise (VPC)

Obtener los valores de conexión del clúster de Kubernetes/Openshift

  1. Ingresa a IBM Cloud desde línea de comandos

    $ ibmcloud login –sso
  2. Establecer el grupo de recursos donde se encuentra el clúster de Kubernetes/Openshift

    $ ibmcloud target -g \<grupo de recursos\>
  3. Ingresa al clúster de kubernetes/openshift

    • Kubernetes: Obtén las instrucción de login en la sección de acceso del clúste

      Panel de acceso a las CLI Tools
    • Openshift: Obtén el token de autenticación en la consola de Openshift similar a la siguiente:

      Dashboard RedHat OpenShift

      $ oc login –token=\<token-obtenido-de-openshift\> --server=https://c100-e.us-south.containers.cloud.ibm.com:31204
  4. Seleccionar una de las IP públicas del clúster (puede ser cualquiera), revisa la sección 1 del glosario para más información

    
    $ kubectl describe configmap ibm-cloud-provider-vlan-ip-config -n kube-system
    ...
         "subnets": [
    ...
        {
          "id": "2809892",
          "subnets": [
            {
              "id": "2465002",
              "ips": [
                "169.57.28.130",
                "169.57.28.131",
                "169.57.28.132",
                "169.57.28.133",
                "169.57.28.134"
              ],
              "is_public": true,
              "is_byoip": false,
              "cidr": "169.57.28.128/29"
            }
    ...
        
    En este caso usaremos esta: 169.57.28.133 (Guarda IP pública en una nota de texto)

  5. Obtener las CIDRs de los PODs y de los servicios del clúster en el cual se configurará strongSwan (Pod Subnet y Service Subnet) y la CIDR privada del cluster (Subnet VLAN privada), revisa la sección 1 del glosario para más información

    
    $ ibmcloud ks cluster get --cluster  --show-resources
    Retrieving cluster c1doised04051r3ln610 and all its resources...
    
    OK
    Name:                                             iks
    ID: c1doised04051r3ln610
    State: normal
    Status: All Workers Normal
    Created: 2021-03-24T18:49:32+0000
    Location: mex01
    Pod Subnet: 172.30.0.0/16
    Service Subnet: 172.21.0.0/16
    Master URL: https://c11.mex01.containers.cloud.ibm.com:30276
    Public Service Endpoint URL: https://c11.mex01.containers.cloud.ibm.com:30276
    Private Service Endpoint URL: https://c11.private.mex01.containers.cloud.ibm.com:30276
    Master Location: mex01
    Master Status: Ready (2 weeks ago)
    Master State: deployed
    Master Health: normal
    Ingress Subdomain: iks-756363-ef814df686d0b4743e59c79659876c98-0000.mex01.containers.appdomain.cloud Ingress Secret: iks-756363-ef814df686d0b4743e59c79659876c98-0000
    Ingress Status: healthy
    Ingress Message: All Ingress components are healthy
    Workers: 1
    Worker Zones: mex01
    Version: 1.20.6_1536* (1.20.6_1538 latest)
    Creator: -
    Monitoring Dashboard: -
    Resource Group ID: 6b450f5dcc8646ea8b220b01a6a0ec29
    Resource Group Name: default
    Subnet VLANs VLAN ID Subnet CIDR Public User-managed 2809894 10.130.89.40/29 false false 2809892 169.57.28.128/29 true false
    En este caso tenemos los siguientes valores:

    
    Pod Subnet: 172.30.0.0/16,
    Service Subnet: 172.21.0.0/16
    Subnet VLAN privada: 10.130.89.40/29 (Guarda los CIDRs en una nota de texto)
        

Configuración de VPC

Instanciar el servicio de VPC

  1. Acceder a IBM Cloud e iniciar sesión
  2. Navegar al apartado de Infraestructura VPC >> Red >> VPCs
  3. Hacer click en “Crear +”
  4. Llenar los datos de la siguiente manera:

VPC

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la VPC
Grupo de recursos Definido por el usuari Recurso de la organización
Grupo de seguridad predeterminado Permitir SSH (Sí)
Permitir ping (Sí)
Habilitar acceso a recursos clásicos (No)
Permite SSH de entrada y hacer ping sobre el tráfico
Solo se puede habilitar acceso a recursos clásicos a una VPC por región.

Subnet de la VPC

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la subred
Grupo de recursos Definido por el usuario Recurso de la organización
Ubicación Definido por el usuario Región donde la subred será creada
Prefijo de dirección Lo define IBM Cloud CIDR de IPs
Número de direcciones Lo define el usuario Número de direcciones que tendrá la subred
Rango de IP Lo define el parámetro anterior Rango de IP de la subred
Pasarela pública Desconectado Permite que todos los recursos se conecten con la red pública de Internet

En este caso la subnet de la VPC es: 172.16.128.0/24 (Guarda la subnet en una nota de texto)

Configurar y crear una pasarela VPN en la VPC

Políticas IPsec e IKE

Crear las políticas para la pasarela VPN

a) Acceder a IBM Cloud e iniciar sesión

b) Navegar al apartado de Infraestructura VPC >> Red >> Pasarelas VPN

c) Seleccionar Políticas IPsec y hacer click en “Crear +”

Política IPsec: suite de protocolos que proporciona comunicación segura entre dispositivos. IBM Cloud VPN for VPC utiliza el protocolo llamado Encapsulating Security Protocol (ESP) en modalidad de túnel, que proporciona autenticación y cifrado de todo el paquete.

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la política
Grupo de recursos Definido por el usuario Recurso de la organización
Región Definido por el usuario Región donde la pasarela VPN será creada
Autenticación sha1 Algoritmo de autenticación
Cifrado aes256 Cifrado de datos
Secreto de reenvío perfecto Habilitado Habilita modificación del grupo Diffie-Hellman
Grupo Diffie-Hellman 14 Protocolo de intercambio
Tiempo de vida de la clave 3600 Tiempo en el que una clave secreta es válida

d) Seleccionar Políticas IKE y hacer click en “Crear +”

Política IKE: forma parte del protocolo IPsec utilizado para establecer conexiones VPN. En la fase 1 de IKE, los iguales de VPN utilizan el intercambio de claves Diffie-Hellman (DH) para crear un canal de comunicación seguro y autenticado. En la fase 2 de IKE, los iguales utilizan el canal seguro de la fase 1 para negociar parámetros para el túnel IPsec.

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la política
Grupo de recursos Definido por el usuario Recurso de la organización
Región Definido por el usuario Región donde la pasarela VPN será creada
Versión de IKE 2 Versión del protocolo
Autenticación sha1 Algoritmo de autenticación
Cifrado aes256 Cifrado de datos
Grupo Diffie-Hellman 14 Protocolo de intercambio
Tiempo de vida de la clave 3600 Tiempo en el que una clave secreta es válida

No es necesario que las políticas compartan la misma autenticación, cifrado o grupo DH. Puede ser cualquier combinación

Pasarela VPN

Crear la pasarela VPN

a) Seleccionar Pasarelas VPN y hacer click en “Crear +”

b) Llena los campos como se indica a continuación (utiliza sección 1 del glosario como referencia)

Propiedad Valor Descripción
Nombre de pasarela VPN Definido por el usuario Nombre de la pasarela VPN
Grupo de recursos Definido por el usuario Recurso de la organización
Región Definido por el usuario Región donde la pasarela VPN será creada
Nube privada virtual Definido por el usuario VPC creada con anterioridad
Subred Definido por el usuario Subnet perteneciente a la VPC
Modalidad Basada en política La VPN de StrongSwan no soporta la modalidad basada en rutas

Conexión de pasarela VPN (Utilizar las IPs y CIDRs que se obtuvieron al inicio de la guía)

Propiedad Valor Descripción
Nombre de conexión VPN Definido por el usuario Nombre de la política
Dirección de pasarela de igual 169.57.28.133 Dirección IP Pública disponible para el Gateway de StrongSwan
Clave precompartida password Clave para la pasarela de igual (cualquier valor con un mínimo de 6 caracteres)
Subredes locales 172.16.128.0/24 Subred de la VPC en CIDR o cualquier subred on-premise
Subredes de igual 172.30.0.0/16, 172.21.0.0/16, 10.130.89.40/29 Subredes del pod, servicio y VLAN privada del clúster
Detección de igual caído Valores por defecto Define que acción hacer ante la pérdida de conexión (Estos valores se pueden editar)
Política IKE Nombre de la política IKE creada previamente
Política IPsec Nombre de la política IPsec creada previamente

c) El resultado debería ser algo como esto:

VPN Dashboard

Pasarela VPN

Panel de configuración de VPN

d) Una vez creada la pasarela VPN se nos proporcionará una IP de pasarela o la IP del Gateway appliance que tengan en on-premise. En este caso es la siguiente: 52.117.9.53 (Guardar la IP en una nota de texto. Este valor deberá usarse en el archivo config.yaml en el campo remote.gateway)

Configurar StrongSwan en el clúster de kubernetes usando Helm

Configuración de Helm en el clúster de kubernetes por medio de IBM Cloud CLI

a) Inicie sesión en su cuenta de IBM Cloud

b) Establecer el contexto para el clúster de kubernetes

c) Introduzca los siguientes comandos:

  • Añada el repositorio de Helm a la instancia de Helm:

$ helm repo add iks-charts https://private.icr.io/helm/iks-charts
  • Actualice el repositorio para recuperar las versiones más recientes del diagrama de Helm:

$ helm repo update
  • Obtenga una lista de los diagramas de Helm disponibles

$ helm search repo iks-charts
  • Para más información visitar el siguiente link

Configuración de strongSwan

  • Utilice el siguiente comando para guardar los valores predeterminados de Helm de StrongSwan en un archivo YAML local:

$ helm show values iks-charts/strongswan > config.yaml
  • Abra el archivo config.yaml y configure los siguientes valores con los datos obtenidos aquí, para mayor detalle referirse a la sección 2 del glosario
Propiedad Valor Descripción
ipsec.keyexchange ikev2 Versión del protocolo IKE
ipsec.esp aes256-sha1-modp2048! Política de IPsec que concuerde con la creada para la pasarela VPN
cifrado: aes256,
autenticación: sha1,
Diffie Hellman: 14 = mod2048

Otros valores, revisar
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
ipsec.ike aes256-sha1-modp2048! Política de IKE que concuerde con la creada para la pasarela VPN
cifrado: aes256,
autenticación: sha1,
Diffie Hellman: 14 = mod2048

Otros valores, revisar
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
ipsec.auto Add Conexión VPN de entrada
ipsec.ikelifetime 3600s Tiempo en el que la clave secreta es válida, tiene que ser idéntica a la establecida en la política IKE En IBM cloud
ipsec.lifetime 3600s Tiempo en el que la clave secreta es válida, tiene que ser idéntica a la establecida en la política IPsec en IBM Cloud
loadBalancerIP 169.57.28.133 Dirección IP Pública disponible para el Gateway de StrongSwan
local.id 169.57.28.133 Misma IP que el loadBalancerIP
local.subnet 172.30.0.0/16, 172.21.0.0/16, 10.130.89.40/29 Subredes del pod, servicio y VLAN privada del clúster
preshared.secret password Valor de la llave secreta
remote.gateway 52.117.9.53 IP para conexión remota
remote.id 52.117.9.53 Identificador de la red remota
remote.subnet 172.16.128.0/24 Subred de la VPC
  • Despliegue el diagrama Helm con el siguiente comando (si el campo status muestra DEPLOYED, el diagrama se desplegó correctamente)

$ helm install vpn iks-charts/strongswan -f config.yaml
  • Espere a que el pod cambie su estado a “Running”

$ kubectl get pod -wn default -l app=strongswan,release=vpn

Revisión del estado de la VPN

Para revisar el estado de la conexión VPN utilice los siguientes comandos:


$ export STRONGSWAN_POD=$(kubectl get pod -n default -l app=strongswan,release=vpn -o jsonpath='{ .items[0].metadata.name }')
$ kubectl exec -n default  $STRONGSWAN_POD -- sudo ipsec status

Si todo está bien, debería salir el valor “ESTABLISHED” en un mensaje como el siguiente:


Security Associations (1 up, 0 connecting):
    k8s-conn[35]: ESTABLISHED 38 minutes ago, 172.30.154.172[169.57.28.133]...10.130.101.11[52.117.9.53]
    k8s-conn{98}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c968bc97_i c7111d60_o
    k8s-conn{98}:   10.130.89.40/29 10.130.101.11/32 172.21.0.0/16 172.30.0.0/16 === 172.16.128.0/24

En caso de no establecerse la conexión

Si no se ha establecido la conexión, pruebe lo siguiente:

  • Reiniciar la conexión VPN de la pasarela que creo en la VPC o en el servidor on-premise.
  • Revisar que la conexión de la pasarela VPN tenga los datos correctos (dirección de pasarela de igual, clave precompartida, políticas IKE o IPsec, subredes locales o subredes de igual). Si la VPN se creó en un servidor on-premise, revisar la configuración IKE y ESP (IPsec) (Generalmente se encuentra en un archivo llamado ipsec.conf)
  • Revisar el archivo config.yaml y que los valores usados concuerden con los establecidos en la VPN, ya sea en la VPC u on-premise
  • Probar la conectividad VPN con las cinco pruebas de Helm utilizando el siguiente comando (solo debería pasar las primeras 3 pruebas), las pruebas de Helm se describen en la sección 3 del glosario.

$ helm test vpn
  • Revisar los logs que generó StrongSwan al establecer la conexión con los siguientes comandos:

$ export STRONGSWAN_POD=$(kubectl get pod -n default -l app=strongswan,release=vpn -o jsonpath='{ .items[0].metadata.name }')

$ kubectl logs -n default  $STRONGSWAN_POD

Verificar comunicación entre aplicaciones

Además de las pruebas que proporciona Helm, podemos hacer una prueba más directa desplegando una aplicación en el clúster de kubernetes y otra en la VPC o en la infraestructura on-premise. Posteriormente se hará un curl o wget desde la VPC al cluster y viceversa para confirmar que se tiene acceso a dichos recursos.

Desplegar una aplicación en el clúster de Kubernetes/Openshift

Vamos a desplegar una aplicación en el clúster para probar la conexión que estableció strongSwan

  • Usaremos una imagen de contenedor proporcionada en la documentación de Kubernetes (más información en el siguiente link)
  • Desplegaremos la aplicación en nuestro cluster con el siguiente comando:

$ kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
  • Ver el despliegue:

$ kubectl get deployments

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
hello-node   1/1       1                       1                    1m
  • Ver el pod (recordar el nombre del pod para probar el curl posteriormente)

$ kubectl get pods

NAME                                           READY   STATUS   RESTARTS   AGE
hello-node-5f76cf6ccf-br9b5   1/1         1               1                  1m
  • Exponer el pod:

$ kubectl expose deployment hello-node --type=LoadBalancer --port=8080

Ver el servicio de manera detallada (recordar el CLUSTER-IP y el puerto de hello-node para probar el curl posteriormente, en este caso es 172.21.23.109:8080)


$ kubectl get services -o wide

Panel de detalles de los servicios dentro de la consola

Desplegar una aplicación en la VPC

Vamos a instanciar una VSI en la VPC que se creó para desplegar una simple página web y probar la conexión de strongSwan

Configurar grupo de seguridad

a) Acceder a IBM Cloud e iniciar sesión

b) Navegar al apartado de Infraestructura VPC >> Red >> Grupos de seguridad

c) Hacer click en “Crear +”

d) Llenar los datos de la siguiente manera:

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la VPC
Grupo de recursos Definido por el usuario Recurso de la organización
Región Definido por el usuario Región donde el grupo de seguridad será creado
Nube privada virtual VPC que se creó en el paso anterior
Reglas de entrada Protocolo: TCP
Puerto: Cualquiera
Tipo de origen: Cualquiera
Define el tipo de protocolo, rango de puertos y origen para la regla
Reglas de salida Protocolo: TCP
Puerto: Cualquiera
Tipo de destino: Cualquiera
Define el tipo de protocolo, rango de puertos y destino para la regla

Establecer una llave SSH en VPC

a) Ejecutar el siguiente comando para generar dos archivos. La clave pública se encuentra en el archivo .pub


$ ssh-keygen

b) Una vez se tenga la llave, navegar en IBM Cloud al apartado de Infraestructura de VPC >> Computación >> Claves SSH

c) Click en “Añadir clave SSH” y completar la información requerida.

Ejemplo del servicio detallado a seleccionar

Desplegar una VSI en la VPC

a) Ir al apartado de Infraestructura de VPC >> Computación >> Instancias de servidor virtual

b) Click en “Crear +” y llenar los datos de la siguiente manera:

Propiedad Valor Descripción
Nombre Definido por el usuario Nombre de la VSI
Grupo de recursos Definido por el usuario Recurso de la organización
Ubicación Definido por el usuario Región donde la VSI será creada (Debe ser la misma región de la VPC creada con anterioridad)
Tipo de servidor virtual Público Define si la VSI será multiarrendatario o arrendatario único
Sistema operativo Ubuntu Linux 20.04 Sistema operativo que tendrá la VSI
Perfil Computación cx2-2×4 Hardware de la VSI
Claves SSH Definido por el usuario (creada previamente) Esta clave se utilizará para conectarse de forma segura a la instancia una vez se está ejecutando
Datos de usuario (opcional) Dejar en blanco Lista de comandos que se hacen automáticamente cuando se instancie la VSI
Volumen de arranque Dejar en blanco El tamaño por default es de 100 GB, incluye cifrado gestionado por proveedor (Estos valores se pueden editar)
Volúmenes de datos Dejar vacío Volúmenes de datos secundarios
Nube privada virtual Definido por el usuario VPC creada con anterioridad
Interfaces de red Si seleccionó correctamente la región y la VPC, debería aparecer automáticamente la subred de esa VPC Opciones de red para conectarse a la VPC

NOTA: Recordar la IP privada para probar el curl posteriormente

Confirmación de la instancia creada

c) Reservar una dirección IP flotante

  • Pulse la instancia para ver la información detallada
  • En la sección de interfaces de red pulse en “Reservar + “para asociar una dirección IP flotante a la instancia. (Esta se usará para acceder a la VSI por ssh
  • En “Floating IP address” seleccionar la opción “Reserve a new Floating IP”
  • En “Security groups” seleccionar el grupo de seguridad creado con anterioridad
  • Guardar

Panel de configuración de la red

d) Acceder a la instancia por SSH

  • Abrir una consola de comandos
  • Utilizar el siguiente comando:

    $ ssh -i  root@
    NOTA: no debe ser el archivo con extensión .pub
  • Cuando se le pregunte “Are you sure you want to continue connecting (yes/no)” escribir yes.
  • Desplegar una página web:

    1. Una vez conectados a nuestra VSI, utilizar el siguiente comando:

      $ sudo apt update
    2. Instalar un servidor web (puede ser cualquier otro servidor web, pero en este caso usaremos apache) con el siguiente comando:

      $ sudo apt-get install apache2
    3. Si hacemos un curl a localhost o a la IP privada de la VSI deberíamos visualizar la página default que proporciona Apache.

      $ curl localhost
    4. Abrir el puerto 80 para acceder desde el cluster.

      $ sudo ufw allow 80

e) Hacer curl de la VSI a la aplicación en el clúster:

  • Desde la terminal conectados con SSH, hacer un curl al servicio hello-node que creamos previamente.

    $ curl \<ip privado del pod\>:\<puerto pod\>
    Deberíamos tener un resultado como este:

    Muestra de código cómo ejemplo
  • El curl fue exitoso

f) Hacer curl a la aplicación residente en la VSI desde clúster (se usará IBM Cloud CLI)

  • Iniciar sesión en IBM Cloud

    $ ibmcloud login --sso
  • Establecer el contexto para el clúster de kubernetes/openshift

    1. Kubernetes: Obtén las instrucción de login en la sección de acceso del clúster

      Panel de Configuración de IKS
    2. Openshift: Obtén el token de autenticación en la consola de Openshift similar a la siguiente:

      Dashboard de RedHat OpenShift, copiar commando

      $ oc login --token=_tb8H-1tKjaskjhdaG8U9iNIAENwtzFyvsAEuNY5NC3XDiYZsk --server=https://c100-e.us-south.containers.cloud.ibm.com:31204
    3. Hacer un curl a la VSI con el siguiente comando (usar nombre del pod):

      $ kubectl exec hello-node-7567d9fdc9-n2gwq curl 172.16.128.12
    4. Debería visualizarse la página default que proporciona apache.

Glosario de configuraciones

Sección 1: Conexión de la pasarela VPN

Propiedad Valor Descripción
Nombre de conexión VPN Definido por el usuario Nombre de la política
Dirección de pasarela de igual 169.57.28.133 Dirección IP Pública disponible para el Gateway de StrongSwan (Revisar nota 1)
Clave precompartida password Clave para la pasarela de igual (Revisar nota 2)
Subredes locales 172.16.128.0/24 Subred de la VPC en CIDR o cualquier subred on-premise
Subredes de igual 172.30.0.0/16, 172.21.0.0/16, 10.130.89.40/29, 10.130.101.11/32 Subredes del cluster (subredes de Pod. Service y VLAN privada) (Revisar nota 3)
Detección de igual caído Parámetros definidos por el usuario Define que acción hacer ante la pérdida de conexión. (Revisar nota 4)
Política IKE iks-ike2-policy Nombre de la política IKE creada previamente
Política IPsec iks-esp-policy Nombre de la política IPsec creada previamente

Nota 1: La dirección de pasarela de igual se obtiene al consultar una IP pública del clúster de kubernetes con el siguiente comando:


$ kubectl describe configmap ibm-cloud-provider-vlan-ip-config -n kube-system
...
     "subnets": [
...
    {
      "id": "2809892",
      "subnets": [
        {
          "id": "2465002",
          "ips": [
            "169.57.28.130",
            "169.57.28.131",
            "169.57.28.132",
            "169.57.28.133",
            "169.57.28.134"
          ],
          "is_public": true,
          "is_byoip": false,
          "cidr": "169.57.28.128/29"
        }
...

Esta IP debe ser igual a la que se especifique en el parámetro loadBalancerIP del archivo config.yaml para StrongSwan.

Si no se tiene IPs disponibles en el clúster, revisar el siguiente link para liberar una IP usada.

Nota 2: La clave precompartida tiene la estructura de una contraseña normal, por lo que puede ser cualquier conjunto de letras, números o símbolos

Nota 3: Las subredes de igual se obtienen con el siguiente comando y de lo que se muestra en Pod Subnet, Service Subnet y Subnet VLANs (la privada)


$ ibmcloud ks cluster get --cluster  --show-resources
Retrieving cluster c1doised04051r3ln610 and all its resources...

OK
Name:                           iks
ID:                             c1doised04051r3ln610
State:                          normal
Status:                         All Workers Normal
Created:                        2021-03-24T18:49:32+0000
Location:                       mex01
Pod Subnet:                     172.30.0.0/16
Service Subnet:                 172.21.0.0/16
Master URL:                     https://c11.mex01.containers.cloud.ibm.com:30276
Public Service Endpoint URL:    https://c11.mex01.containers.cloud.ibm.com:30276
Private Service Endpoint URL:   https://c11.private.mex01.containers.cloud.ibm.com:30276
Master Location:                mex01
Master Status:                  Ready (3 weeks ago)
Master State:                   deployed
Master Health:                  normal
Ingress Subdomain:              iks-756363-ef814df686d0b4743e59c79659876c98-0000.mex01.containers.appdomain.cloud
Ingress Secret:                 iks-756363-ef814df686d0b4743e59c79659876c98-0000
Ingress Status:                 healthy
Ingress Message:                All Ingress components are healthy
Workers:                        1
Worker Zones:                   mex01
Version:                        1.20.5_1533* (1.20.6_1536 latest)
Creator:                        -
Monitoring Dashboard:           -
Resource Group ID:              6b450f5dcc8646ea8b220b01a6a0ec29
Resource Group Name:            default

*To update to 1.20.6_1536 version, run 'ibmcloud ks cluster master update --cluster iks --version 1.20.6_1536'. Review and make any required version changes before you update: 'https://ibm.biz/iks-versions'


Subnet VLANs
VLAN ID   Subnet CIDR        Public   User-managed
2809894   10.130.89.40/29    false   
2809892   169.57.28.128/29   true     false

Si también se requiere que los worker nodes accedan a la vpn, es necesario agregar sus IPs privadas (en formato CIDR) a las subredes de igual. Se consultan con el siguiente comando:


$ kubectl get nodes

NAME            STATUS   ROLES    AGE   VERSION
10.130.101.11   Ready       33d   v1.20.4+IKS

Nota 4: Este apartado nos indica que hacer cuando se pierda la conexión con la VPN, y tenemos las siguientes opciones:

Parámetro Opciones disponibles Descripción
Acción Reiniciar
Borrar
Retener
Ninguna
Acción a realizar cuando una pasarela de igual deja de responder:
Reiniciar – Volver a negociar la conexión inmediatamente.
Borrar – Cerrar la conexión.
Retener – Volver a negociar la conexión al detectar tráfico.
Ninguna – No realizar ninguna acción cuando se detecta un igual caído.
Intervalo (seg) Definido por el usuario Con qué frecuencia probar que la pasarela de igual está respondiendo (debe ser menor que el tiempo de espera).
Tiempo de espera (seg) Definido por el usuario Define el intervalo de tiempo de espera después del cual se suprimen todas las conexiones a un igual debido a la inactividad. Este tiempo de espera sólo se aplica a IKEv1.

Sección 2: Archivo config.yaml para diagrama de Helm de StrongSwan

Propiedad Valor Descripción
loadBalancerIP 169.57.28.133 Dirección IP Pública disponible para el Gateway de StrongSwan (Revisar nota 6)
ipsec.keyexchange ikev2 Versión del protocolo IKE
ipsec.esp aes256-sha1-modp2048! Política de IPsec
cifrado: aes256,
autenticación: sha1,
Diffie Hellman: 14 = mod2048
(Revisar nota 7)
ipsec.ike aes256-sha1-modp2048! Política de IKE
cifrado: aes256,
autenticación: sha1,
Diffie Hellman: 14 = mod2048
(Revisar nota 8)
ipsec.auto add Conexión VPN de entrada (Revisar nota 9)
ipsec.ikelifetime 3600s Tiempo en el que la clave secreta es válida para la política IKE
ipsec.lifetime 3600s Tiempo en el que la clave secreta es válida para la política IPsec
local.subnet 172.30.0.0/16, 172.21.0.0/16, 10.130.89.40/29, 10.130.101.11/32 Subredes de las IPs privadas de todos los nodos de trabajador y las subredes del cluster.
local.ip 169.57.28.133 Usar la IP del load balancer
remote.gateway 52.117.9.53 IP para conexión remota
remote.subnet 172.16.128.0/24 Subred de la VPC
remote.id 52.117.9.53 Identificador de la red remota (Nota 10)
preshared.secret password Valor de la llave secreta

Nota 5: Las parámetros preshared.secret, remote.subnet y local.subnet deben ser iguales a los utilizados en la sección 1 (conexión de la pasarela VPN) de la siguiente manera:

config.yaml Conexión de la pasarela VPN
preshared.secret Clave precompartida
remote.subnet subredes locales
local.subnet subredes de igual

Nota 6: Si este parámetro se deja vacío, strongSwan utilizará al azar una de las IP públicas disponibles del clúster. Para saber cuál usó deberemos buscar en los logs de strongSwan:

  • Iniciar sesión de IBM Cloud a través de CLI
  • Establecer contexto del clúster
  • Introducir los siguientes comandos:

    
    $ export STRONGSWAN_POD=$(kubectl get pod -n default -l app=strongswan,release=vpn -o jsonpath='{ .items[0].metadata.name }')
    
    $ kubectl logs -n default  $STRONGSWAN_POD
        
  • Buscar el parámetro “leftid” y revisar la IP que utilizó strongSwan. Por ejemplo: leftid=169.57.28.133

Nota 7: Si este campo se deja vacío, por default strongSwan utilizará los siguientes valores: aes128-sha1,3des-sha1

Nota 8: Si este campo se deja vacío, por default strongSwan utilizará los siguientes valores: aes128-sha1-modp2048,3des-sha1-modp1536

Nota 9: El valor de este parámetro puede cambiar por “start”. Esto solo cambia el tipo de conexión de la VPN a uno de salida.

  • Conexión de Entrada: El punto final VPN local de la red remota inicia la conexión VPN y el clúster escucha la conexión

  • 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

Nota 10: Este valor se obtiene al crear la pasarela VPN.

Sección 4: Descripción de las pruebas de Helm para la conexión VPN de strongSwan

Prueba Descripción
vpn-strongswan-check-config Valida la sintaxis del archivo ipsec.conf que se genera desde el archivo config.yaml. Esta prueba puede fallar debido a valores incorrectos en el archivo config.yaml.
vpn-strongswan-check-state Comprueba que la conexión VPN tiene el estado ESTABLISHED. Esta prueba puede fallar por las siguientes razones:
  • Diferencias entre los valores del archivo config.yaml y los valores del punto final de VPN local.
  • Si el clúster está en modalidad «de escucha» (ipsec.auto se establece en add), la conexión no se establece en el lado local.
vpn-strongswan-ping-remote-gw Hace ping a la dirección IP pública de remote.gateway que ha configurado en el archivo config.yaml. Si la conexión VPN tiene el estado ESTABLISHED, puede pasar por alto el resultado de esta prueba. Si la conexión VPN no tiene el estado ESTABLISHED, esta prueba podría fallar por los motivos siguientes:
  • No haber especificado una dirección IP de pasarela VPN local. Si ipsec.auto se establece en start, la dirección IP de remote.gateway es obligatoria.
  • • Los paquetes ICMP (ping) están siendo bloqueados por un cortafuegos.
vpn-strongswan-ping-remote-ip-1 Hace ping a la dirección IP privada remote.privateIPtoPing de la pasarela VPN local desde el pod de VPN en el clúster. Esta prueba puede fallar por las siguientes razones:
  • No haber especificado una dirección IP remote.privateIPtoPing. Si intencionalmente no especifica una dirección IP, este error es aceptable.
  • No haber especificado el CIDR de subred del pod del clúster, 172.30.0.0/16, en la lista local.subnet.
vpn-strongswan-ping-remote-ip-2 Hace ping a la dirección IP privada remote.privateIPtoPing de la pasarela VPN local desde el nodo trabajador en el clúster. Esta prueba puede fallar por las siguientes razones:
  • No haber especificado una dirección IP remote.privateIPtoPing. Si intencionalmente no especifica una dirección IP, este error es aceptable.
  • No haber especificado el CIDR de subred privada del nodo trabajador del clúster en la lista local.subnet.

Referencias

Documentación para stronSwan en Kubernetes/Openshift en IBM Cloud
https://cloud.ibm.com/docs/containers?topic=containers-vpn

Documentación para crear una VPC en IBM Cloud:
https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console&locale=es

Documentación de strongSwan:
https://www.strongswan.org/about.html

Ejemplo usado para esta guía:
https://github.ibm.com/velox/onecloud/blob/master/architecture/public-isolation/VPN-setup.md

Políticas IPsec e IKE en contexto de strongSwan:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

Documentación para instalar herramientas de CLI:
https://cloud.ibm.com/docs/cli?topic=cli-getting-started#step1-install-idt

Documentación para diagramas de Helm:
https://github.com/helm/helm/releases