Prueba de la conectividad con el corredor MQTT con clientes MQTT

Artículo
02/10/2025

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 un corredor MQTT con clientes MQTT en un entorno que no es de producción.

De manera predeterminada, cualquier corredor MQTT:

Implementa un agente de escucha habilitado para el protocolos de seguridad de la capa de transporte (TLS) en el puerto 18883 con ClusterIp como tipo de servicio. ClusterIp significa que solo se puede acceder al corredor desde el clúster de Kubernetes. Para acceder al corredor desde fuera del clúster, debe configurar un servicio de los tipos 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, use la autenticación de cuentas de servicio y TLS para proteger la solución de IoT. Para más información, vea:

Configuración de TLS con administración automática de certificados para proteger la comunicación de MQTT en el corredor MQTT.
Configuración de la autenticación en el corredor MQTT.
Exposición de los servicios de Kubernetes a dispositivos externos mediante el reenvío de puertos o un conmutador virtual con Azure Kubernetes Services (AKS) Edge Essentials.

Antes de comenzar, instale o configure Operaciones de IoT de Azure. 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 (CA) predeterminado.

Descargue la implementación de mqtt-client.yaml del repositorio de ejemplo de GitHub.

Importante

No use el cliente MQTT en producción. El cliente solo tiene fines de prueba.

wget https://raw.githubusercontent.com/Azure-Samples/explore-iot-operations/main/samples/quickstarts/mqtt-client.yaml -O mqtt-client.yaml

Aplique el archivo de implementación con kubectl:

kubectl apply -f mqtt-client.yaml

pod/mqtt-client created

Después de que se ejecute el pod, use kubectl exec para ejecutar comandos dentro de él.

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 debería tener un aspecto similar al ejemplo 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 la 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 entidad de certificación 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 debería tener un aspecto similar al ejemplo 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 entidad de certificación 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

Como 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, se recomienda mantener el cliente de escucha predeterminado sin modificar y dedicado para la comunicación interna de Operaciones de IoT. Aunque se puede 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 los puertos 1883 y 8883 de MQTT más comunes, 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 ese método, puede usar <nodeExternalIP>:<NodePort> para conectarse como se muestra en la documentación de Kubernetes.

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

En Azure Portal, vaya a la instancia de operaciones de IoT.
En Componentes, seleccione MQTT Broker.

Seleccione Cliente de escucha de agente MQTT para NodePort>Create. Solo puede crear un agente 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	Valor
Nombre	`aio-broker-nodeport`
Nombre del servicio	Déjelo vacío o use `aio-broker-nodeport`.
Port	1884
Autenticación	Elija entre una existente o No.
Authorization	Elija entre una existente o No.
Protocolo	Elija MQTT.
Puerto del nodo	31884

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.
Seleccione Crear para crear el cliente de escucha.

Precaución

La eliminación de los valores authenticationRef y tls de la configuración de desactiva la autenticación y TLS sólo con fines de prueba.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-nodeport'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource nodePortListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    serviceType: 'NodePort'
    ports: [
      {
        port: 1884
        nodePort: 31884 // Must be in the range 30000-32767
        authenticationRef: 'default' // Add BrokerAuthentication reference, omit setting turns off authentication for testing only
        tls: {
          // Add TLS settings
          // Omitting section turns off TLS for testing only
        }
      }
    ]
  }
}

Implemente el archivo de Bicep mediante la CLI de Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Cree un archivo denominado broker-nodeport.yaml con el código de configuración siguiente. Reemplace los marcadores de posición por sus propios valores, incluida su propia autenticación y configuración de TLS.

Precaución

La eliminación de los valores authenticationRef y tls de la configuración de desactiva la autenticación y TLS sólo con fines de prueba.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-nodeport
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: NodePort
  ports:
    - port: 1883
      nodePort: 31884 # Must be in the range 30000-32767
      authenticationRef: default # Add BrokerAuthentication reference, omit setting turns off authentication for testing only
      tls:
        # Add TLS settings
        # Omitting section turns off TLS for testing only

Luego, use kubectl para implementar la configuración:

kubectl apply -f broker-nodeport.yaml

Nota:

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

Obtenga la dirección IP externa del nodo:

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

La salida debería tener un aspecto similar al ejemplo 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 debería tener un aspecto similar al ejemplo 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 forma de exponer el corredor a Internet es usar el tipo de servicio LoadBalancer. Este método es más complejo y puede requerir que se configuren más elementos, como el reenvío de puertos.

