仅靠sqlnet.ora无法实现“特定IP访问特定用户”的控制，因其IP检查发生在TCP握手阶段，早于用户名认证；真正可行的是在用户SCHEMA上创建登录触发器，用sys_context获取客户端IP并校验，但受NAT、RAC同步、高权限用户绕过等限制。
仅靠 sqlnet.ora 无法实现“特定ip访问特定用户”的控制——它连用户名都还没看到，就已决定放行或拒绝整个连接。
为什么 tcp.invited_nodes 不认用户
Oracle 监听器在 TCP 握手阶段就执行 IP 检查，此时客户端尚未发送用户名、密码，sqlnet.ora 的 tcp.invited_nodes 或 tcp.excluded_nodes 只能按源 IP 做全局开关。哪怕你只希望 scott 用户不能从 192.168.5.100 登录，而 hr 用户可以，这个需求它天生不支持。
常见错误现象：
- 配置了
tcp.invited_nodes = (192.168.5.200)，结果192.168.5.100连scott失败，但连hr也失败 → 因为拦截发生在连接层，不是会话层 - 监听启动报
TNS-12560→ 很可能漏加了数据库本机 IP（如192.168.5.50），不能写localhost或127.0.0.1
用登录触发器限制用户+IP 组合
这是唯一能真正按“用户 + IP”做判断的方案，但必须接受它的硬约束：它在认证后才触发，且对部分高权限用户无效。
实操要点：
- 触发器必须创建在具体用户上，例如
ON scott.SCHEMA，而不是ON DATABASE（后者影响所有用户，风险极高） - 获取客户端 IP 要用
sys_context('USERENV', 'IP_ADDRESS')，但该值在有 NAT、负载均衡、SQL*Net 转发时不可靠——可能返回空、127.0.0.1或中间设备 IP - DBA、SYS、SYSTEM 及拥有
ADMINISTER DATABASE TRIGGER权限的用户，会绕过该触发器（错误只写入告警日志，不阻断登录） -
RAISE_APPLICATION_ERROR错误号必须在-20001到-20999范围内，填-20000会编译失败
示例（限制 scott 用户禁止从两个 IP 登录）：
CREATE OR REPLACE TRIGGER scott_ip_restriction
AFTER LOGON ON scott.SCHEMA
DECLARE
v_ip VARCHAR2(30) := SYS_CONTEXT('USERENV', 'IP_ADDRESS');
BEGIN
IF v_ip IN ('192.168.5.100', '192.168.5.101') THEN
RAISE_APPLICATION_ERROR(-20001, 'Login denied for user SCOTT from ' || v_ip);
END IF;
END;
真实环境中最常被忽略的三点
第一，网络路径导致 IP 失真：只要链路中存在 SNAT/DNAT（比如 Kubernetes Service、F5、云厂商 SLB），sys_context('USERENV', 'IP_ADDRESS') 就不可信，此时触发器形同虚设。
第二，RAC 环境下 sqlnet.ora 必须同步修改所有节点，且 lsnrctl reload 在 RAC 中禁止使用——必须逐节点 srvctl stop listener -n nodeX 再 start，SCAN 监听也要单独处理。
第三，没有“纯白名单 + 用户粒度”的银弹方案：若既要细粒度控制，又要覆盖 DBA 用户，就得在防火墙（如 iptables、云安全组）或反向代理层做前置过滤，Oracle 层面只能补位，不能托底。
