iSCSI initiator 连接目标超时但 iscsiadm discovery 正常的网络/CHAP 排查-SQL

iSCSI login超时常见原因有四：目标未监听3260端口（需ss确认LISTEN且绑定0.0.0.0）、CHAP认证失败静默超时（检查iscsid.conf及用户名密码）、MTU不匹配导致握手包丢弃（用ping -M do测试路径MTU）、target返回Redirect但initiator版本过低不支持（需升级open-iscsi至2.0.874+）。

iscsiadm discovery 成功但 login 超时，先确认目标是否真在监听 3260

Discovery 只走 SendTargets 查询（UDP 或 TCP），不建立完整会话；login 才真正尝试建 TCP 连接并完成登录握手。所以 discovery 正常 ≠ 目标 iSCSI 服务就绪。

在目标端执行：

ss -tlnp | grep :3260

确认输出中包含 iscsid 或 tgtd（取决于后端实现）且状态为 LISTEN。若只看到 127.0.0.1:3260，说明服务绑定在本地回环——需改配置绑定 0.0.0.0 或具体网卡 IP。

• Linux tgtd：检查 /etc/tgt/conf.d/*.conf 中 ip_address 是否设为实际监听地址
• Linux LIO（targetcli）：运行 targetcli ls /iscsi，确认 tpg1/portals 下的 portal 地址不是 127.0.0.1
• 防火墙必须放行 3260/tcp，不只是 discovery 用的 UDP 端口（如 3260/udp 或 860/udp）

CHAP 认证失败不会报“认证错误”，而是静默超时

iSCSI initiator 在 CHAP 阶段出错（比如用户名错、密码错、反向 CHAP 未配）时，多数内核模块（如 libiscsi）不会返回明确错误，而是等待超时后断开连接——表现为 iscsiadm -m node -T --login 卡住 60 秒后报 connection timed out。

排查方法：

• 在 initiator 上启用调试日志：echo "file drivers/scsi/libiscsi.c +p" > /sys/kernel/debug/dynamic_debug/control，再试 login，然后 dmesg | tail -30 查看是否有 chap response mismatch 或 auth failed 类提示
• 确认 /etc/iscsi/iscsid.conf 中以下几项是否显式设置（不能依赖注释默认值）：
  node.session.auth.authmethod = CHAP
node.session.auth.username =
node.session.auth.password =
node.session.auth.username_in =
node.session.auth.password_in =
• 目标端 CHAP 用户名必须与 initiator 发送的 username_in 完全一致（大小写敏感），且密码长度不能超过 16 字符（部分 tgt 实现限制）

MTU 不匹配导致 login 握手包被丢弃

iSCSI 对网络质量敏感，尤其是 login 阶段的文本协商（Text Key Exchange）可能生成较大初始 PDU。若 initiator 和 target 间某段链路 MTU 小于 1500（例如 GRE 隧道、VLAN、某些云厂商 overlay 网络），而两端网卡又没开启 jumbo frame 或路径 MTU 发现（PMTUD），login 请求可能被中间设备静默丢弃。