MQTTX与EMQX在EKS集群中的TCP连接问题排查指南

问题背景

在使用MQTTX客户端连接部署在AWS EKS集群中的EMQX消息中间件时，开发人员遇到了TCP连接建立但MQTT协议握手失败的问题。具体表现为MQTTX客户端能够完成TCP三次握手，但在发送MQTT CONNECT报文后无法收到服务端响应，最终导致连接超时。

环境配置

该环境包含以下关键组件：

1. EMQX集群：版本5.7.1，部署在EKS中
2. Kong API网关：作为入口控制器，配置了TCPIngress资源
3. 网络负载均衡器(NLB)：提供外部访问入口
4. MQTTX客户端：用于测试MQTT连接

问题现象

开发人员观察到以下具体现象：

1. 使用telnet测试1883端口连通性成功
2. MQTTX客户端日志显示TCP连接建立但MQTT握手超时
3. EMQX的dashboard中相关连接指标(client.connect)没有增长
4. 通过WebSocket端口连接测试却能正常工作

技术分析

通过对TCP抓包数据的深入分析，我们发现以下关键点：

1. TCP层行为正常：

   • 完整的三次握手过程
   • 客户端能够成功发送TCP数据包

2. 应用层问题：

   • MQTT CONNECT报文发出后未收到ACK确认
   • 客户端多次重传后最终收到RST复位报文
   • 服务端似乎从未"看到"这些MQTT协议包

3. 协议差异：

   • 失败的测试使用原生MQTT over TCP(1883端口)
   • 成功的测试使用MQTT over WebSocket(不同端口)

根本原因

经过排查，确定问题出在Kong网关的配置上：

1. SSL证书配置冲突：

   • 在TCPIngress中不必要地配置了SSL相关注解
   • 导致TCP流量被错误地尝试进行TLS解密

2. 协议处理不当：

   • 纯TCP流量被当作TLS流量处理
   • 网关无法正确解析MQTT协议导致连接中断

解决方案

1. 清理Kong配置：

   • 移除TCPIngress中与SSL相关的注解
   • 确保纯TCP流量不被TLS处理层拦截

2. 配置验证步骤：

   • 使用telnet验证基础TCP连通性
   • 通过tcpdump确认MQTT协议包传输情况
   • 逐步测试从简单到复杂的协议交互

经验总结

1. 协议栈理解：

   • 明确区分传输层(TCP)和应用层协议(MQTT)
   • 认识到中间件可能在不同协议层进行干预

2. 排查方法论：

   • 从下至上逐层排查(网络→传输→应用)
   • 对比测试不同协议变体(如TCP vs WebSocket)

3. 云环境特殊性：

   • EKS中的网络组件可能引入额外处理层
   • 负载均衡器配置需要与后端服务协议匹配

最佳实践建议

1. 配置管理：

   • 保持Ingress配置与后端服务协议一致
   • 避免在TCP服务上配置不必要的TLS参数

2. 监控体系：

   • 在关键节点部署流量嗅探点
   • 建立端到端的协议健康检查机制

3. 测试策略：

   • 先验证基础网络连通性
   • 再测试简单应用协议交互
   • 最后进行完整业务场景测试

通过这次问题排查，我们不仅解决了具体的连接问题，更重要的是建立了一套在复杂云环境中诊断MQTT通信问题的系统化方法。这对于后续在Kubernetes环境中部署物联网消息中间件具有重要的参考价值。