我来分享下针对这个Ivanti VPN内外网同时访问问题的思路和可行方案，结合你已经做的排查，咱们一步步来梳理：

问题背景回顾 #

你遇到的情况非常典型——通过Ivanti VPN连接客户内网后，全局流量被强制导向VPN适配器，导致无法访问公网，只能靠虚拟机拆分工作流，确实挺折腾的。

你已做的排查方向是对的！ #

你之前检查网络适配器、路由表、DNS的思路完全没问题：

• Ivanti创建的适配器用了255.255.255.255的子网掩码，还强制替换了默认DNS服务器
• 连接VPN后新增的3-4条路由规则，正是把流量都拉去VPN的关键
• 你手动添加路由指定特定IP走WiFi、用Add-DnsClientNrptRule配置DNS规则，这些都是正确的尝试方向，只是需要调整到反向逻辑就能解决问题。

核心解决方案：拆分路由 + 拆分DNS #

1. 调整路由表：让内网流量走VPN，公网走本地 #

Ivanti默认会把所有流量（0.0.0.0/0）都导向VPN，我们需要修改路由表，只把客户内网的IP段定向到VPN，其余公网流量走本地网卡：

• 第一步：断开VPN，用管理员权限打开命令提示符，执行route print，记录下本地网卡的默认路由（格式大概是0.0.0.0 0.0.0.0 192.168.x.x <本地网卡IP>），记住这里的本地网关IP（比如192.168.1.1）

• 第二步：连接VPN，再次执行route print，找到新的默认路由（指向Ivanti适配器的网关，比如10.x.x.x）

• 第三步：删除VPN的全局默认路由：

  route delete 0.0.0.0 mask 0.0.0.0 <VPN网关IP>
  

• 第四步：添加客户内网IP段的专属路由（假设客户内网是10.0.0.0/8，如果是更细分的段比如10.10.0.0/16就改对应的掩码）：

  route add 10.0.0.0 mask 255.0.0.0 <VPN网关IP> metric 1
  

  （metric设为1是让内网流量优先走VPN，优先级更高）

• 第五步：恢复本地公网的默认路由：

  route add 0.0.0.0 mask 0.0.0.0 <本地网关IP> metric 10
  

  （metric设为10，确保公网流量不会抢内网的路由）

  注意：每次连接VPN都需要重新执行这些命令，可以把它们写成批处理脚本，管理员权限运行就能自动配置。

2. 调整DNS策略：内网域名用客户DNS，公网用本地DNS #

你之前是把公网域名指定用本地DNS，其实应该反过来——只让客户内网的域名走Ivanti提供的DNS，其余所有域名用本地DNS：

• 用管理员权限打开PowerShell，添加内网域名的NRPT规则（比如客户内网域名为*.client-domain.com）：

  Add-DnsClientNrptRule -Namespace "*.client-domain.com" -NameServers "<客户DNS1>", "<客户DNS2>"
  

• 去网络适配器设置里，确保本地网卡的DNS服务器（比如8.8.8.8、1.1.1.1）优先级高于Ivanti适配器的DNS，或者直接在Ivanti客户端设置里取消“使用VPN的DNS服务器”选项（如果管理员没锁这个设置的话）
• 针对IPv6问题：如果客户内网不用IPv6，可以直接禁用本地网卡的IPv6；如果需要用，就在NRPT规则里也添加IPv6的内网域名规则，避免公网域名通过IPv6被VPN拦截。

3. 更省事的办法：检查Ivanti的拆分隧道设置 #

有些Ivanti版本支持**拆分隧道（Split Tunnel）**功能，这是官方提供的内外网分流方案，不用手动改路由：

• 打开Ivanti客户端，找到你连接的配置文件，查看“隧道模式”或“拆分隧道”选项
• 如果能开启，选择“仅内网流量走VPN”或者手动添加内网IP段/域名，这样公网流量会自动走本地，这是最省心的方案（如果管理员没禁用这个功能的话）

验证配置是否生效 #

配置完后可以用这些命令测试：

• nslookup gitlab.client-domain.com：看解析是否用了客户的DNS服务器
• nslookup google.com：看解析是否用了本地DNS服务器
• tracert google.com：看路由第一跳是不是本地网关
• tracert 10.x.x.x（内网IP）：看路由第一跳是不是VPN网关

这样就能确认内外网流量是否各自走对了路径。

备注：内容来源于stack exchange，提问作者Ress