WSL2 не го наследува корпоративниот VPN и токму тоа е грешката

WSL2 работи во сопствена виртуелна мрежа и никогаш не го наследува VPN стекот на домаќинот. Одвојте ги неуспесите на имињата од неуспесите на патеката пред воопшто да го уредите resolv.conf.

Внатрешното вики се вчитува во Edge, а git clone внатре во дистрибуцијата истекува. Ова единствено набљудување обично се чита како «VPN го блокира WSL2», и следниот час оди во уредување на /etc/resolv.conf. Покорисното читање е дека WSL2 никогаш го немал мрежниот пат на домаќинот: работи во помошна VM со сопствен адаптер, сопствени рути и датотека со resolver што Windows ја генерира за него. Сето што следи зависи од тоа кое од тие три навистина ви недостасува.

VM-от има свој стек, метрики и resolver

Во стандардниот NAT режим, дистрибуцијата стои зад виртуелен прекинувач и стигнува до интернет преку домаќинот, но не ги гледа неговите адаптери. ip addr прикажува едно интерфејс со приватна адреса, ip route прикажува стандардна рута преку тој прекинувач, а /etc/resolv.conf е генерирана датотека што покажува кон stub resolver избран од Windows. Ништо од тоа не се менува затоа што на страната на Windows се подигна VPN клиент.

Затоа «прелистувачот работи» докажува толку малку. Прелистувачот го користи стекот на домаќинот, тунелот и resolver политиката на домаќинот. Вашата обвивка користи друг стек што случајно дели физичка мрежна карта. Тие се согласуваат во среќниот случај и се разидуваат точно кога VPN инсталира филтер, ја препишува DNS листата или додава рута за подмрежата на виртуелниот прекинувач.

Два теста одлучуваат во кој свет сте, и тие мора да се извршат внатре во дистрибуцијата:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Неуспех на имињата додека буквална адреса одговара е проблем со resolver. Неуспех на имињата и адресите заедно е проблем со патеката, и никакво уредување на resolver нема да го допре. Следат докази од страната на Windows: Get-NetAdapter | Get-DnsClientServerAddress и route print -4 покажуваат дали тунелот ја зазел подмрежата во која живее вашата VM.

Прв мит: корпоративните DNS сервери го решаваат

Уредувањето на датотеката со resolver е класичен совет и е точен околу половина од времето. Кога е точен, точен е од конкретна причина: генерираната датотека покажува кон resolver што знае само јавни имиња, па барањето за intranet.example.internal се враќа како непостоечко иако патеката е во ред.

Закачувањето на серверите на VPN значи запирање на Windows да ја регенерира датотеката, бидејќи секоја рачно напишана датотека се заменува при следното стартување:

[network]
generateResolvConf = false

Зачувајте го тоа како /etc/wsl.conf, извршете wsl --shutdown од Windows, потоа стартувајте ја дистрибуцијата и напишете /etc/resolv.conf со серверите на тунелот први и јавен resolver само како резерва. Тоа е трајна промена со трошок за одржување: датотеката веќе не го следи домаќинот, па кога корпоративните DNS адреси ќе се сменат, дистрибуцијата продолжува да ги прашува старите. Некој мора да биде сопственик на таа датотека.

Не прави ништо ни кога неуспехот е поширок. Ако curl кон 1.1.1.1 истече, клиентот на тунелот го филтрира виртуелниот прекинувач или ја насочува подмрежата на VM во тунелот, и правилен resolver ви дава само имиња до кои сето уште не може да се стигне.

Втор мит: промената на метриката останува

Кога имињата се решаваат но сообраќајот излегува преку физичкиот адаптер, лостот се метриките на интерфејсот. Дајте му висока цена на VPN адаптерот и ниска на WSL прекинувачот:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Потоа запомнете дека во многу клиентски верзии тунелскиот адаптер се пресоздава при секое поврзување и метриката се враќа на стандардната. Еднократна команда е поправка што тивко истекува, обично преку викенд, и тикетот се враќа со «минатата недела работеше». Закажана задача активирана од настанот на VPN, или скрипта што корисникот ја извршува по поврзување, е чесната верзија на оваа поправка.

Истиот рок важи за рутите на домаќинот додадени за еден тврдоглав префикс. Тие вредат како дијагностика, бидејќи кажуваат дали проблемот е една дестинација или целата патека, но не се архитектура.

Трет мит: една поправка покрива секоја верзија на Windows

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit е sidecar моделот: мала дистрибуција го поседува патот на страната на домаќинот и проследува за други дистрибуции преку виртуелен сокет, па сообраќајот на апликациите престанува да зависи од филтрираниот прекинувач. Потребно е стандардниот пат да работи, што значи да се отстранат препишувањата networkingMode и dnsTunneling од %UserProfile%\.wslconfig, да се врати generateResolvConf = true во секоја работна дистрибуција и услугата да се стартува при најава.

Огледалниот режим е вградената алтернатива во Windows 11 22H2 и понови, и тоа е едно поставување плус исклучување:

[wsl2]
networkingMode=mirrored

Внатре во дистрибуцијата ip addr потоа ги наведува адаптерите на домаќинот, тунелот може да се појави меѓу нив, и DNS тунелирањето проследува барања преку Windows resolver дури и кога клиентот ја препишува DNS листата. Не е универзално: некои филтерски драјвери сето уште ја отфрлаат огледалната патека, а Hyper-V правилата на огнениот ѕид може да бараат експлицитна дозвола. Водичот за WSL мрежи на Microsoft е страницата што треба да се спореди со вашата верзија пред да се примени рецепт напишан за понова.

По секоја промена тестирајте три работи

Изберете еден механизам по машина и запишете го, бидејќи двете лошо се комбинираат. Sidecar над огледалниот режим го удвојува проследувањето, а огледален домаќин со заостанат sidecar запис во .wslconfig обично паѓа по надградба, а не пред неа.

Што и да избравте, тестот за прифаќање се истите три барања внатре во дистрибуцијата: внатрешно име, јавно име и сурова адреса. Потоа повторете ги откако ќе го исклучите и повторно поврзете тунелот, и по wsl --shutdown. Ако паѓа само внатрешното име, тоа е resolver политика; ако внатрешното и јавното име паѓаат заедно со работна адреса, тоа е сето уште resolver политика; ако паѓа сето, тоа е патеката.

Ако еден внатрешен домаќин паѓа додека останатите работат, престанете да гледате во resolver и побарајте рута што недостасува за тој префикс. Ако сето работи до следното повторно поврзување, најдовте поправка што зависи од состојбата при извршување, и таа мора автоматски повторно да се примени или да се замени со еден од двата механизми погоре.

Поврзани статии