审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
iSCSI登录超时需分四步排查：先验证目标端3260端口可达及服务状态；再检查CHAP认证配置一致性；接着排除防火墙与中间网络设备干扰；最后核查会话参数、内核日志及协议兼容性。
确认目标端服务状态与端口可达性
虽然 iscsiadm -m discovery 能成功发现目标（说明 TCP 3260 端口在发现阶段可通），但连接超时往往发生在登录（login）阶段，此时需建立完整 iSCSI 会话。先验证目标 IP 和端口是否真正可达：
- 使用 telnet 或 nc -zv 测试端口连通性（注意：部分目标启用 CHAP 后可能对未认证连接快速拒绝，telnet 成功不等于 login 成功）；
- 检查目标端 iscsid 或 target service（如 tgt、lio、scst）是否运行且监听在对应 IP/端口，例如 ss -tlnp | grep :3260；
- 确认目标未配置 ACL 限制发起端 IQN，或仅允许特定网络访问（常见于企业存储设备 Web 界面中的“允许主机”或“Initiator ACL”设置）。
检查发起端 CHAP 认证配置一致性
Discovery 通常不触发认证，而 Login 必须完成 CHAP（如果目标启用）。若目标要求双向或单向 CHAP，但发起端未正确配置，就会静默超时：
- 查看目标是否启用 CHAP：在目标端检查配置（如 tgt 中
- 在发起端确认 /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）；
- 执行 iscsiadm -m node -T 等命令同步配置后，再用 --login 尝试。
排查防火墙与中间网络设备干扰
Discovery 使用 SendTargets（UDP 3260 或 TCP 3260），Login 则依赖稳定长连接的 TCP 会话，更易受中间策略影响：
- 发起端和目标端的本地防火墙（如 firewalld、iptables）需放行 TCP 3260 入/出方向；
- 若跨网段或经交换机/路由器，确认无 ACL、QoS 限速、TCP MSS 调整或连接跟踪老化（如 netfilter conntrack timeout 过短）；
- 特别注意：某些安全设备或云平台（如 AWS Security Group、阿里云安全组）默认只放行 discovery 端口，未显式放行 login 流量（仍是 3260，但需保持连接）；
- 可临时关闭两端防火墙测试，或用 tcpdump -i any port 3260 抓包观察 login 请求是否发出、有无 SYN_ACK、是否被 RST。
验证 iSCSI 会话参数与内核兼容性
部分超时源于参数协商失败或驱动异常：
- 检查发起端内核日志：dmesg | grep -i iscsi，关注 “session recovery”, “login failed”, “timeout” 等关键词；
- 尝试调大超时值（临时）：iscsiadm -m node -T ；
- 禁用一些高级特性测试是否兼容：iscsiadm -m node -T ，或关闭 ImmediateData；
- 确保 initiator 版本与目标协议版本匹配（如 target 使用 iSCSI v2.0，旧版 open-iscsi 可能握手失败）。