Por ejemplo, para crear un cliente de escucha del corredor con el tipo de servicio LoadBalancer, el nombre del servicio aio-broker-loadbalancer y la escucha en el puerto 1883, siga estos pasos.

En Azure Portal, vaya a la instancia de operaciones de IoT.
En Componentes, seleccione MQTT Broker.

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	Valor
Nombre	`aio-broker-loadbalancer`
Nombre del servicio	Déjelo vacío o use `aio-broker-loadbalancer`.
Port	1883
Autenticación	Elija entre una existente o No.
Authorization	Elija entre una existente o No.
Protocolo	Elija MQTT.

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.
Seleccione Crear para crear el cliente de escucha.
Seleccione Crear para crear el cliente de escucha.

Precaución

La eliminación de los valores authenticationRef y tls de la configuración de desactiva la autenticación y TLS sólo con fines de prueba.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        authenticationRef: 'default' // Add BrokerAuthentication reference, omit setting turns off authentication for testing only
        tls: {
          // Add TLS settings
          // Omitting section turns off TLS for testing only
        }
      }
    ]
  }
}

Implemente el archivo de Bicep mediante la CLI de Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Precaución

La eliminación de los valores authenticationRef y tls de la configuración de desactiva la autenticación y TLS sólo con fines de prueba.

Cree un archivo denominado broker-loadbalancer.yaml cuya configuración sea como la del siguiente ejemplo. Reemplace los marcadores de posición por sus propios valores, incluida su propia autenticación y configuración de TLS.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
    - port: 1883
      authenticationRef: default # Add BrokerAuthentication reference, omit setting turns off authentication for testing only
      tls:
        # Add TLS settings
        # Omitting section turns off TLS for testing only

Use kubectl para implementar la configuración:

kubectl apply -f broker-loadbalancer.yaml

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 del siguiente ejemplo:

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

Luego, se asignó una IP externa al servicio del equilibrador de carga. Puede usar 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 1883 --message "hello" --topic "world" --debug # Add authentication and TLS options matching listener settings

Si no se asigna la 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, el estado podría mostrarse como Pendiente.

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

Deje el comando de reenvío de puertos en ejecución en el terminal.
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, consulte Uso del enrutamiento de puerto para acceder a aplicaciones en un clúster.

Enrutamiento de puerto en AKS Edge Essentials

Para AKS Edge Essentials, debe dar varios pasos más. 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.

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 ser similar al siguiente ejemplo:

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

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
```

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

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 que asigne el puerto 1883 de MQTT predeterminado del corredor MQTT 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 de denegación de servicio distribuidos.

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.

En Azure Portal, vaya a la instancia de operaciones de IoT.
En Componentes, seleccione MQTT Broker.

Seleccione agente de escucha de agente MQTT para NodePort o agente de escucha de agente MQTT para LoadBalancer>Crear. Solo puede crear un agente 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	Valor
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	Elige Ninguno.
Authorization	Elige Ninguno.
Protocolo	Elija MQTT.
Puerto del nodo	Escriba un número entre 30000 y 32767 si usa el puerto de nodo.

Seleccione Crear para crear el cliente de escucha.

Precaución

La eliminación de los valores authenticationRef y tls de la configuración de desactiva la autenticación y TLS sólo con fines de prueba.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource nodePortListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: <SERVICE_TYPE> // 'LoadBalancer' or 'NodePort'
    ports: [
      {
        port: <PORT_NUMBER>
        nodePort: <PORT_NUMBER_BETWEEN_30000_32767> // If using NodePort
        // Omitting authenticationRef and tls for testing only
      }
    ]
  }
}

Implemente el archivo de Bicep mediante la CLI de Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: <SERVICE_TYPE> # LoadBalancer or NodePort
  ports:
    - port: <PORT_NUMBER>
      nodePort: <PORT_NUMBER_BETWEEN_30000_32767> # If using NodePort
      # Omitting authenticationRef and tls for testing only

Compartir vía

Prueba de la conectividad con el corredor MQTT con clientes MQTT

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

Conexión de clientes desde fuera del clúster

Puerto del nodo

Equilibrador de carga

Uso del reenvío de puertos

Enrutamiento de puerto en AKS Edge Essentials

Acceso a través de localhost

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

Comentarios

Recursos adicionales

Compartir vía

Prueba de la conectividad con el corredor MQTT con clientes MQTT

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

Conexión de clientes desde fuera del clúster

Puerto del nodo

Equilibrador de carga

Uso del reenvío de puertos

Enrutamiento de puerto en AKS Edge Essentials

Acceso a través de localhost

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

Contenido relacionado

Comentarios

Recursos adicionales