VPN қосылғанда WSL жұмыс хост атауын неге жоғалтады?

Windows ішкі хостты ешбір шағымсыз шешеді, ал сол атау туннель көтерілген сәтте WSL ішінде сәтсіз аяқталады. Әдеттегі жөндеу — дистрибутивке жария шешуші жазу, ол қарапайым шолуды қалпына келтіреді және жұмыс хост атауын шешілмейтін етеді. Бұл бір ақауды екіншісіне ауыстырады және шын мәнінде сынған қабатты жасырады. Шешушінің кез келген жолын қоспас немесе жоймас бұрын үш қабаттың қайсысы сәтсіз екенін анықтаңыз.

Алдымен маршруттау ақауын жоққа шығарыңыз

Екі жақта да дәл сол толық квалификацияланған атауды сұраңыз, ұқсас екі атауды емес. Бірдей жол үшін Windows-та сәттілік және WSL-де сәтсіздік екі шешу жолының қолтаңбасы, және бұл үлгіні осынша таза жасайтын басқа нәрсе аз. Егер WSL қызметке оның белгілі сандық мекенжайы бойынша да жете алмаса, маршруттау немесе сүзгілеу мәселесі де бар. Бұл жағдайда DNS жұмысы оны ашпайды, және түстен кейінгі уақыт дұрыс емес қабатқа кетеді.

Үш симптом осы жағдайлардың көбін қамтиды, және әрқайсысы басқа жерді нұсқайды. Конфигурация файлын ашпас бұрын сәйкес жолды оқыңыз:

Ортаңғы жол — адамдар қате оқитын жол, өйткені оны бұзған өзгеріс апталар бұрын жасалған және сол кезде сәтті көрінген. Үшінші жол — адамдар қате диагностикалайтын жол, өйткені шешілетін атау желінің сау екенінің дәлеліндей сезіледі. Екі жол да сізді төмендегі басқа бөлімге жібереді.

DNS туннельдеуінің төменгі нұсқа шегі бар

Microsoft WSL-дің желілік режимін құжаттайды, ол DNS сұрауларын виртуализация арнасы арқылы Windows шешушісіне туннельдейді. Қолдау көрсетілген Windows 11 құрастыруларында ол әдепкі бойынша қосылған, сондықтан бір корпоративтік желідегі екі машина әртүрлі әрекет етеді. Айнымалы — құрастыру нөмірі, корпоративтік саясат емес.

WSL желілік нұсқаулығы сол режимді және оны қолдайтын нұсқаларды сипаттайды. Бұл мүмкіндік маңызды, өйткені корпоративтік DNS саясаты әдетте Windows шешушісінде тұрады, ал Windows жолын мұралайтын дистрибутив саясатты да бірге мұралайды. Жария шешушіден сұрайтын дистрибутивтің жеке атауға барар жолы жоқ, оның өз конфигурациясы қаншалықты ұқыпты көрінсе де. Осы механизм бүкіл симптомды түсіндіреді және жария шешушімен айналып өтудің неге сәтсіз болатынын түсіндіреді.

Бірдеңені өңдеу алдында құрастыруды оқыңыз. Неғұрлым жаңа орнатудан көшірілген параметр ескірек орнатудың оны жүзеге асыратынына дәлел емес. Өзгеріс жанына құрастыру нөмірін жазыңыз, өйткені екі машина арасындағы айырмашылық әрдайым дерлік саясат емес, нұсқа.

Ескі қайта анықтаулар өздері шешкен мәселеден ұзақ өмір сүреді

Ескірек рецепттер құрылған шешуші файлдарын өшіріп тастайтын, атау серверін қатты кодтайтын немесе файлды өзгермейтін атрибутпен құлыптайтын. Бұл өзгерістер оларды тудырған қосылу мәселесі жоғалғаннан кейін де ұзақ уақыт орнында қалады, және әдетте жаңарақ параметрдің ештеңе істемейтіндей көрінуінің себебі — солар. Олар сондай-ақ дистрибутивті қайта орнатудан кейін де shell профилі түрінде сақталады, ол файлды әр кірген сайын қайта жазады. Соңғысын табу ең қиын, өйткені ол бәрі тексеретін файлдан көрінбейді.

Қолмен жазылған шешуші файлын, ондағы өзгермейтін атрибутты және оны қайта жазатын іске қосу скриптін іздеңіз. Өңдеу алдында өзгермейтін жалаушаны тексеріңіз, өйткені құлыпталған файлға жазу рұқсат мәселесіндей оқылатын түрде сәтсіз аяқталады. Содан кейін shell профилін тексеріңіз, өйткені ондағы скрипт сіздің түзетуіңізден кейін секундтар ішінде ескі мазмұнды қалпына келтіреді.

Қайта анықтауды жоюдың салдары бар, сондықтан нені жойғаныңызды және неге екенін жазыңыз. Басқа мақсат үшін шынымен статикалық шешуші қажет дистрибутив құрылған файл қайта оралғанда бұзылады.

Екі файл, екі түрлі рөл

Екі конфигурация файлы әртүрлі жерлерде тұрады және әртүрлі нәрселерді басқарады, ал оларды шатастыру қате қабатқа қолданылатын өңдеулерді тудырады. Windows жағындағы файл виртуалды машинаның қасиеттерін белгілейді, ал дистрибутив жағындағы файл бұл дистрибутивтің өз шешуші конфигурациясын қалай құратынын белгілейді. Ешқайсысы екіншісін қайта анықтамайды, сондықтан екеуі де келісуі керек.

Бұл мүмкіндікті қолдайтын орнату үшін Windows жағындағы үзінді қысқа. Бұл — сол жақтағы бүкіл өзгеріс:

[wsl2]
dnsTunneling=true

Бұл үзінді Windows пайдаланушы профиліне тиесілі және бір дистрибутивке емес, виртуалды машинаға қолданылады. Туннельдеу сонымен қатар дистрибутивтің шешуші генерациясын өшірмегенін талап етеді, сондықтан дистрибутив жағындағы файл бұл мінез-құлықты тыныш қалдыруы керек. Біреуін екіншісінсіз өзгертіңіз — режим үнсіз ештеңе істемейді, және бұл жөндеудің бұзылған деп хабарлануының ең көп тараған жолы. Екі файлды бір сессияда тексеріңіз, өйткені апталап аралықпен жасалған екі өңдеу — ешкім тели алмайтын екі өңдеу.

Қайта іске қосыңыз, содан кейін екі жақтан да сұраңыз

Бұл параметрлер орта іске қосылғанда оқылады, сондықтан жұмыс істеп тұрған дистрибутив ішіндегі жаңа shell оларды қайта жүктемейді. Shell-ді қайта іске қосудың орнына ортаны өшіріңіз және алдымен орындалып жатқан жұмысты сақтаңыз, өйткені әр дистрибутив онымен бірге тоқтайды. Осы бір қалдыру өзгерістің әсері жоқ деген хабарламалардың көбін түсіндіреді.

Содан кейін екі жаққа да бірдей сұрақ қойыңыз. Шығыс сонымен қатар дистрибутивтің қай шешушімен қалғанын көрсетеді:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Бірінші команда ортаны аяқтайды, екіншісі дистрибутивтің қазір қай шешушіні пайдаланатынын көрсетеді, ал соңғы екеуі әр жаққа бірдей сұрақ қояды. Параметр күйін емес, жауаптарды салыстырыңыз. Екі файл да дұрыс болған кезде таза қайта іске қосудан кейін де сәтсіз аяқталатын сұрау корпоративтік шешуші саясатына нұсқайды, және бұл әңгіменің иесі басқа.