必须配合sqlnet.ora配置才能可靠限制IP访问，仅用登录触发器易被绕过或误拦；其依赖的sys_context('USERENV','IP_ADDRESS')在NAT、代理等场景下返回中间设备IP而非真实客户端IP，且对SYS/DBA用户无效；而sqlnet.ora中TCP.VALIDNODE_CHECKING在监听层拦截更早更稳，需配合TCP.INVITED_NODES或TCP.EXCLUDED_NODES并reload监听器生效。
不能只靠登录触发器实现可靠限制，必须配合 sqlnet.ora 配置，否则容易被绕过或误拦。
登录触发器能用，但有硬伤
触发器里用 sys_context('USERENV', 'IP_ADDRESS') 获取 IP 是可行的，但这个值在经过 NAT、负载均衡、反向代理或监听器转发时会变成中间设备地址，不是真实客户端 IP。比如你看到的是 192.168.10.5，其实是负载均衡器的内网 IP，真实用户可能是公网 203.204.205.206。
常见错误现象：
- 触发器里判断
ip NOT IN ('192.168.1.100')，结果本地测试连不上——因为本地 SQL*Plus 连接可能返回空字符串或127.0.0.1 - 触发器抛出
ORA-20001，但客户端只显示模糊的ORA-00604，真正错误被掩盖，得查数据库告警日志才能定位 - 对
SYS、SYSTEM用户无效，Oracle 禁止对其启用登录触发器；DBA 或拥有ADMINISTER DATABASE TRIGGER权限的用户也能绕过逻辑
实操建议：
- 先在 SQL*Plus 里执行
SELECT sys_context('USERENV', 'IP_ADDRESS') FROM dual;，确认当前连接看到的 IP 是否符合预期 - 若返回为空或
127.0.0.1，说明网络路径不可信，别依赖这个字段做权限控制 - 真要用触发器，必须声明
AUTONOMOUS_TRANSACTION才能在AFTER LOGON里写日志表，否则报ORA-04092 - 错误号只能用
-20001到-20999范围，超出会报语法错
sqlnet.ora 的 TCP.VALIDNODE_CHECKING 才是主力
这是 Oracle 官方推荐、监听层生效的方案，不依赖数据库会话状态，也不受应用层干扰。它在连接建立初期就拦截，比触发器更早、更干净。
关键配置项必须成对出现：
-
tcp.validnode_checking = yes（必须设为yes，否则后面两项无效） -
tcp.invited_nodes = (192.168.59.100, 192.168.59.101, 127.0.0.1)（白名单，只放行这些 IP）
注意：tcp.invited_nodes 必须包含数据库本机所有监听所用的 IPv4 地址（不能写 localhost），否则 lsnrctl reload 或 lsnrctl stop 会失败——监听器自己要连自己。
支持通配符和 CIDR：
- 网段写法：
(192.168.59.*, 10.0.0.0/24)（Oracle 12c 及以后支持 CIDR） - 黑名单方式：
tcp.excluded_nodes = (203.204.205.206)，但优先级低于invited_nodes
修改后只需 lsnrctl reload，无需重启数据库实例。
为什么不能只用其中一种？
单纯靠触发器：攻击者只要连上一个没限制的用户（比如 APP_USER），再用该会话发起 UTL_HTTP 或 DBMS_SCHEDULER 调用，就能间接访问敏感数据——触发器管不到这种“内部跳转”。
单纯靠 sqlnet.ora：它只控制连接入口，不限制已连上的用户行为。比如某用户从合法 IP 登录后，把账号密码泄露给他人，后者仍可复用凭证远程登录（只要 IP 还在白名单里）。
所以生产环境应双管齐下：
- 用
sqlnet.ora拦住 95% 的非法连接尝试（快、稳、低开销） - 用登录触发器补充校验业务关键用户（如
EPAY_USER），并记录拒绝日志供审计 - 二者 IP 判断逻辑尽量一致，避免配置漂移导致策略冲突
最容易被忽略的一点：改完 sqlnet.ora 后，务必从一个**不在白名单中的 IP** 尝试连接，验证是否真返回 ORA-12547: TNS:lost contact，而不是静默失败或连上空会话。
