☰

当 Windows 连接到 VPN 时，WSL2 没有连接

tag-icon • tag-icon networking vpn wsl2
当 Windows 连接到 VPN 时，WSL2 没有连接

我的 Windows PC 上的网络配置如下：

Ethernet adapter Ethernet 2:

   Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
   ...
   IPv4 Address. . . . . . . . . . . : 172.27.31.15(Preferred)
   Default Gateway . . . . . . . . . : ::
                                   172.27.0.1
   ...

Ethernet adapter vEthernet (Default Switch):
   ...
   IPv4 Address. . . . . . . . . . . : 172.22.128.1(Preferred)
   ...

Ethernet adapter vEthernet (WSL):
   ...
   IPv4 Address. . . . . . . . . . . : 172.28.48.1(Preferred)
   ...

Wireless LAN adapter Wi-Fi:
   ...
   IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
   Default Gateway . . . . . . . . . : 192.168.2.1
   ...

我的 WSL：

# ip addr|grep 'inet '
inet 127.0.0.1/8 scope host lo
inet 172.28.50.28/20 brd 172.28.63.255 scope global eth0
# ip route
default via 172.28.48.1 dev eth0
172.28.48.0/20 dev eth0 proto kernel scope link src 172.28.50.28

当 Windows PC 连接到 VPN 时，从 WSL2 内部 ping IP 会得到以下结果：

172.27.0.1 (Unreachable)
192.168.2.1  (Unreachable)
172.28.48.1  (Unreachable)
172.22.128.1  (Unreachable)

当 Windows PC 与 VPN 断开连接时，从 WSL2 内部 ping IP 会得到以下结果：

192.168.2.1  (YES)
172.28.48.1  (YES)
172.22.128.1  (Unreachable)

基本上，当 Windows PC 连接到 VPN 时，WSL2 完全与除其自身之外的任何 IP 隔离。如何解决这个问题？

更新：

在Windows PC上“rounte print”显示的路由情况如下（我省略了Gateway=192.168.2.1、Interface=192.168.2.13的大部分行）：

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.13     35
          0.0.0.0          0.0.0.0       172.27.0.1     172.27.31.15      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     172.22.128.0    255.255.240.0       172.27.0.1     172.27.31.15      2
     172.22.128.0    255.255.240.0         On-link      172.22.128.1    271
     172.22.128.1  255.255.255.255         On-link      172.22.128.1    271
   172.22.143.255  255.255.255.255         On-link      172.22.128.1    271
       172.27.0.0    255.255.192.0         On-link      172.27.31.15    257
     172.27.31.15  255.255.255.255         On-link      172.27.31.15    257
    172.27.63.255  255.255.255.255         On-link      172.27.31.15    257
      172.28.48.0    255.255.240.0         On-link       172.28.48.1    271
      172.28.48.0    255.255.240.0       172.27.0.1     172.27.31.15      2
      172.28.48.1  255.255.255.255         On-link       172.28.48.1    271
    172.28.63.255  255.255.255.255         On-link       172.28.48.1    271
    192.168.2.0    255.255.255.0       172.27.0.1     172.27.31.15      2
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.2.13    291
        224.0.0.0        240.0.0.0         On-link       172.28.48.1    271
        224.0.0.0        240.0.0.0         On-link      172.27.31.15    257
        224.0.0.0        240.0.0.0         On-link      172.22.128.1    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.2.13    291
  255.255.255.255  255.255.255.255         On-link       172.28.48.1    271
  255.255.255.255  255.255.255.255         On-link      172.27.31.15    257
  255.255.255.255  255.255.255.255         On-link      172.22.128.1    271

答案1

https://github.com/sakai135/wsl-vpnkit

这帮我解决了公司系统与工作 VPN 之间的问题。

记录在这里希望修复搜索引擎索引（每次我尝试搜索修复此特定问题时我都会点击这个帖子）

答案2

