如何通过Azure Firewall暴露Azure ARO上的Mosquitto MQTT服务

• 需求：将运行在私有Azure Red Hat OpenShift（ARO）集群上的Mosquitto MQTT服务，通过Azure Firewall经TLS协议暴露至公网，该方案可复用到所有部署Mosquitto的私有OpenShift集群场景。
• 访问约束：根据Red Hat官方文档说明，服务采用TLS加密模式时，客户端必须通过OpenShift透传路由器分配的主机名访问MQTT服务，核心依赖是透传路由需要通过TLS握手中的SNI（服务器名称指示）字段匹配对应后端服务Pod。
• 已完成内网验证：在与ARO同属一个VNet的虚拟机上，使用mosquitto_pub/sub客户端已验证服务可正常连通。测试命令如下，其中*--host*参数为核心必填项，作用是让OpenShift透传路由器定位到承载对应服务的Pod：

mosquitto_pub -t foo -m "text" --cafile mosquitto_ca.crt \
--insecure -u admin -P admin --host mosquitto.apps.my_domain --port 443

• 配置Azure Firewall DNAT规则开放公网入站时，发现DNAT规则的目标地址不支持填写FQDN，仅可填写集群负载均衡器IP作为转发目标。
• 直接配置IP转发会触发TLS连接报错：客户端用IP访问时TLS握手不会携带对应服务域名的SNI字段，OpenShift透传路由器无法识别需要转发的目标服务，导致连接失败。

1. 如何通过Azure Firewall暴露这类依赖SNI匹配的OpenShift透传路由服务？
2. Azure Firewall是否支持入站流量的目标地址配置为FQDN？

• 方案偏好：备选方案为使用支持Websocket协议的Application Gateway，但MQTT属于非HTTP流量，且Azure Firewall具备更强的流量管控能力，因此优先期望基于Azure Firewall实现需求。

关于入站FQDN配置能力的明确说明 #

Azure Firewall 所有正式版本（基础/标准/高级）的DNAT规则均不支持入站方向将目标地址设置为FQDN，仅出站方向的网络规则、应用规则支持FQDN过滤，这是产品当前的固定功能边界。

基于Azure Firewall暴露透传路由的可行方案 #

无需替换为Application Gateway，通过Azure Firewall高级版的入站TLS SNI匹配能力即可实现需求，全程不需要修改OpenShift侧现有透传路由配置，具体配置步骤如下：

• 为Azure Firewall分配独立公网IP，在公网DNS服务商处为MQTT服务域名mosquitto.apps.my_domain添加A记录，解析到该防火墙公网IP。
• 在Azure Firewall高级版的防火墙策略中开启入站TLS检查，导入MQTT服务对应的服务端证书，配置SNI匹配规则：当入站TLS握手携带的SNI字段值为mosquitto.apps.my_domain时，直接将流量以TCP透传模式转发到ARO集群负载均衡器的443端口，不在防火墙层做TLS卸载/重加密，保留端到端TLS透传逻辑，完全适配OpenShift透传路由的转发要求。
• 配套配置四层DNAT规则，将目标为防火墙公网IP、443端口的TCP流量全部送入上述TLS SNI规则链做分流，匹配到MQTT域名的流量正常转发，其余未匹配流量按默认安全策略拦截即可。

客户端侧不需要做特殊调整，保持原有连接参数即可：--host参数仍填原有MQTT服务域名，证书配置、账号密码配置和内网测试时完全一致，不会触发证书域名不匹配、SNI缺失类报错。

降级适配方案 #

如果当前使用的是Azure Firewall标准/基础版，没有入站TLS检查能力，可以在Azure Firewall和ARO集群之间部署一层轻量四层TCP反向代理（如HAProxy、Nginx Stream模块），由代理层负责识别TLS握手中的SNI字段做流量转发，Azure Firewall只需要做四层DNAT将公网443端口流量转发到代理地址即可。该方案会增加一层运维节点，仅作为高级版功能不可用时的备选。

内容的提问来源于stack exchange，提问作者shaswata pal