iSCSI存储的使用过程中，discovery阶段可以正常扫描到target，但后续发起连接时出现超时，是运维场景中比较常见的问题，这类问题大多和CHAP或者mutual CHAP认证配置不当有关。
iSCSI discovery与连接阶段的认证差异
iSCSI的discovery阶段和正式连接阶段是独立的流程，discovery默认不需要认证，或者仅使用独立的discovery认证配置，而target连接阶段使用的是target专属的CHAP认证配置，这也是为什么会出现discovery成功但连接超时的核心原因。
discovery阶段的作用是让initiator获取target的列表，而连接阶段是initiator和target建立会话，传输存储数据，两个阶段的认证配置是分开管理的，很多用户会混淆这两部分的配置，导致连接失败。
CHAP配置常见问题排查
单向CHAP认证只需要target验证initiator的身份，常见配置错误有以下几类：
- initiator配置的CHAP用户名和密码和target端配置的不一致，包括大小写、特殊字符的差异
- target端没有给对应的initiator开放CHAP认证权限，或者绑定的initiator IQN不正确
- initiator端没有开启CHAP认证开关，或者错误地将CHAP配置放到了discovery配置段
CHAP配置示例（Linux initiator端）
以下是iscsiadm配置单向CHAP的正确方式：
# 先发现target，discovery阶段如果不需要认证可以直接执行 iscsiadm -m discovery -t st -p 192.168.0.100:3260 # 配置目标target的CHAP认证信息，假设target的IQN是iqn.2023-01.com.test:storage iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.username -v initiator_user iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.password -v initiator_pass123 # 发起连接 iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --login
mutual CHAP配置常见问题排查
mutual CHAP是双向认证，target需要验证initiator，initiator也需要验证target，配置复杂度更高，错误点更多：
- 遗漏了双向认证的配置项，只配置了单向CHAP就开启了mutual CHAP模式
- target端和initiator端配置的相互认证用户名密码不匹配，比如target端的反向认证密码和initiator配置的目标认证密码不一致
- mutual CHAP的认证用户名和单向CHAP的用户名混淆，两类认证可以使用不同的账号，很多用户会误以为必须相同
mutual CHAP配置示例（Linux initiator端）
# 先配置单向CHAP的基础信息 iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.authmethod -v CHAP iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.username -v initiator_user iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.password -v initiator_pass123 # 配置mutual CHAP的反向认证信息，target会向initiator提供用户名和密码验证 iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.username_in -v target_user iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --op update -n node.session.auth.password_in -v target_pass456 # 发起连接 iscsiadm -m node -T iqn.2023-01.com.test:storage -p 192.168.0.100:3260 --login
通用排查步骤
如果确认配置无误还是连接超时，可以按照以下步骤排查：
- 查看initiator端的日志，Linux系统下可以查看/var/log/messages或者journalctl -u iscsid，日志会明确提示认证失败的原因
- 查看target端的认证日志，比如tgt服务的日志，确认是否有收到认证请求以及认证失败的具体原因
- 临时关闭CHAP认证测试连接是否正常，如果关闭后可以连接，说明问题一定在认证配置上，再逐步还原配置定位错误点
- 检查网络是否有ACL限制，部分环境会限制3260端口的双向流量，导致认证报文传输异常引发超时
常见配置错误对照表
| 错误现象 | 可能原因 | 解决方法 |
|---|---|---|
| discovery成功，连接超时 | CHAP用户名密码不匹配 | 核对target和initiator的CHAP账号密码 |
| discovery成功，连接提示认证失败 | mutual CHAP反向认证配置缺失 | 补充username_in和password_in配置 |
| discovery成功，连接超时无明确报错 | initiator IQN和target绑定的IQN不一致 | 更新target端绑定的initiator IQN |
iSCSICHAPmutual_CHAPtarget连接超时discovery成功修改时间：2026-06-17 16:15:50