在我的情况下，我们使用的是 Palo Alto VPN；但是，您可以轻松修改它以找到任何其他 VPN 接口。这会找到问题路由并将其删除，流量现在从 WSL2 实例通过 VPN 流动。从提升的 PS 手动运行它，或在 VPN 连接时从计划任务触发它。此解决方案基于出色的写作https://janovesk.com/wsl/2022/01/21/wsl2-and-vpn-routing.html

clear
#find the VPN interface
$If_PANGP=Get-NetAdapter | Where-Object -Property InterfaceDescription -like PANGP*

#get the VPN interface index
$IDX_PANGP=$If_PANGP.ifIndex
write-host "PANGP interface index: $IDX_PANGP"

#get the interface used by WSL
$If_WSL=Get-NetAdapter | Where-Object -Property Name -like *WSL*  #there can be multiple Hyper-V interfaces - this find only the WSL one

#get the interface index for subsequent commands
$IDX_WSL=$If_WSL.ifIndex
write-host "WSL interface index: $IDX_WSL`n"

#get the subnet used by WSL
#The unique property for the subnet route is that it has a 20 bit subnet mask
#I don't know if this varies on other systems but this seems to work for mine
$RT_WSL=Get-NetRoute | Where-Object -Property ifIndex -eq $IDX_WSL | Where-Object -Property DestinationPrefix -like "*/20"

#Split the DestinationPrefix into it's components
$DP_WSL=$RT_WSL.DestinationPrefix.ToString() -split "/"  
$SN_WSL=$DP_WSL[0]   #WSL Subnet
$SM_WSL=$DP_WSL[1]   #WSL Mask

#find the WSL-subnet route bound to the PANGP interface
$RT_WSL_IFPAN=Get-NetRoute | Where-Object -Property ifIndex -eq $IDX_PANGP | Where-Object -Property DestinationPrefix -like "$SN_WSL*"

write-host "This is the route I will remove"
$RT_WSL_IFPAN


#this works but I have to call it several times at an elevated command prompt, it confirmed deletion 3 times before it was no longer found
write-host "`ncmd.exe equivalent:"
write-host "route delete $SN_WSL MASK $SM_WSL IF $IDX_PANGP"   #The mask here needs to be converted to octet form, but this output is just for posterity anyway


#Nuke it from orbit
#do until command fails - takes several tries, I don't know why
$A=1
while ($true)
{
    Write-Host "trying to remove route attempt $A"
    Remove-NetRoute -InputObject $RT_WSL_IFPAN -Confirm:$false -ErrorAction SilentlyContinue
    if (!$?)
    {
        Write-Host "route was removed on attempt $A"
        break
    }
    sleep 1
    $A+=1
}

#To restore the route - disable/enable the WSL ethernet adapter in network connections

答案3

这是企业 VPN 的一个已知限制。WSL2 在 Hyper-V 交换机后面的单独虚拟网络上运行。我认为连接到 VPN 时，您也无法访问本地网络上的任何其他设备。从 Windows 的角度来看，WSL2 网络是一个“单独的设备”/网络。

两个选项：

  • 首先，如果您的用例支持，请在连接到 VPN 时使用 WSL1 实例。由于它与 Windows 共享网络接口，因此当 VPN 连接到 Windows 时，它仍然可以访问网络（以及 VPN 上的资源）。

  • 其次，如果你使用的是 Windows 11（我知道，这不太可能用于企业设备），那么可以尝试一种解决方法。WSL2 网络领域目前处于预览阶段，并有所改进。Windows 11 用户可以安装 Microsoft Store 中提供的 WSL 预览版，然后按照说明操作这里打开桥接网络。

    在这种模式下，我的理解（虽然我无法测试）是桥接设备可能能够在启用 VPN 的情况下连接到网络。但是，如果您需要从 WSL2 内部连接到 VPN，则需要使用 Linux 客户端。

答案4

谢谢你的路由表。我认为这与 John 的假设相符，即您的 VPN 提供商未启用拆分隧道。也就是说，VPN 客户端在与 VPN 服务器建立连接时，配置为更新操作系统的路由表并通过 VPN 移动所有流量。

