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

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 请求可能被中间设备静默丢弃。

快速验证：

• 在 initiator 上对 target IP 执行：ping -M do -s 1472 （1472 + 28 ICMP header = 1500）
• 若不通，逐步减小 -s 值（如 1400、1300），直到能通，得到路径最小 MTU
• 将 initiator 网卡 MTU 设为该值：ip link set dev mtu
• 重启 iscsid：systemctl restart iscsid，再试 login

注意：仅调大 initiator MTU 没用，必须整条路径一致；某些交换机或 SDN 控制面会强制分片但丢弃 DF 标志包，此时需关掉 PMTUD（net.ipv4.ip_no_pmtu_disc = 1）并手动设低 MTU。

iscsiadm login 时 target 返回重定向（Redirection）但 initiator 未处理

部分企业级存储（如 Netapp、Dell SC 系列）在多路径或负载均衡场景下，会在 login 响应中返回 REDIRECT 文本键，要求 initiator 连到另一个 IP:port。但老版本 open-iscsi（如 centos 7 自带的 2.0.873）默认不支持重定向，会卡在等待响应，最终超时。

检查方式：

• 用 tcpdump -i any port 3260 -w iscsi_login.pcap 抓包，wireshark 打开后过滤 iscsi.opcode == 0x03（Login Response），查看 payload 是否含 Redirect 或 TargetAddress 字段
• 升级 iscsi-initiator-utils 至 2.0.874+（RHEL 8+/CentOS 8+ 默认包含），或手动编译新版 open-iscsi
• 临时规避：在 target 端禁用重定向功能（如 NetApp 的 iscsi nodename redirect disable），或让 initiator 直连实际提供服务的节点 IP（绕过 VIP）

这个点容易被忽略——因为抓包里能看到 server 回了包，但 initiator 内核模块根本没解析重定向逻辑，就当没收到响应。