iSCSItarget连接超时解决方法

本文深入剖析了iSCSI连接中“discovery成功但login超时”这一常见疑难问题的根本原因：discovery（SendTargets）不触发CHAP认证，仅依赖网络可达性，而login阶段才严格校验CHAP凭据、initiatorname授权及mutual CHAP配置的一致性；超时往往并非网络故障，而是因用户名、initiatorname大小写或空格不匹配、target端ACL未授权、mutual CHAP反向凭证缺失或开关逻辑错误（如mutual_chap=Yes却未在initiator配置username_in）导致target静默丢包；文章还提供了缩短登录超时、实时内核日志监控和tcpdump抓包分析等三步精准排错方法，助你快速定位并解决看似神秘的iSCSI连接失败问题。

为什么 discovery 成功但 login 超时

根本原因是 CHAP 认证在 iSCSI login 阶段才触发，而 discovery（即 iscsiadm -m discovery）走的是不带认证的 SendTargets 流程。即使 target 配置了 auth_type = CHAP 或 mutual_chap = Yes，discovery 仍能成功——它只看网络可达性和 target 是否响应 SendTargets 请求，完全绕过用户/密码校验。

login 超时（常见表现为 iscsiadm -m node -l 卡住 60 秒后报 connection timed out 或 session login timeout）往往不是网络问题，而是 CHAP 凭据不匹配、initiator 名称未被 target 显式授权、或 mutual CHAP 的反向凭证缺失导致 target 主动丢弃连接请求。

CHAP 用户名和 initiatorname 必须与 target 端严格一致

target（如 tgt、lio、scst）通常按 initiatorname + username 组合做 ACL 授权。哪怕只差一个空格或大小写，login 就会静默失败并最终超时。

• /etc/iscsi/initiatorname.iscsi 中的 InitiatorName 值必须和 target 配置里白名单中的 initiator 名完全一致（例如 iqn.1993-08.org.debian:01:abcd1234）
• CHAP username（iscsiadm -m node -o update -n node.session.auth.username -v "alice"）必须与 target 端为该 initiator 配置的 username 字段一模一样
• mutual CHAP 的 username_in（即 target 用来验证 initiator 的用户名）也必须匹配，且 target 必须明确启用 mutual_chap 并填入对应密码

target 端配置中 auth_type 和 mutual_chap 的开关逻辑

以 Linux 内核 LIO（targetcli）为例：auth_type 控制是否启用单向 CHAP；mutual_chap 是独立开关，仅当设为 Yes 且 auth_type = CHAP 时才启用双向认证。二者不是“或”关系，而是嵌套依赖。

• auth_type = None：即使设置了 username/password，login 也不会触发 CHAP，但若 target 强制要求认证，login 会被拒绝（非超时）
• auth_type = CHAP + mutual_chap = No：仅 target 验证 initiator，initiator 不验证 target
• auth_type = CHAP + mutual_chap = Yes：双方互相验证，此时 initiator 必须设置 node.session.auth.username_in 和 node.session.auth.password_in，且 target 端需配置 userid_in 和 password_in

错误配置如 mutual_chap = Yes 但 initiator 没配 username_in，会导致 target 等待 initiator 发起 mutual 验证，超时断连。

debug login 过程的三个关键命令

不要只看 iscsiadm -m node -l 的返回码。超时类问题必须抓底层交互：

• 开启 debug 日志：iscsiadm -m node -T -p --op=update -n node.session.timeo.login_timeout -v 15（先缩短超时便于测试）
• 查看实时日志：sudo dmesg -w | grep -i "iscsi\|chap"，重点关注 chap response mismatch 或 rejecting login
• 抓包确认流程：sudo tcpdump -i any -s 0 port 3260 -w iscsi-login.pcap，用 Wireshark 打开后过滤 iscsi.opcode == 0x03（Login Request），检查其中的 Username、Password、AuthMethod 字段是否符合预期

CHAP 密码不会明文出现在包里，但 AuthMethod 和 Challenge/Response 的长度、是否含 mutual flag 可直接判断握手阶段卡在哪一步。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~