您提到以下主机无法访问：

  1. 172.27.0.1（无法访问）
  2. 192.168.2.1（无法访问）
  3. 172.28.48.1（无法访问）
  4. 172.22.128.1（无法访问）

172.27.0.1/18

这是您的 Cisco AnyConnect 接口的默认网关 IP：

以太网适配器以太网 2：

   Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
   ...
   IPv4 Address. . . . . . . . . . . : 172.27.31.15(Preferred)
   Default Gateway . . . . . . . . . : ::
                                   172.27.0.1

您无法 ping 此特定 IP 地址很可能只是服务器端的防火墙规则阻止了 ICMP（ping）流量。如果确实无法访问，那么根据路由表的状态，您将无法建立任何连接。

192.168.2.1/24

我假设这是您的设备正在连接的无线接入点的默认网关：

Wireless LAN adapter Wi-Fi:
   ...
   IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
   Default Gateway . . . . . . . . . : 192.168.2.1
   ...

路由表的相关部分如下：

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
    192.168.2.0    255.255.255.0       172.27.0.1     172.27.31.15      2

这里，发往192.168.2.0/24子网的流量只有一个选项，即通过127.27.0.1网关。没有其他路由说要192.168.2.1在192.168.2.13接口上使用网关。

因此，发往192.168.2.0/24子网的流量到达 VPN 网关，而另一端没有任何内容。因此，无法到达目的地。

172.28.48.1/20

路由表的相关部分如下：

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      172.28.48.0    255.255.240.0         On-link       172.28.48.1    271
      172.28.48.0    255.255.240.0       172.27.0.1     172.27.31.15      2

这里，您有两条不同的路由用于同一个网络。172.28.48.0/20您希望流量通过 On-link 路由。但是，它的Metric值为 271，高于MetricVPN 网关的 2。较低的度量获胜，因此网络流量172.28.48.0/20将流向 VPN 网关，而另一侧则没有任何流量。因此，目的地无法到达。

172.22.128.1/20

路由表的相关部分如下：

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
     172.22.128.0    255.255.240.0       172.27.0.1     172.27.31.15      2
     172.22.128.0    255.255.240.0         On-link      172.22.128.1    271

（这个和172.28.48.0/20网络的情况类似。）

对于172.22.128.0/20网络，指定了两条路由。您需要 On-link 路由，但 VPN 网关的度量较低。因此，流量会172.22.128.0/20流向 VPN 网关，而另一侧则没有任何流量。因此，无法到达目的地。

为了从主机访问所需的网络，您需要删除 Cisco AnyConnect VPN 客户端在路由表中安装的路由。我不知道 VPN 客户端是否会检测到这一点并再次更新它们；通常，当管理员以这种方式配置他们的 VPN 时，这是有意为之，而手动尝试在未经许可的情况下绕过 VPN 客户端配置可能会被视为负面行为。

我也不认为这是 WSL2 与 WSL1 的问题，也不是 Windows 10 与 11 的问题，也不是虚拟桥与虚拟 NAT 的问题（但我承认我可能错了）。只要主机上的路由表是这样配置的，来自主机的任何流量都将通过 VPN，而不是通过主机上的相关接口将流量推送到本地 VM 网络。

您的虚拟机本身应该仍具有网络连接；它们只需通过 VPN 即可。如果您能够通过控制台登录“本地”登录虚拟机，则可以确认这一点。

编辑：

关于您对路线表的评论的说明：

该表显示大多数路由通过我的家庭路由器 192.168.2.1，其他路由（到办公室）通过办公室路由器：172.27.0.1

我认为路由表显示的不是这个。具体来说，对于非特定网络 -- 0.0.0.0-- 指定了两条路由：

IPv4 Route Table
=================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.13     35
          0.0.0.0          0.0.0.0       172.27.0.1     172.27.31.15      2

同样，VPN 网关具有较低的路由Metric，因此所有匹配的流量（0.0.0.0而不是更具体的路由）都将转到 VPN（我们已经在上面证明了更具体的路由是还配置为通过VPN)。

相关内容