Compartir a través de

Prueba de la conectividad con el corredor MQTT con clientes MQTT

  • Artículo

Importante

En esta página se incluyen instrucciones para administrar componentes de Operaciones de IoT de Azure mediante manifiestos de implementación de Kubernetes, que se encuentra en versión preliminar. Esta característica se proporciona con varias limitacionesy no se debe usar para cargas de trabajo de producción.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

En este artículo se muestran diferentes formas de probar la conectividad con el corredor MQTT con clientes MQTT en un entorno de no producción.

De manera predeterminada, el corredor MQTT:

  • Implementa un cliente de escucha habilitado para TLS en el puerto 18883 con ClusterIp como tipo de servicio. ClusterIp significa que solo se puede acceder al agente desde el clúster de Kubernetes. Para acceder al agente desde fuera del clúster, debe configurar un servicio de tipo LoadBalancer o NodePort.

  • Acepta cuentas de servicio de Kubernetes para la autenticación de conexiones desde el clúster. Para conectarse desde fuera del clúster, debe configurar un método de autenticación diferente.

Precaución

En escenarios de producción, debe usar la autenticación de cuentas de servicio y TLS para proteger la solución de IoT. Para más información, vea:

Antes de comenzar, instale o configure operaciones de loT. Use las siguientes opciones para probar la conectividad con el corredor MQTT con clientes MQTT en un entorno de no producción.

Conexión al cliente de escucha predeterminado dentro del clúster

La primera opción es conectarse desde el clúster. Esta opción usa la configuración predeterminada y no requiere actualizaciones adicionales. En los ejemplos siguientes se muestra cómo conectarse desde dentro del clúster mediante Alpine Linux sin formato y un cliente MQTT usado habitualmente, mediante la cuenta de servicio y el certificado de entidad de certificación raíz predeterminado.

En primer lugar, cree un archivo denominado client.yaml con el código de configuración siguiente:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
---
apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  # Namespace must match MQTT broker BrokerListener's namespace
  # Otherwise use the long hostname: aio-broker.azure-iot-operations.svc.cluster.local
  namespace: azure-iot-operations
spec:
  # Use the "mqtt-client" service account created from above
  # Otherwise create it with `kubectl create serviceaccount mqtt-client -n azure-iot-operations`
  serviceAccountName: mqtt-client
  containers:
    # Mosquitto and mqttui on Alpine
  - image: alpine
    name: mqtt-client
    command: ["sh", "-c"]
    args: ["apk add mosquitto-clients mqttui && sleep infinity"]
    volumeMounts:
    - name: broker-sat
      mountPath: /var/run/secrets/tokens
    - name: trust-bundle
      mountPath: /var/run/certs
  volumes:
  - name: broker-sat
    projected:
      sources:
      - serviceAccountToken:
          path: broker-sat
          audience: aio-internal # Must match audience in BrokerAuthentication
          expirationSeconds: 86400
  - name: trust-bundle
    configMap:
      name: azure-iot-operations-aio-ca-trust-bundle # Default root CA cert

A continuación, use kubectl para implementar la configuración. Solo debe tardar unos segundos en iniciarse.

kubectl apply -f client.yaml

Una vez que se ejecuta el pod, use kubectl exec para ejecutar comandos dentro del pod.

Por ejemplo, para publicar un mensaje en el agente, abra un shell dentro del pod:

kubectl exec --stdin --tty mqtt-client --namespace azure-iot-operations -- sh

Dentro del shell del pod, ejecute el siguiente comando para publicar un mensaje en el agente:

mosquitto_pub --host aio-broker --port 18883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

La salida debe tener una apariencia similar a la siguiente:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

El cliente de mosquitto usa el token de cuenta de servicio montado en /var/run/secrets/tokens/broker-sat para autenticarse con el agente. El token es válido durante 24 horas. El cliente también usa el certificado de CA raíz predeterminado montado en /var/run/certs/ca.crt para comprobar la cadena de certificados TLS del agente.

Sugerencia

Puede usar kubectl para descargar el certificado de entidad de certificación raíz predeterminado para utilizarlo con otros clientes. Por ejemplo, para descargar el certificado de entidad de certificación raíz predeterminado en un archivo denominado ca.crt:

kubectl get configmap azure-iot-operations-aio-ca-trust-bundle -n azure-iot-operations -o jsonpath='{.data.ca\.crt}' > ca.crt

Para suscribirse al tema, ejecute el siguiente comando:

mosquitto_sub --host aio-broker --port 18883 --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

La salida debe tener una apariencia similar a la siguiente:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: world, QoS: 0, Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0

El cliente de mosquitto usa el mismo token de cuenta de servicio y certificado de CA raíz para autenticarse con el agente y suscribirse al tema.

Para quitar el pod, ejecute kubectl delete pod mqtt-client -n azure-iot-operations.

Conexión de clientes desde fuera del clúster

