resolv.conf-tiedoston muokkaaminen ei korjaa DNS:ää VPN:n katkeamisen jälkeen

Katkaiset VPN:n, ping 1.1.1.1 vastaa yhä, ja jokainen nimikysely jumittuu, ennen kuin sivu lopulta luovuttaa. Sitten cat /etc/resolv.conf näyttää nimipalvelimen, joka on koskaan ollut olemassa vain tunnelin sisällä, yleensä luettelon ensimmäisenä. Sen rivin poistaminen näyttää korjaavan asian noin kymmeneksi minuutiksi, kunnes keskeytys, Wi-Fi-verkkovierailu tai uudelleenkäynnistys palauttaa sen. Muokkaamasi tiedosto ei ole asetus; se on kuvaus linkin tilasta, jonka omistaa toinen komponentti.

Miksi yksi vanhentunut merkintä maksaa sekunteja kyselyä kohden

glibc-resolveri käy nimipalvelinluettelon läpi järjestyksessä ja odottaa aikakatkaisun loppuun ennen kuin yrittää seuraavaa, ja resolv.conf(5) rajoittaa luettelon kolmeen merkintään. Laita tunnelin puoleinen resolveri, kuten 10.8.0.1, luettelon kärkeen sen jälkeen kun tunneli on poissa, ja jokainen kysely maksaa aikakatkaisun ennen kuin putoaa palvelimelle, joka vastaa. Siksi oire näyttää kuolleelta yhteydeltä eikä DNS-virheeltä: selaimet estyvät, aikakatkaisevat ja tarjoilevat joskus välimuistiin tallennetun osoitteen, joka vanhenee myöhemmin.

Se selittää myös, miksi valitus tulee muodossa «internet on rikki». Ping IP-osoitteeseen todistaa, että linkki on kunnossa, mikä saa vian näyttämään sovelluksen vialta. Resolveriluettelo on ensimmäinen asia, joka luetaan, ja viimeinen, jota muokataan.

Myytti: resolv.conf on asetustiedosto

Kysy, mikä polku todella on, ennen kuin muutat sitä:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

systemd-resolved-isännässä se on symbolinen linkki stub-tiedostoon, joka osoittaa osoitteeseen 127.0.0.53, ja todelliset palvelimet elävät linkkikohtaisessa tilassa, jonka resolvectl tulostaa. NetworkManager-isännässä se voi olla tiedosto, jonka NetworkManager kirjoittaa aktiivisesta yhteydestä. Joillakin toimittajien asiakasohjelmilla se on tavallinen tiedosto, joka kirjoitetaan uudelleen paikan päällä yhdistettäessä ja, jos olet epäonnekas, jota ei koskaan palauteta katkaistaessa. Ne ovat kolme eri omistajaa, ja kahden ensimmäisen muokkaaminen käsin joko ei tee mitään tai kestää seuraavaan verkkotapahtumaan.

resolvectl status on näkymä, joka kertoo totuuden: linkkikohtaiset DNS-palvelimet, reititysverkkotunnukset ja onko tunnelilinkki yhä olemassa. resolvectl query example.com menee pidemmälle ja näyttää, mikä liitäntä vastasi. Käytä molempia ennen kuin kosket tiedostoon, ja pidä mielessä, että selain, jolla on oma suojattu DNS, jättää kaiken tämän huomiotta.

Etsi omistaja ennen kuin muokkaat mitään

Kolme komponenttia kilpailee yleensä samasta asetuksesta: systemd-resolved, NetworkManager ja se, mitä VPN-asiakasohjelma asensi. Tunnista ensin elossa oleva:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Jos resolved on aktiivinen ja symbolinen linkki osoittaa sen stubiin, yleinen tiedosto on tuotettua tulostetta ja muokkauksesi on kosmeettinen. Jos NetworkManager omistaa yhteyden, palvelimet kuuluvat yhteysprofiiliin, joten korjaus on nmcli-ominaisuuden muutos eikä tiedoston muokkaus. Jos toimittajan daemon on käynnissä, vain sen oma palautuspolku selviää seuraavasta yhteydestä.

Siivoa linkin tila, jonka asiakasohjelma jätti

