tcp.validnode_checking=no或未设置时ip限制机制完全不生效；设为yes后监听器才在tcp握手阶段检查客户端ip，必须配合tcp.invited_nodes（白名单）或tcp.excluded_nodes（黑名单）使用，二者不可共存，且需lsnrctl reload生效。
tcp.validnode_checking 必须设为 YES 才生效
这个参数是整个 IP 限制机制的总开关，不设或设成 NO，后面所有规则都无效。它控制监听器是否在 TCP 握手阶段介入检查客户端 IP。设为 YES 后，监听器才会读取 tcp.invited_nodes 或 tcp.excluded_nodes 并执行匹配逻辑。
常见错误现象：tnsping 成功但 sqlplus 连不上，或者连接后几秒断开（报 ORA-3136），大概率是这个参数没开，或者拼写成了 valid_node_checking 等错误形式。
注意：该参数只对 TCP/IP 协议有效，本地连接（sqlplus / as sysdba）和 IPC 协议完全绕过它。
白名单用 tcp.invited_nodes，别混用 excluded_nodes
想只允许几个 IP 访问，就用 tcp.invited_nodes；想禁止几个 IP 而其余全放行，才用 tcp.excluded_nodes。两者不能同时配置，否则监听器启动失败，报错 ORA-00119。
白名单更安全、意图更明确，推荐优先使用。示例写法：
tcp.validnode_checking = YES tcp.invited_nodes = (192.168.5.100, 192.168.5.200, 10.10.0.0/16, 127.0.0.1)
关键细节：
-
127.0.0.1和本机真实 IP（如192.168.5.50）必须显式加入，否则lsnrctl reload或lsnrctl status会失败 - 不支持通配符写法（如
192.168.5.*），网段必须用 CIDR 格式（/24、/16） - 主机名要和客户端发起连接时使用的 hostname 完全一致，监听器不做 DNS 反查
改完 sqlnet.ora 必须 lsnrctl reload，不是重启数据库
sqlnet.ora 是监听器进程（tnslsnr）读取的配置文件，和数据库实例无关。改完不 reload，监听器继续按旧规则运行，新配置永远不生效。
正确操作顺序：
- 编辑
$ORACLE_HOME/network/admin/sqlnet.ora - 保存后执行
lsnrctl reload（非stop/start，避免连接中断） - 验证：用被拒绝的 IP 尝试连接，应直接报
ORA-12547: TNS:lost contact，而不是卡住或提示密码错误
如果 reload 报错，检查日志 $ORACLE_HOME/network/log/listener.log，常见原因是 IP 写错、漏了本机地址、或两个 nodes 参数共存。
IP 地址失真时 sqlnet.ora 会失效
当客户端和数据库之间存在 NAT、负载均衡（F5、SLB）、Kubernetes Service 或 SQL*Net 转发时，监听器看到的源 IP 是中间设备的地址（比如 10.10.10.10 或 127.0.0.1），不是真实客户端 IP。此时 tcp.invited_nodes 规则基于错误 IP 判断，可能把合法用户拦在外面，也可能让恶意 IP 混进来。
这种场景下，sqlnet.ora 的 IP 控制基本不可靠。真正需要“用户+IP”细粒度控制，只能退到登录触发器（AFTER LOGON ON username.SCHEMA），但要注意它不拦截高权限用户（SYS、DBA），且依赖 sys_context('USERENV', 'IP_ADDRESS') —— 这个值在同样存在 NAT 时也会失真。
