WSL2-k DNS galdu zuen VPN-a konektatu ondoren? Bi arrazoi

Resolver fitxategi zaharkitu batek eta bide-metrika lehiakor batek sintoma bera sortzen dute WSL2 barruan. Erregistra itzazu bi aldeak, eta gero konpondu benetan hondatuta dagoena.

Helbidearen bidezko ping-ek distribuzioaren barruan funtzionatzen du, pakete-instalazioek eta git deskargek ez, eta hutsak tunela altxatu eta berehala agertu ziren. Izenak soilik utzi zioten ebazten, eta horrek DNS-ra eramaten du, konektibitatera ez. Paketeak berriro instalatzea da hemen lehen urrats okerrik ezagunena. WSL2-k sintoma zehatz hori sortzeko bi modu independente ditu, eta konponketa desberdinak behar dituzte.

Zergatik mantentzen du distribuzioak bere resolver propioa

Windows-eko DNS bezeroa ez da distribuzioaren barruan erabiltzen. WSL2-k bere resolver fitxategia eraikitzen du abiaraztean, Windows-ek makina birtual laguntzailearentzako etengailu birtualean argitaratzen duen stub helbide batera seinalatuz.

Konfigurazio hori egonkorra da sare-aldaketa arrunten aurrean, behin idazten delako eta berrerabiltzen delako. Konfigurazioa zuzena izateari uzten dio tunelaren bezeroak ostalariaren egokitzaile-zerrenda berridazten duenean, makina birtual laguntzailea jadanik abiarazi ondoren.

Distribuzioaren barruan ezerk ez du aldaketa zaintzen, beraz fitxategiak bidean egon daitekeen helbide batera seinalatzen jarraitzen du, beharbada orain ez dagoena. Hurrengo bilaketak orduan itxaroten du, denbora agortzen zaio edo barne-zonari inoiz entzun ez dion zerbitzari baten erantzuna jasotzen du. Barrutik resolverrak erantzuteari uzten dio besterik gabe, eta izen guztiek aldi berean huts egiten dute.

Bildu lehenengo frogak bi aldeetan

Idatz ezazu distribuzioak zer ikusten duen, eta gero Windows-ek zer ikusten duen, bat ere aldatu aurretik. Bi ikuspegiek batera bereizten dituzte hutsegite-moduak.

Distribuzioaren barruan, inprimatu resolver fitxategia, bideratze-taula eta barne-bilaketa bat eta publiko bat:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows-en, zerrendatu DNS zerbitzariak egokitzaile bakoitzeko eta IPv4 taula metrikekin. VPN bezero batek normalean bide bat instalatzen du WSL2 azpisarearentzat, eta haren metrikak erabakitzen du trafiko hori tunelatik ateratzen den edo tokiko geratzen den.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Bide-metrika edo fitxategi zaharkitua

Lehen hutsegitea fitxategi zaharkitua da. Resolverra abiarazteko egokitzailearen egoerarako idatzi zen, eta tunelak egoera hori aldatu zuen. Haren stub helbidea orain iristezina izan daiteke, edo barne-zonari buruz ezer ez daki zerbitzari bat izenda dezake.

Bigarrena bideratze-arazo bat da. VPN-ak WSL2 azpisarea estaltzen duen bide bat gehitzen duenean, ostalariaren esteka-bidea baino metrika baxuagoarekin, makina birtual laguntzaileari zuzendutako paketeak tunelera sartzen dira. Orduan WSL2 zerbitzu guztiek denbora agortzen dute, ez DNS-ak bakarrik.

Bereizteko probak lerro bat kostatzen du. Resolver publiko bat bezalako helbide numeriko batek ping-ari erantzuten badio izenek huts egiten duten bitartean, bidea osorik dago eta DNS da arazoa. Hori da resolver-aldaketa justifikatuta dagoen kasua, eta justifikatuta ez dagoen kasua ere begi-bistakoa bihurtzen da. Proba numerikoak ere huts egiten badu, makina birtual laguntzaileak bidea galdu du eta inolako resolver fitxategik ez du hori konponduko.

Bideratze kasurako, kendu metrika automatikoa tunelaren egokitzailetik eta eman WSL2 esteka-bidea baino goragoko zenbaki bat:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Itzaltzeak garrantzia du. Metrika aldatzeak ez du martxan dagoen makina birtual laguntzailea berridazten, beraz distribuzioa berreraiki behar da aldaketa ikusgai izan aurretik.

Har ezazu fitxategia, nahita

Bideratzea zuzena bada eta barne-izenek soilik huts egiten badute, resolverra da erruduna eta sorgailua geldi dezakezu. Mantentze-kostua duen aldaketa deliberatua da, ez arin aplikatzeko konponbide bat.

Sortu /etc/wsl.conf distribuzioaren barruan sorkuntza desgaitzen duen sare-atalean, eta gero idatzi resolver fitxategia zeuk, lehenengo enpresa-zerbitzaria eta gero publiko bat erreserban:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Ordenak garrantzia du. Resolver publiko batek ezin dio barne-izen bati erantzun, eta erreserba interneteko bilaketetarako soilik dago. Fitxategia zurea denean, ezerk ez du birsortzen, beraz mugitzen den enpresa-resolver batek zeuk nabaritu behar duzun etena bihurtzen da.

Egiaztatu izenak, gero paketeak

Egiaztatu barne-izen bat eta publiko bat sistemaren resolverrarekin, eta gero errepikatu huts egin zuen eragiketa. Pakete-kudeatzaileek batzuetan beren resolver propioa erabiltzen dute, horregatik funtzionatzen duen getent batek instalazio hondatu batekin batera bizi daiteke.

Berridazketa automatizatzen baduzu, egin idempotente: tunelik ez badago, mantendu lehendik dagoen fitxategia zerbitzari-zerrenda hutsa idatzi ordez.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Barrutik funtzionatzen duen barne-bilaketa bat eta funtzionatzen duen bilaketa publiko bat dira erregistratzeko merezi duen emaitza. Ostalarian VPN ikono berde batek ez du bietako bat ere frogatzen.

Erlazionatutako artikuluak