Tapettu asiakasohjelma ei voi ajaa siivouskoukkuaan. SIGKILL:iä ei voi saada kiinni lainkaan, kun taas SIGINT ja SIGTERM voidaan, joten tunneli, joka «vain pysähtyi» pakkotapon jälkeen, jättää usein sekä liitännän rekisteröinnin että resolverimerkinnän paikoilleen. Etsi tarkka PID ja lähetä signaali vain sille:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Älä tartu pkill -f vpn tai killall vpn -komentoon ennen kuin olet lukenut koko osumaluettelon. -f sovittaa koko komentoriviin, joten se voi lopettaa kääreskriptin, editori-istunnon tai asiaankuulumattoman prosessin, jonka polku sisältää merkkijonon. Väärän prosessin lopettaminen kesken työn on tapa, jolla resolveriongelmasta tulee kadonnut tiedosto.

resolvectl revert nollaa kyseisen linkin ajon aikaisen DNS-asetuksen, mikä on kapeampaa kuin resolverin uudelleenkäynnistys ja paljon kapeampaa kuin yleisen tiedoston muokkaus. Jos tunnelilinkki on kadonnut kokonaan, systemctl restart NetworkManager rakentaa yhteyden tilan uudelleen, ja se on vaihe, johon lähdeketjut jatkuvasti palaavat. Varo palvelunhallintaa, jossa on Restart=always, koska se voi laittaa tapetun asiakasohjelman ja sen DNS-asetukset suoraan takaisin.

Toinen suunta: työnnetty DNS, joka ei koskaan saapunut

Vanhentuneen merkinnän peilikuva on tunneli, jossa ei ole lainkaan käyttökelpoista resolveria. Profiilin DNS-valinta on pyyntö; yhteyttä hallitsevan komponentin on luovutettava se resolverille. Jos loki näyttää, että palvelin vastaanotettiin mutta tunnelilinkki ei kanna yhtään DNS-asetusta, puuttuva asia on integraatio, ei palvelin.

Testaa luovutus tekemällä se käsin, mikä erottaa «palvelin on väärä» ja «kukaan ei soveltanut sitä»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Kaiken nappaava reititysverkkotunnus lähettää jokaisen nimen kyseiselle linkille, mitä täystunnelin asiakasohjelma haluaa ja mitä jaettua DNS:ää ei saa käyttää. Nämä asetukset katoavat seuraavassa yhteydessä. Tehdäksesi niistä pysyviä NetworkManagerissa poista automaattinen DNS käytöstä, aseta palvelin yhteydelle ja lisää verkkotunnus:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Yritystunnelille, jonka pitäisi vastata vain sisäisiin nimiin, luettele ne vyöhykkeet alkutildellä kaiken nappaavan sijaan, jotta julkiset nimet käyttävät edelleen paikallista resolveria.

Kiertotiet, joista tulee seuraava katkos

resolv.conf-tiedoston kopioiminen ennen yhdistämistä ja palauttaminen jälkeen on runbookissa laillinen rivi, ja se on kiertotie eikä korjaus. Se epäonnistuu juuri silloin kun sillä on merkitystä, koska kaatuminen tai pakotettu uudelleenkäynnistys ohittaa palautuksen. Kirjaa se kiertotieksi, jotta seuraava henkilö ei rakenna sen varaan.

systemd-resolvedin poistaminen käytöstä ja julkisten palvelimien kovakoodaaminen on toinen suosittu liike. Se tekee yhdistämisestä ja katkaisusta ennustettavaa ja poistaa linkkikohtaisen DNS:n kaikilta muilta verkoilta, mikä rikkoo jaetun DNS:n sisäisille nimille ja tekee tyhjäksi sellaisen tunnelin tarkoituksen, joka on tarkoitettu pitämään kyselyt sisällään. resolvconfin asentaminen ja julkisten palvelimien kiinnittäminen maksaa saman ylimääräisellä kerroksella. Käsittele kumpaa tahansa diagnoosina: jos se palauttaa selailun, olet oppinut, että resolverin integraatio on syyllinen, ei että julkiset palvelimet ovat oikein.

Kestävä korjaus on yksi omistaja kerrosta kohden: päätä, mikä komponentti omistaa tunnelilinkin DNS:n ja mikä yleisen oletuksen, kirjoita se muistiin ja poista muut polulta. Tarkista sitten katkaisun jälkeen nimellä, jonka vain VPN ratkaisee. Jos yksityinen nimi vastaa yhä, rekisteröintiä ei poistettu; jos mikään ei ratkea, tiedosto osoittaa palvelimeen, jota ei enää ole. Molemmat näkyvät resolvectlissä ennen kuin avaat selaimen.