WSL2 non herda a VPN corporativa, e ese é o erro
WSL2 execútase na súa propia rede virtual e nunca herda a pila VPN do host. Separe os fallos de nomes dos fallos de ruta antes de editar resolv.conf sequera.
A wiki interna carga en Edge, mentres que git clone dentro da distribución esgota o tempo. Esa única observación adoita lerse como «a VPN bloquea WSL2», e a hora seguinte vai en editar /etc/resolv.conf. A lectura máis útil é que WSL2 nunca tivo a ruta de rede do host: execútase nunha VM auxiliar co seu propio adaptador, as súas propias rutas e un ficheiro de resolver que Windows xera para ela. Todo o que segue depende de cal deses tres lle falta en realidade.
A VM ten a súa propia pila, métrica e resolver
No modo NAT predeterminado, a distribución está detrás dun conmutador virtual e chega a internet a través do host, pero non ve os adaptadores do host. ip addr mostra unha interface cun enderezo privado, ip route mostra unha ruta predeterminada a través dese conmutador, e /etc/resolv.conf é un ficheiro xerado que apunta a un stub resolver que escolleu Windows. Nada diso cambia porque un cliente VPN se iniciase no lado de Windows.
Por iso «o navegador funciona» demostra tan pouco. O navegador usa a pila do host, o túnel e a política de resolver do host. A túa shell usa outra pila que casualmente comparte unha tarxeta de rede física. Coinciden no caso feliz e diverxen exactamente cando a VPN instala un filtro, reescribe a lista de DNS ou engade unha ruta para a subrede do conmutador virtual.
Dúas probas deciden en que mundo estás, e deben executarse dentro da distribución:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confQue os nomes fallen mentres un enderezo literal responde é un problema de resolver. Que nomes e enderezos fallen xuntos é un problema de ruta, e ningunha cantidade de edición do resolver o tocará. A evidencia do lado de Windows vén despois: Get-NetAdapter | Get-DnsClientServerAddress e route print -4 mostran se o túnel se quedou coa subrede onde vive a túa VM.
Mito un: os servidores DNS corporativos arranxan iso
Editar o ficheiro de resolver é o consello clásico, e acerta aproximadamente a metade das veces. Cando acerta, é por un motivo concreto: o ficheiro xerado apunta a un resolver que só coñece nomes públicos, así que unha consulta para intranet.example.internal volve como inexistente aínda que a ruta estea ben.
Fixar os servidores da VPN significa impedir que Windows rexenere o ficheiro, porque calquera ficheiro que escribas a man substitúese no seguinte arranque:
[network]
generateResolvConf = falseGarda iso como /etc/wsl.conf, executa wsl --shutdown desde Windows, despois arranca a distribución e escribe /etc/resolv.conf cos servidores do túnel primeiro e un resolver público só como reserva. É un cambio duradeiro cun custo de mantemento: o ficheiro xa non segue o host, así que cando cambian os enderezos DNS corporativos a distribución segue preguntando polos antigos. Alguén ten que ser dono dese ficheiro.
Tampouco fai nada cando o fallo é máis amplo. Se curl cara 1.1.1.1 esgota o tempo, o cliente do túnel está filtrando o conmutador virtual ou encamiñando a subrede da VM ao túnel, e un resolver correcto só che dá nomes que aínda non se poden alcanzar.
Mito dous: o cambio de métrica aguanta
Cando os nomes se resolven pero o tráfico sae polo adaptador físico, a panca son as métricas de interface. Dálle un custo alto ao adaptador da VPN e un baixo ao conmutador WSL:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1Despois lembra que en moitas compilacións do cliente o adaptador do túnel recréase en cada conexión e a métrica volve ao seu valor predeterminado. Un comando puntual é unha corrección que caduca en silencio, normalmente durante unha fin de semana, e o ticket volve con «a semana pasada funcionaba». Unha tarefa programada activada polo evento da VPN, ou un script que o usuario executa tras conectarse, é a versión honesta desta reparación.
A mesma caducidade aplícase ás rutas de host engadidas para un prefixo teimudo. Valen a pena como diagnóstico, porque che din se o problema é un destino ou toda a ruta, pero non son unha arquitectura.
Mito tres: unha corrección cobre cada compilación de Windows
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit é o patrón sidecar: unha distribución pequena posúe a ruta do lado do host e reenvía para outras distribucións a través dun socket virtual, de xeito que o tráfico das aplicacións deixa de depender do conmutador filtrado. Necesita que a ruta estándar funcione, o que significa quitar as anulacións networkingMode e dnsTunneling de %UserProfile%\.wslconfig, restaurar generateResolvConf = true en cada distribución que funcione e iniciar o servizo ao iniciar sesión.
O modo espello é a alternativa integrada en Windows 11 22H2 e posteriores, e é un axuste máis un apagado:
[wsl2]
networkingMode=mirroredDentro da distribución ip addr entón enumera os adaptadores do host, o túnel pode aparecer entre eles, e o túnel de DNS reenvía as consultas a través do resolver de Windows mesmo cando o cliente reescribe a lista de DNS. Non é universal: algúns controladores de filtro seguen descartando a ruta espello, e as regras de firewall de Hyper-V poden necesitar un permiso explícito. A guía de redes de WSL de Microsoft é a páxina que debes contrastar coa túa compilación antes de aplicar unha receita escrita para unha máis nova.
Proba tres cousas tras cada cambio
Escolle un mecanismo por máquina e anótao, porque os dous se combinan mal. Un sidecar sobre o modo espello duplica o reenvío, e un host espello cunha entrada de sidecar obsoleta en .wslconfig tende a fallar despois dunha actualización, non antes.
Escollas o que escollas, a proba de aceptación son as mesmas tres peticións dentro da distribución: un nome interno, un nome público e un enderezo cru. Despois repíteas tras desconectar e reconectar o túnel, e tras wsl --shutdown. Que só falle o nome interno significa política de resolver; que fallen xuntos o nome interno e o público cun enderezo que funciona segue significando política de resolver; que falle todo significa a ruta.
Se falla un host interno mentres o resto funciona, deixa de mirar o resolver e busca unha ruta que falte para ese prefixo. Se todo funciona ata a seguinte reconexión, atopaches unha corrección que depende do estado en tempo de execución, e debe reaplicarse automaticamente ou substituírse por un dos dous mecanismos anteriores.