resolv.conf en WSL 2: DNS mortas kiam la VPN konektiĝas

WSL regeneras resolv.conf el la Windows-adaptiloj kiujn ĝi vidas, do la resolvilo de la VPN eble neniam alvenos. Ĉesigu la generadon, poste testu korporacian nomon.

Retumi ene de la distribuaĵo funkcias, kaj la unua interna gastigantnomo malsukcesas en la momento kiam la tunelo leviĝas. La reflekso estas aldoni publikan resolvilon, kio restarigas la interreton kaj faras la korporacian nomon neatingebla por la resto de la tago. En WSL 2, /etc/resolv.conf estas generita eligo kaj ne agordo, kaj ĝuste tiu mekanismo indas esti komprenata. La ripeto ne estas pli bona resolvilo, ĝi estas posedo de la dosiero.

La dosiero estas generata, ne agordata

WSL 2 skribas la dosieron ĉe starto el la Windows-adaptiloj kiujn ĝi vidas en tiu momento, kaj presas komenton supre kiu diras tion. Kiam VPN-kliento poste aldonas aŭ reskribas adaptilon, la distribuaĵo ne nepre regeneras ion, kaj la dosiero daŭre priskribas reton kiu ne plu ekzistas.

Dua malsukcesa reĝimo estas pli silenta: WSL eble kopias servilojn nur el kelkaj adaptiloj. Se la fizika adaptilo jam havas IPv6-resolvilon, la IPv4-serviloj kiujn la VPN-adaptilo provizas povas esti forĵetitaj anstataŭ aldonitaj, kaj la dosiero aspektas kompleta dum ĝi preterlasas ĝuste tiun, kiu respondas al internaj nomoj.

Komparu la Windows-vidon kun la Linux-vido

Legu ambaŭ flankojn antaŭ redaktado. Ene de la distribuaĵo, rigardu kion la dosiero enhavas kaj ĉu ĝi estas ordinara dosiero aŭ ligilo. En Windows, listigu la resolvilon por ĉiu adaptilo, inkluzive tiun kiun la VPN kreis:

ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Kiam la VPN-adaptilo montras la korporaciajn servilojn kaj Linux montras ion alian, la malkonsento estas en generado kaj ne en atingeblo. Komparu la adaptilan liston same kiel la adresojn, ĉar mankanta adaptilo klarigas mankantan servilon. Tiu distingo decidas ĉu vi ripetas WSL aŭ fajroŝirmilon, kaj la du havas nenion komunan.

Malŝaltu la generadon kaj skribu vian propran dosieron

Unu dokumentita agordo malhelpas WSL reskribi la dosieron, kaj ĝi loĝas en /etc/wsl.conf. Aldonu retan sekcion al tiu dosiero:

[network]
generateResolvConf = false

Poste finu la distribuaĵon el Windows per wsl --shutdown kaj restartigu ĝin. Se la vojo estas simbola ligilo kaj ne ordinara dosiero, forigu la ligilon antaŭ ol skribi vian propran enhavon, ĉar skribado tra la ligilo povas rekrei la generitan celon ĉe la sekva starto. De tiu punkto la dosiero estas via kaj nenio reskribas ĝin.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Sen serĉa domajno, neplena gastigantnomo estas kompletigata per la publika radiko kaj revenas kiel nenia tia domajno. timeout malhelpas mortan unuan servilon haltigi ĉiun serĉon, attempts limigas kiom da provoj serĉo elspezas, kaj rotate disigas reŝajncojn anstataŭ ĉiam komenci supre. La interŝanĝo estas ke la dosiero ne plu sekvas VPN kies resolvila adreso ŝanĝiĝas inter sesioj.

Traktu resolvilon kiu moviĝas, poste kontrolu

Kelkaj klientoj donas sesio-specifan resolvilon, do statika dosiero rompiĝas ĉe la sekva konekto. Du aliroj estas defendeblaj. Skribu la dosieron el malgranda skripto kiam ajn la adreso ŝanĝiĝas, aŭ lasu la generadon ŝaltita kaj certigu ke la adaptilo el kiu WSL kopias portas la korporacian servilon. La dua bezonas neniun hokon kaj malsukcesas kiam ajn la generado preterlasas la VPN-adaptilon; ambaŭ ankoraŭ postulas unue solvi la IPv6-konflikton.

Windows ankaŭ aplikas siajn proprajn nomajn politikojn, kiel sufiksa serĉolisto aŭ rezolucia politiko por specifaj domajnoj, kaj kopiado de adaptilaj adresoj ne reproduktas tiujn regulojn. Se nomo solviĝas en Windows kaj ne en la distribuaĵo kun la sama servilo, komparu la sufikso-traktadon antaŭ ol kulpi la tunelon.

Testu per nomo kaj ne per pakaĵo: getent hosts sensor-access0.corp.example trapasas la resolvilan stakon, dum ping eble sukcesas kontraŭ kaŝmemora aŭ laŭvorta adreso. Poste ripetu post malkonekto kaj rekonekto, ĉar agordo kiu funkcias unufoje kaj regeneriĝas ĉe daŭrigo neniam estis ripetita. Konservu la antaŭan enhavon kaj notu kiu komponanto posedas la vojon sur tiu maŝino, por ke la sekva ŝanĝo komenciĝu kun pruvoj.

Rilataj artikoloj