Compartir a través de

Cree un entorno de red de ejemplo para la administración de redes superpuestas de Azure IoT (versión preliminar)

  • Artículo

Para usar el servicio de administración de redes superpuestas de Azure IoT (versión preliminar), debe configurar un entorno de red aislado. Por ejemplo, la arquitectura ISA-95/ de Purdue Network. En esta página se proporcionan algunos ejemplos para configurar un entorno de prueba en función de cómo desea lograr el aislamiento.

  • Segmentación física: las redes están separadas físicamente. En este caso, la administración de redes superpuestas (versión preliminar) debe implementarse en un host de NIC dual (tarjeta de interfaz de red) para conectarse a la red accesible desde Internet y a la red aislada.
  • Segmentación lógica: la red se segmenta lógicamente con configuraciones como VLAN, subred o firewall. La administración de red superpuesta tiene un único punto de conexión y está configurado para que sea visible para su propia capa de red y la capa aislada.

Ambos enfoques requieren configurar un DNS personalizado en la capa de red aislada para dirigir el tráfico de red a la instancia de Administración de redes superpuestas.

Importante

Los entornos de red descritos en la documentación de administración de redes en capas son ejemplos para probar la administración de redes en capas. No es una recomendación de cómo se compila la topología de red y clúster para producción.

Configuración de una red aislada con segmentación física

La siguiente configuración de ejemplo es una red aislada sencilla con dispositivos físicos mínimos.

Diagrama de una configuración de red aislada de dispositivo físico.

  • El punto de acceso inalámbrico se usa para configurar una red local y no proporciona acceso a Internet.
  • El clúster de nivel 4 es un clúster de nodo único hospedado en una máquina física de tarjeta de interfaz de red dual (NIC) que se conecta a Internet y a la red local.
  • El clúster de nivel 3 es un clúster de nodo único hospedado en una máquina física. Este clúster de dispositivos solo se conecta a la red local.

La administración de red en capas se implementa en el clúster de NIC dual. El clúster de la red local se conecta a La administración de redes superpuestas como proxy para acceder a los servicios de Azure y Arc. Además, necesitaría un DNS personalizado en la red local para proporcionar resolución de nombres de dominio y apuntar el tráfico a la administración de redes superpuestas. Para obtener más información, consulte Configuración de DNS personalizado.

Configuración de una red aislada con segmentación lógica

El diagrama siguiente se ilustra un entorno de red aislado en el que cada nivel se segmenta lógicamente con subredes. En este entorno de prueba, hay varios clústeres uno en cada nivel. Los clústeres pueden ser AKS Edge Essentials o K3S. El clúster de Kubernetes de la red de nivel 4 tiene acceso directo a Internet. Los clústeres de Kubernetes de nivel 3 y inferiores no tienen acceso a Internet.

Diagrama de una red aislada de segmentación lógica.

Los varios niveles de redes de esta configuración de prueba se realizan mediante subredes dentro de una red:

  • Subred de nivel 4 (10.104.0.0/16): esta subred tiene acceso a Internet. Todas las solicitudes se envían a los destinos de Internet. Esta subred tiene una sola máquina Windows 11 con la dirección IP 10.104.0.10.
  • Subred de nivel 3 (10.103.0.0/16): esta subred no tiene acceso a Internet y está configurada para que solo tenga acceso a la dirección IP 10.104.0.10 en el nivel 4. Esta subred contiene una máquina Windows 11 con la dirección IP 10.103.0.33 y una máquina Linux que hospeda un servidor DNS. El servidor DNS se configura siguiendo los pasos descritos en Configuración de DNS personalizado. Todos los dominios de la configuración DNS deben asignarse a la dirección 10.104.0.10.
  • Subred de nivel 2 (10.102.0.0/16): al igual que el nivel 3, esta subred no tiene acceso a Internet. Está configurado para que solo tenga acceso a la dirección IP 10.103.0.33 en el nivel 3. Esta subred contiene una máquina Windows 11 con la dirección IP 10.102.0.28 y una máquina Linux que hospeda un servidor DNS. Hay una máquina Windows 11 (nodo) en esta red con la dirección IP 10.102.0.28. Todos los dominios de la configuración DNS deben asignarse a la dirección 10.103.0.33.

Consulte los ejemplos siguientes para configurar este tipo de entorno de red.

Ejemplo de segmentación lógica con hardware mínimo

En este ejemplo, ambas máquinas están conectadas a un punto de acceso (AP) que se conecta a Internet. La máquina host de nivel 4 puede acceder a Internet. El host de nivel 3 está bloqueado y no puede acceder a Internet con la configuración del AP. Por ejemplo, firewall o control de cliente. Dado que ambas máquinas están en la misma red, la instancia de administración de red superpuesta hospedada en el clúster de nivel 4 está visible de forma predeterminada para el clúster y la máquina de nivel 3. Es necesario configurar un DNS personalizado adicional en la red local para proporcionar resolución de nombres de dominio y apuntar el tráfico a la administración de red superpuesta. Para obtener más información, consulte Configuración de DNS personalizado.

Diagrama de una configuración de red aislada lógica.

Ejemplo de segmentación lógica en Azure

En este ejemplo, se crea un entorno de prueba con una red virtual y una máquina virtual Linux en Azure.

Importante

