WSL2 нь корпорацийн VPN-ийг өвлөхгүй, яг энэ нь алдаа

Дотоод вики Edge-д ачаалагдах боловч дистрибутив доторх git clone хугацаа хэтэрч зогсдог. Энэ ганц ажиглалтыг ихэвчлэн «VPN WSL2-г блоклож байна» гэж уншдаг бөгөөд дараагийн цаг /etc/resolv.conf-г засахад зарцуулагддаг. Илүү ашигтай уншлага нь WSL2-д хост-ын сүлжээний зам эхнээсээ байгаагүй: тэр өөрийн адаптер, өөрийн маршрут, Windows-ийн түүнд зориулж үүсгэдэг resolver файлтай туслах VM-д ажилладаг. Дараах бүхэн эдгээр гурвын алийг нь танд үнэхээр дутагдаж байгаагаас хамаарна.

VM өөрийн стек, метрик, resolver-тэй

Анхдагч NAT горимд дистрибутив виртуал шилжүүлэгчийн ард сууж, интернетэд хост-оор дамжин хүрдэг боловч хост-ын адаптеруудыг хардаггүй. ip addr хувийн хаягтай нэг интерфэйсийг харуулна, ip route тэр шилжүүлэгчээр дамжсан анхдагч маршрутыг харуулна, /etc/resolv.conf нь Windows-ын сонгосон stub resolver руу чиглэсэн үүсгэсэн файл юм. Windows талд VPN клиент ажиллаж эхэлснээс эдгээрийн аль нь ч өөрчлөгдөхгүй.

Тиймээс «хөтчүүр ажилладаг» гэдэг маш бага зүйг нотолдог. Хөтчүүр хост-ын стек, туннель, хост-ын resolver бодлогыг ашигладаг. Таны shell өөр стек ашигладаг бөгөөд энэ нь санамсаргүйгээр физик сүлжээний картыг хуваалцдаг. Тэд сайн тохиолдолд нийцэж, 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 болгон хадгалж, Windows-оос wsl --shutdown ажиллуул, дараа нь дистрибутивыг эхлүүлж /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 хувилбарыг хамардаг

wsl-vpnkit нь sidecar загвар: жижиг дистрибутив хост талын замыг эзэмшиж, бусад дистрибутивуудад виртуал сокетоор дамжуулдаг тул аппын трафик шүүгдсэн шилжүүлэгчээс хамаарахаа болино. Стандарт зам ажиллах шаардлагатай, өөрөөр хэлбэл networkingMode ба dnsTunneling дарж бичлэгүүдийг %UserProfile%\.wslconfig-оос хасаж, ажиллаж буй дистрибутив бүрт generateResolvConf = true-г сэргээж, нэвтрэх үед үйлчилгээг эхлүүлэх.

Толь горим нь Windows 11 22H2 ба түүнээс хойшхи хувилбаруудад суурилагдсан хувилбар бөгөөд нэг тохиргоо дээр нэг унтраалт юм:

[wsl2]
networkingMode=mirrored

Дистрибутив дотор ip addr дараа нь хост-ын адаптеруудыг жагсааж, туннель тэдгээрийн дунд харагдаж болно, мөн DNS туннель нь клиент DNS жагсаалтыг дахин бичсэн ч асуулгыг Windows resolver-оор дамжуулдаг. Энэ нь бүх нийтийн биш: зарим шүүлтүүрийн драйвер толь замыг одоо ч хаядаг, Hyper-V галт ханын дүрэмд тодорхой зөвшөөрөл шаардлагатай байж болно. Microsoft-ын WSL сүлжээний удирдамж нь илүү шинэ хувилбарт зориулсан жорыг хэрэглэхийн өмнө өөрийн хувилбартай тулгах хуудас юм.

Өөрчлөлт бүрийн дараа гурван зүйлийг шалгаарай

Машин бүрт нэг механизм сонгож бичээрэй, учир нь хоёулаа муу нийлдэг. Толь горим дээрх sidecar дамжуулалтыг хоёр дахин нэмэгдүүлдэг, .wslconfig-д хуучирсан sidecar бичлэгтэй толь хост шинэчлэлтийн дараа бүтэлгүйтдэг, өмнө нь биш.

Юу сонгосон ч, хүлээн авах тест нь дистрибутив доторх ижил гурван хүсэлт: дотоод нэр, нийтийн нэр, түүхий хаяг. Дараа нь туннелийг салгаж дахин холбосны дараа, мөн wsl --shutdown-ийн дараа давтана уу. Зөвхөн дотоод нэр бүтэлгүйтвэл resolver бодлого; дотоод болон нийтийн нэр хамт бүтэлгүйтэж хаяг ажиллаж байвал мөн resolver бодлого; бүхэн бүтэлгүйтвэл зам.

Нэг дотоод хост бүтэлгүйтэж бусад нь ажиллаж байвал resolver-ыг харахаа болиод тэр префиксэд дутуу маршрут хай. Дараагийн дахин холболт хүртэл бүхэн ажиллаж байвал та ажиллах үеийн төлөвөөс хамааралтай засвар олсон бөгөөд түүнийг автоматаар дахин хэрэглэх эсвэл дээрх хоёр механизмын аль нэгээр солих ёстой.