sqlnet.ora 的 tcp.invited_nodes 或 tcp.excluded_nodes 仅作用于监听器连接层，按源IP粗粒度放行或拒绝全部连接，不识别用户名、不介入认证，故无法实现“特定IP访问特定用户”的细粒度控制。
直接说结论：sqlnet.ora 的 tcp.invited_nodes 或 tcp.excluded_nodes 能限制 ip 访问，但只作用于 oracle net 连接层（即监听器入口），不区分数据库用户，也无法按用户粒度控制。想“限制特定 ip 访问某个数据库用户”，仅靠 sqlnet.ora 做不到。
为什么 sqlnet.ora 无法按用户限制 IP
sqlnet.ora 的访问控制发生在连接建立前的网络握手阶段，此时 Oracle 还没收到用户名、密码，更不知道你要连哪个用户。它只看客户端发起连接的源 IP 或主机名，然后决定“放行”或“拒绝整个连接请求”。
也就是说：
• 允许 192.168.1.100 → 该 IP 上任何用户（scott、hr、sys）都能连
• 拒绝 192.168.1.200 → 该 IP 上所有连接（哪怕只是 tnsping）都会被监听器切断
它不是数据库权限系统，不读取 DBA_USERS，也不介入认证流程。
实际能用的配置组合与陷阱
必须同时满足三项才生效：
• tcp.validnode_checking = yes（开关必须打开）
• 只启用 tcp.invited_nodes 或 tcp.excluded_nodes 之一（二者互斥，不能共存）
• 所有涉及的 IP/主机名必须可解析（尤其 invited_nodes 中的 hostname，需在 /etc/hosts 或 DNS 中存在；否则监听启动失败，报 TNS-12560）
常见错误现象：
• 修改后 tnsping 成功但 sqlplus 报 ORA-12537: TNS:connection closed → 很可能是本地回环地址（如 127.0.0.1、::1、localhost）没加进 invited_nodes，导致监听自检失败
• RAC 环境下只改了一个节点的 sqlnet.ora → SCAN 监听和本地监听行为不一致，部分连接绕过规则
• 使用通配符（如 192.168.1.*）→ Oracle 明确不支持，配置会被忽略
Oracle 19c 下 reload 还是 restart 监听？
单实例库：用 lsnrctl reload 即可，不用重启数据库，也不必停监听。
RAC 环境（含 19c）：
• lsnrctl reload 会清空已注册的服务，导致连接中断，**禁止使用**
• 必须用 srvctl stop listener -n node1 + srvctl start listener -n node1 逐节点重启本地监听
• 若使用 SCAN，则还需对 SCAN 监听执行 srvctl stop scan_listener 和 srvctl start scan_listener
• 所有节点的 $ORACLE_HOME/network/admin/sqlnet.ora 都要同步修改，缺一不可
真要按用户+IP 控制，得换方案
sqlnet.ora 是粗粒度网关，精细控制必须下沉到数据库层：
• 使用细粒度审计（FGA）+ 触发器拦截，但性能差、维护重
• 在应用层做 IP 白名单（如 Web 应用鉴权后才发 DB 请求）
• 用 Oracle Database Vault 或 Oracle Label Security（需额外许可）
• 更现实的做法：结合防火墙（如 iptables / Windows 防火墙）封死非可信 IP 的 1521 端口，再用 sqlnet.ora 做第二道网关——这是生产环境最常采用的纵深防御组合