Dado que el cliente de escucha del corredor predeterminado se establece en el tipo de servicio ClusterIp, no se puede conectar al corredor desde fuera del clúster directamente. Para evitar interrupciones involuntarias en la comunicación entre los componentes internos de operaciones de IoT de Azure, se recomienda mantener el cliente de escucha predeterminado sin modificar y dedicado para la comunicación interna de AIO. Aunque es posible crear un servicio LoadBalancer de Kubernetes independiente para exponer el servicio IP del clúster, es mejor crear un cliente de escucha independiente con diferentes configuraciones, como el puerto MQTT 1883 y 8883 más común, para evitar confusiones y posibles riesgos de seguridad.

Puerto del nodo

La manera más fácil de probar la conectividad es usar el tipo de servicio NodePort en el cliente de escucha. Con eso, puede usar <nodeExternalIP>:<NodePort> para conectarse como en la documentación de Kubernetes.

Por ejemplo, para crear un agente de escucha con el tipo de servicio de puerto de nodo, el nombre del servicio aio-broker-nodeport, y la escucha en el puerto 1884 (puerto de nodo 31884):

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione Cliente de escucha de agente MQTT para NodePort>Create. Solo puede crear un cliente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente.

    Precaución

    Al establecer la autenticación en Ninguno y no configurar TLS , solo se desactiva la autenticación y TLS con fines de prueba.

    Escriba la siguiente configuración:

    Configuración Value
    Nombre aio-broker-nodeport
    Nombre del servicio Dejar vacío o aio-broker-nodeport
    Port 1884
    Autenticación Elija entre una existente o Ningun
    Autorización Elija entre una existente o Ningun
    Protocolo Elegir MQTT
    Puerto del nodo 31884

  4. Agregue la configuración de TLS al cliente de escucha seleccionando TLS>Agregar en el puerto. Este paso no es necesario si no necesita TLS para las pruebas. Para obtener más información, consulte BrokerListener.

  5. Seleccione Crear para crear el cliente de escucha.

Nota:

De forma predeterminada, el número de puerto de nodo debe estar en el intervalo 30000-32767.

Obtenga la dirección IP externa del nodo:

kubectl get nodes -o yaml | grep ExternalIP -C 1

La salida debe tener una apariencia similar a la siguiente:

    - address: 104.197.41.11
      type: ExternalIP
    allocatable:
--
    - address: 23.251.152.56
      type: ExternalIP
    allocatable:
...

Use la dirección IP externa y el puerto del nodo para conectarse al corredor. Por ejemplo, para publicar un mensaje en el corredor:

mosquitto_pub --host <EXTERNAL_IP> --port 31884 --message "hello" --topic "world" --debug # Add authentication and TLS options matching listener settings

Si no hay ninguna dirección IP externa en la salida, es posible que esté usando una configuración de Kubernetes que no exponga la dirección IP externa del nodo de forma predeterminada, como muchas configuraciones de k3s, k3d o minikube. En ese caso, puede acceder al corredor con la dirección IP interna junto con el puerto de nodo desde máquinas de la misma red. Por ejemplo, para obtener la dirección IP interna del nodo:

kubectl get nodes -o yaml | grep InternalIP -C 1

La salida debe tener una apariencia similar a la siguiente:

    - address: 172.19.0.2
      type: InternalIP
    allocatable:

A continuación, use la dirección IP interna y el puerto de nodo para conectarse al corredor desde una máquina dentro del mismo clúster. Si Kubernetes se ejecuta en una máquina local, como con k3s de nodo único, a menudo puede usar localhost en lugar de la dirección IP interna. Si Kubernetes se ejecuta en un contenedor de Docker, como con k3d, la dirección IP interna corresponde a la dirección IP del contenedor y debe ser accesible desde la máquina host.

Equilibrador de carga

Otra manera de exponer el corredor a Internet es usar el tipo de servicio LoadBalancer. Este método es más complejo y puede requerir una configuración adicional, como configurar el reenvío de puertos.

Por ejemplo, para crear un nuevo agente de escucha con el tipo de servicio del equilibrador de carga, el nombre del servicio aio-broker-loadbalancer, y la escucha en el puerto 1883:

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione Cliente de escucha de agente MQTT para NodePort>Create. Solo puede crear un cliente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente.

    Precaución

    Al establecer la autenticación en Ninguno y no configurar TLS , solo se desactiva la autenticación y TLS con fines de prueba.

    Escriba la siguiente configuración:

    Configuración Value
    Nombre aio-broker-loadbalancer
    Nombre del servicio Dejar vacío o aio-broker-loadbalancer
    Port 1883
    Autenticación Elija entre una existente o Ningun
    Autorización Elija entre una existente o Ningun
    Protocolo Elegir MQTT

  4. Agregue la configuración de TLS al cliente de escucha seleccionando TLS>Agregar en el puerto. Este paso no es necesario si no necesita TLS para las pruebas. Para obtener más información, consulte BrokerListener.

  5. Seleccione Crear para crear el cliente de escucha.

  6. Seleccione Crear para crear el cliente de escucha.

Obtenga la dirección IP externa para el servicio del agente:

kubectl get service aio-broker-loadbalancer --namespace azure-iot-operations

Si la salida es similar a la siguiente:

NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer   LoadBalancer   10.x.x.x        x.x.x.x       1883:30382/TCP   83s

