VPN:n DNS ottaa kaikki haut: korjaa dns-priority NetworkManagerissa

Yhdistä toimiston VPN, ja yhtäkkiä jokainen nimihaku menee yrityksen resolverille. Julkiset nimet ratkeavat edelleen, joten mikään ei näytä rikkinäiseltä ennen kuin paikallisen tulostimen nimi epäonnistuu tai split-horizon-tietue palauttaa toimiston osoitteen. Joissakin Fedora-asennuksissa käy päinvastoin: operaattorin resolver vastaa edelleen, kun tunneli on pystyssä. Molemmat ovat yksi kysymys — mikä resolver omistaa tämän kyselyn — ja NetworkManager-järjestelmissä vastaus asuu kunkin yhteyden DNS-ominaisuuksissa.

Kaksi yhteyttä, yksi voittava resolver

Jokainen yhteys ilmoittaa DNS-prioriteetin. Tavalliset yhteydet ovat oletuksena 50 ja VPN-yhteydet 0, ja pienempi arvo voittaa. Juuri tämä oletus on syy siihen, että VPN-yhteys ohittaa hiljaa kaapeliyhteyden jokaisen vaatimansa verkkotunnuksen osalta: nolla voittaa viisikymmentä ilman, että kukaan valitsi sitä.

Prioriteetti järjestää ehdokkaat. Se ei rajoita, mitä voittajalta kysytään. VPN-yhteys ilman hakutoimialuetta vaatii kaiken, joten sen suosiminen lähettää myös julkiset kyselyt tunneliin ja jaetun tunnelin mallissa sinne, minne yrityksen resolver välittää.

Prioriteetti päättää järjestyksen, hakuluettelo omistajuuden

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Hakuluettelo on omistajuusilmoitus. Paljas verkkotunnus kuten corp.example tulee hakuliitteeksi ja reititysverkkotunnukseksi. Vain reititykseen tarkoitettu muoto ~corp.example lähettää kyseisen liitteen alle kuuluvat haut tälle yhteydelle lisäämättä verkkotunnusta lyhyisiin nimiin. Tuo tilde on ero sanojen «kysy tältä palvelimelta» ja «kysy tältä palvelimelta ja lopeta kirjoitukseni» välillä.

Käytä molempia muotoja, kun käyttäjät kirjoittavat lyhyitä isäntänimiä ja tietueisiin viitataan myös täysin kvalifioiduilla nimillä. Käytä vain reititysmuotoa, kun haluat jaon muuttamatta sitä, miten resolver täydentää paljaan nimen.

Tee sitten suosituksesta selkeä ja aktivoi yhteys uudelleen:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Negatiivinen prioriteetti on dokumentoitu tapa sanoa «suosi tätä yhteyttä», ja molempien osoiteperheiden asettaminen pitää käytöksen yhtenäisenä isännässä, jossa on IPv6-yhteys. Ominaisuuden muuttaminen ilman yhteyden uudelleenaktivointia ei muuta mitään siitä, mikä on nyt käynnissä, siksi sarja päättyy nimenomaiseen up-komentoon.

Anna systemd-resolvedin pitää jako

Oletusarvoinen dnsmasq-liitännäinen kokoaa kyselyt yhteen paikalliseen resolveriin, joten erottelu linkeittäin jää karkeaksi. systemd-resolved näyttää jaon linkeittäin, ja resolvectl query nimeää linkin, joka vastasi.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Sen jälkeen yrityksen linkki kantaa corp.example-osoitteen ja julkinen resolver palvelee loput. Kun haku osuu väärälle linkille, komento nimeää linkin, joka siihen vastasi, ja sen tietäminen on parempaa kuin pelkän osoitteen tietäminen.

Sovita DNS-suunnittelu tunnelin tyyppiin

Yksityisyysratkaisut, jotka lähettävät kaiken tunnelin läpi, eivät saisi kantaa jakoluetteloa, koska se palauttaisi julkiset nimet paikalliselle resolverille ja kumoaisi tarkoituksen. Jaetun tunnelin ratkaisut tarvitsevat sellaisen: ilman sitä yrityksen resolver näkee jokaisen julkisen kyselyn, ja asetelma hajoaa heti, kun tunneli putoaa.

Sitten on kill switch, joka estää DNS:n tunnelin ulkopuolella. Nimet ratkeavat tunnelin vyöhykkeille ja epäonnistuvat kaikkialla muualla, vaikka yhteys on täysin kunnossa. Toimivat vastaukset ovat nimenomainen lupa lähiverkon resolverille tai paikallinen välimuisti, joka välittää vain yrityksen vyöhykkeen, ja kumpikin on poikkeus, jolla on omistaja, ei tunnelin vika.

Profiili, joka kirjoittaa resolverin asetukset uudelleen liitännän käynnistyessä, käyttäytyy lähes samoin: kun paikallinen resolver ei ole tavoitettavissa, vain tunnelin tuntemat nimet ratkeavat. Mikä tahansa mekanismi onkaan käytössä, kirjoita ylös, mitkä nimet on tarkoitettu toimimaan missäkin tilassa, ja anna luettelo sille, joka käsittelee ilmoitukset.

Varmista linkeittäin ja vielä uudelleen yhteyden palauttamisen jälkeen

Kysy yksi sisäinen ja yksi julkinen nimi ja katso, mihin kysely todella menee. Vuototarkistussivu kertoo, mikä resolver vastasi, ei sitä, minkä linkin järjestelmä valitsi, joten se ei kerro mitään juuri määrittämästäsi järjestyksestä.

Aja kaksi kyselyä uudelleen yhteyden katkaisun ja palauttamisen jälkeen. Prioriteetit otetaan uudelleen käyttöön, kun yhteys aktivoituu, ja vanha symbolinen linkki voi säilyä päivityksen yli, jota kukaan ei muista. Lopuksi haluat kirjata, mikä resolver omistaa minkä liitteen, sekä tarkistuksen, joka pitää vielä huomennakin.