WSL2 не атрымлівае карпаратыўную VPN, і ў гэтым і ёсць памылка

Унутраная вікі адкрываецца ў Edge, а git clone унутры дыстрыбутыва сканчаецца тайм-аўтам. Гэтае адзінае назіранне звычайна чытаюць як «VPN блакуе WSL2», і наступная гадзіна ідзе на рэдагаванне /etc/resolv.conf. Больш карыснае прачытанне: WSL2 ніколі не меў сеткавага шляху хасцёра, бо працуе ў дапаможнай ВМ са сваім адаптарам, сваімі маршрутамі і файлам resolver, які Windows генераваў для яго. Усё далейшае залежыць ад таго, чаго з гэтых трох вам на самой справе не хапае.

ВМ мае свой стэк, свае метрыкі і свой 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 паказваюць, ці тунель забраў падсетку, у якой жыве ваша ВМ.

Міф першы: карпаратыўныя 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 сканчаецца тайм-аўтам, кліент тунеля фільтруе віртуальны камутатар або накіроўвае падсетку ВМ у тунель, і правільны 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

wsl-vpnkit — гэта шаблон sidecar: невялікі дыстрыбутыў валодае шляхам на баку хасцёра і перасылае трафік іншых дыстрыбутываў праз віртуальны сокет, таму трафік праграм больш не залежыць ад адфільтраванага камутатара. Патрэбны працоўны стандартны шлях, а значыць выдаліць перавызначэнні networkingMode і dnsTunneling з %UserProfile%\.wslconfig, аднавіць generateResolvConf = true у кожным працоўным дыстрыбутыве і запускаць службу пры ўваходзе.

Люстраваны рэжым — убудаваная альтэрнатыва ў Windows 11 22H2 і пазней, і гэта адна налада плюс выключэнне:

[wsl2]
networkingMode=mirrored

Унутры дыстрыбутыва ip addr тады пералічвае адаптары хасцёра, тунель можа з'явіцца сярод іх, а DNS-тунеляванне перасылае запыты праз resolver Windows, нават калі кліент перапісвае спіс DNS. Гэта не ўніверсальна: некаторыя фільтруючыя драйверы ўсё яшчэ скідаюць люстраваны шлях, а правілы брандмаўэра Hyper-V могуць патрабаваць яўнага дазволу. Кіраўніцтва па сетках WSL ад Microsoft — гэта старонка, якую трэба зверыць са сваёй зборкай, перш чым ужываць рэцэпт, напісаны для навейшай.

Праверце тры рэчы пасля кожнай змены

Выберыце адзін механізм на машыну і запішыце яго, бо два дрэнна спалучаюцца. Sidecar паверх люстраванага рэжыму падвойвае перасылку, а люстраваны хасцёр са састарэлым запісам sidecar у .wslconfig схільны падаць пасля абнаўлення, а не да яго.

Што б вы ні выбралі, прыёмачны тэст — тыя ж тры запыты ўнутры дыстрыбутыва: унутранае імя, публічнае імя і сыры адрас. Затым паўтарыце іх пасля адключэння і паўторнага падключэння тунеля і пасля wsl --shutdown. Калі падае толькі ўнутранае імя, гэта палітыка resolver; калі ўнутранае і публічнае імёны падаюць разам пры працоўным адрасе, гэта ўсё яшчэ палітыка resolver; калі падае ўсё, гэта шлях.

Калі адзін унутраны хост падае, а астатнія працуюць, перастаньце глядзець на resolver і шукайце адсутны маршрут для гэтага прэфікса. Калі ўсё працуе да наступнага перападлучэння, вы знайшлі выпраўленне, якое залежыць ад стану часу выканання, і яго трэба ўжываць аўтаматычна або замяніць адным з двух механізмаў вышэй.