El entorno virtual es solo para exploración y evaluación. Para más información, consulte Entornos admitidos para Operaciones de IoT de Azure.

  1. Cree una red virtual en su suscripción de Azure. Cree subredes para al menos dos capas (nivel 4 y nivel 3). Recorte de pantalla de una red virtual en Azure.
  2. Es opcional crear una subred adicional para la jumpbox o la máquina del desarrollador para acceder de forma remota a la máquina o al clúster entre capas. Esta configuración es cómoda si planea crear más de dos capas de red. De lo contrario, puede conectar la máquina jumpbox a la red de nivel 4.
  3. Cree grupos de seguridad de red para cada nivel y adjúntelos a la subred en consecuencia.
  4. Puede usar el valor predeterminado para el grupo de seguridad de nivel 4.
  5. Debe configurar reglas de seguridad adicionales de entrada y salida para el grupo de seguridad de nivel 3 (y nivel inferior).
    • Agregue reglas de seguridad de entrada y salida para denegar todo el tráfico de red.
    • Con una prioridad más alta, agregue reglas de seguridad entrantes y salientes para permitir el tráfico de red hacia y desde el intervalo IP de la subred de nivel 4.
    • [Opcional] Si crea una subred jumpbox, cree reglas de entrada y salida para permitir el tráfico hacia y desde esta subred. Recorte de pantalla del grupo de seguridad de nivel 3.
  6. Cree máquinas virtuales Linux en el nivel 3 y nivel 4.
    • Consulte Entornos admitidos para conocer la especificación de la máquina virtual.
    • Al crear la máquina virtual, conecte la máquina a la subred que se creó en los pasos anteriores.
    • Omita la creación del grupo de seguridad para la máquina virtual.

Configuración de DNS personalizado

Se necesita un DNS personalizado para el nivel 3 y posterior. Garantiza que la resolución DNS para el tráfico de red que se origina en el clúster apunta a la instancia de administración de redes superpuestas de nivel primario. En un entorno de producción o existente, incorpore las siguientes resoluciones DNS al diseño de DNS. Si desea configurar un entorno de prueba para el servicio de administración de redes superpuestas y Operaciones de IoT de Azure, puede consultar uno de los ejemplos siguientes.

Configure CoreDNS

Aunque la configuración de DNS se puede lograr de muchas maneras diferentes, en este ejemplo se usa un mecanismo de extensión proporcionado por CoreDNS que es el servidor DNS predeterminado para clústeres K3S. Las direcciones URL de la lista de permitidos, que deben resolverse, se agregan a CoreDNS.

Importante

El enfoque CoreDNS solo se aplica al clúster K3S en el host de Ubuntu en el nivel 3.

Creación de un mapa de configuración a partir de la administración de redes superpuestas de nivel 4

Después de que el clúster de nivel 4 y la administración de redes superpuestas estén listos, realice los pasos siguientes.

  1. Confirme la dirección IP del servicio administración de redes superpuestas con el siguiente comando:

    kubectl get services -n azure-iot-operations

    La salida debe tener un aspecto similar al siguiente. La dirección IP del servicio es 20.81.111.118.

    NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
lnm-level4   LoadBalancer   10.0.141.101   20.81.111.118   80:30960/TCP,443:31214/TCP   29s

  2. Vea los mapas de configuración con el comando siguiente:

    kubectl get cm -n azure-iot-operations

    La salida debería tener un aspecto similar al ejemplo siguiente:

    NAME                           DATA   AGE
aio-lnm-level4-config          1      50s
aio-lnm-level4-client-config   1      50s

  3. Personalice el aio-lnm-level4-client-config. Esta configuración es necesaria como parte de la configuración de nivel 3 para reenviar el tráfico desde el clúster de nivel 3 a la instancia de administración de redes superpuestas de nivel superior.

    # set the env var PARENT_IP_ADDR to the ip address of level 4 LNM instance.
  export PARENT_IP_ADDR="20.81.111.118"

# run the script to generate a config map yaml
  kubectl get cm aio-lnm-level4-client-config -n azure-iot-operations -o yaml | yq eval '.metadata = {"name": "coredns-custom", "namespace": "kube-system"}' -| sed 's/PARENT_IP/'"$PARENT_IP_ADDR"'/' > configmap-custom-level4.yaml

    Este paso crea un archivo denominado configmap-custom-level4.yaml

Configuración del nivel 3 CoreDNS de K3S

Después de configurar el clúster K3S y moverlo a la capa aislada de nivel 3, configure el CoreDNS de K3S de nivel 3 con la configuración de cliente personalizada que se generó anteriormente.

  1. Copie en configmap-custom-level4.yaml el host de nivel 3 o en el sistema donde acceda de forma remota al clúster.

  2. Ejecute los comandos siguientes:

    # Create a config map called coredns-custom in the kube-system namespace
kubectl apply -f configmap-custom-level4.yaml

# Restart coredns
kubectl rollout restart deployment/coredns -n kube-system

# validate DNS resolution
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net

# You should see the following output.
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net
Server:    10.43.0.10
Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local

Name:      east.servicebus.windows.net
Address 1: 20.81.111.118
pod "busybox" deleted

# Note: confirm that the resolved ip address matches the ip address of the level 4 Layered Network Management instance.

  3. El paso anterior establece la configuración de DNS para resolver las direcciones URL permitidas dentro del clúster en el nivel 4. Para asegurarse de que el DNS fuera del clúster está haciendo lo mismo, debe configurar el sistema resuelto para reenviar el tráfico a CoreDNS dentro del clúster K3S. Ejecute los siguientes comandos en el host K3S: Cree el directorio siguiente:

        sudo mkdir /etc/systemd/resolved.conf.d

    Cree un nuevo archivo denominado lnm.conf con el contenido siguiente. La dirección IP debe ser la dirección IP del clúster de nivel 3 del servicio kube-dns que se ejecuta en el espacio de nombres kube-system.

    [Resolve]
DNS=<PUT KUBE-DNS SERVICE IP HERE> 
DNSStubListener=no

    Reinicie la instancia de DNS Resolver:

    sudo systemctl restart systemd-resolved

Contenido relacionado

¿Qué es la administración de redes superpuestas de Azure IoT?