Esto significa que se ha asignado una dirección IP externa al servicio del equilibrador de carga y puede usar la dirección IP externa y el puerto para conectarse al corredor. Por ejemplo, para publicar un mensaje en el corredor:

mosquitto_pub --host <EXTERNAL_IP> --port 1883 --message "hello" --topic "world" --debug # Add authentication and TLS options matching listener settings

Si no se asigna la dirección IP externa, es posible que tenga que usar el reenvío de puertos o un conmutador virtual para acceder al corredor.

Uso del reenvío de puertos

Con minikube, kind y otros sistemas de emulación de clúster, es posible que no se asigne automáticamente una dirección IP externa. Por ejemplo, podría mostrarse como estado Pendiente.

  1. Para acceder al agente, reenvíe el puerto de escucha del agente al host.

    # Using aio-broker-loadbalancer service name and listener port 1883 as example
kubectl port-forward --namespace azure-iot-operations service/aio-broker-loadbalancer <HOST_PORT>:1883

  2. Deje el comando de reenvío de puertos en ejecución en el terminal.

  3. Conéctese al atente en el puerto del host con la misma autenticación y configuración de TLS que la del ejemplo sin reenvío de puertos.

Para más información sobre minikube, vea Uso del enrutamiento de puerto para acceder a aplicaciones en un clúster

Enrutamiento de puerto en AKS Edge Essentials

Para Edge Essentials de Azure Kubernetes Services, debe realizar algunos pasos adicionales. Con AKS Edge Essentials, la obtención de la dirección IP externa puede no ser suficiente para conectarse al corredor. Es posible que tenga que configurar el reenvío de puertos y abrir el puerto en el firewall para permitir el tráfico al servicio del corredor.

  1. En primer lugar, obtenga la dirección IP externa del cliente de escucha del equilibrador de carga:

    kubectl get service broker-loadbalancer --namespace azure-iot-operations

    La salida debe tener una apariencia similar a la siguiente:

    NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
broker-loadbalancer     LoadBalancer   10.x.x.x       192.168.0.4   1883:30366/TCP   14h

  2. Configure el enrutamiento de puerto al servicio broker-loadbalancer en la dirección IP externa 192.168.0.4 y el puerto 1883:

    netsh interface portproxy add v4tov4 listenport=1883 connectport=1883 connectaddress=192.168.0.4

  3. Abra el puerto en el firewall para permitir el tráfico al servicio del agente:

    New-NetFirewallRule -DisplayName "AIO MQTT Broker" -Direction Inbound -Protocol TCP -LocalPort 1883 -Action Allow

  4. Use la dirección IP pública del host para conectarse al agente MQTT.

Para más información sobre el enrutamiento de puerto, vea Exposición de servicios de Kubernetes a dispositivos externos.

Acceso a través de localhost

Algunas distribuciones de Kubernetes pueden exponer el corredor MQTT a un puerto en el sistema host (localhost) como parte de la configuración del clúster. Utilice este enfoque para facilitar que los clientes del mismo host accedan al corredor MQTT.

Por ejemplo, para crear un clúster K3d con la asignación del puerto MQTT predeterminado del corredor MQTT 1883 a localhost:1883:

k3d cluster create --port '1883:1883@loadbalancer'

O bien, para actualizar un clúster existente:

k3d cluster edit <CLUSTER_NAME> --port-add '1883:1883@loadbalancer'

A continuación, use localhost y el puerto para conectarse al corredor. Por ejemplo, para publicar un mensaje en el corredor:

mosquitto_pub --host localhost --port 1883 --message "hello" --topic "world" --debug # Add authentication and TLS options matching listener settings

Desactivación solo de TLS y de la autenticación con fines pruebas

La razón por la que el corredor MQTT usa la autenticación TLS y las cuentas de servicio de forma predeterminada es proporcionar una experiencia segura de manera predeterminada que minimiza la exposición involuntaria de la solución de IoT a los atacantes. No debe desactivar TLS ni la autenticación en producción. Exponer el corredor MQTT a Internet sin autenticación y TLS puede provocar accesos no autorizados e incluso ataques DDOS.

Advertencia

Si comprende los riesgos y necesita usar un puerto no seguro en un entorno bien controlado, puede desactivar TLS y la autenticación con fines de prueba eliminando los ajustes tls y authenticationRef de la configuración del cliente de escucha.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione agente de escucha de agente MQTT para NodePort o agente de escucha de agente MQTT para LoadBalancer>Crear. Solo puede crear un cliente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente.

    Precaución

    Al establecer la autenticación en Ninguno y no configurar TLS , solo se desactiva la autenticación y TLS con fines de prueba.

    Escriba la siguiente configuración:

    Configuración Value
    Nombre Escriba un nombre para el cliente de escucha
    Nombre del servicio Escriba un nombre de servicio
    Port Escriba un número de puerto
    Autenticación Elija Ninguno.
    Authorization Elija Ninguno.
    Protocolo Elegir MQTT
    Puerto del nodo Escriba un número entre 30000-32767 si usa el puerto de nodo.

  4. Seleccione Crear para crear el cliente de escucha.

Contenido relacionado