VPN-DNS eis elke opsoektog: herstel NetworkManager se dns-prioriteit

Koppel die kantoor-VPN en skielik gaan elke naamopsoektog na die korporatiewe resolver. Openbare name los steeds op, so niks lyk stukkend totdat ’n plaaslike drukernaam misluk of ’n split-horizon-rekord die kantooradres teruggee. Op sommige Fedora-opstellings gebeur die teenoorgestelde: die ISP-resolver antwoord steeds nadat die tonnel op is. Albei is een vraag — watter resolver besit hierdie navraag — en op NetworkManager-stelsels woon die antwoord in die DNS-eienskappe per verbinding.

Twee verbindings, een wenresolver

Elke verbinding verklaar ’n DNS-prioriteit. Gewone verbindings staan by verstek op 50 en VPN-verbindings op 0, en die laer waarde wen. Daardie verstek is hoekom ’n VPN-verbinding stilweg die bedrade skakel vir elke domein wat hy eis verbygaan: nul klop vyftig sonder dat iemand dit kies.

Prioriteit orden die kandidate. Dit beperk nie waaroor die wenner gevra word nie. ’n VPN-verbinding sonder ’n soekdomein eis alles, so om dit te verkies stuur ook openbare navrae in die tonnel in en, in ’n split-tonnel-ontwerp, na wat die korporatiewe resolver ook al aanstuur.

Prioriteit bepaal volgorde, die soeklys bepaal eienaarskap

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

Die soeklys is die eienaarskapverklaring. ’n Kaal domein soos corp.example word ’n soekagtervoegsel en ’n roeteringsdomein. Die slegs-roetering-vorm ~corp.example stuur opsoektogte onder daardie agtervoegsel na hierdie verbinding sonder om die domein by kort name aan te heg. Daardie tilde is die verskil tussen “vra hierdie bediener” en “vra hierdie bediener en maak my tikwerk klaar”.

Gebruik albei vorms wanneer gebruikers kort gasheername tik en die rekords ook as volledig gekwalifiseerde name geadresseer word. Gebruik net die roeteringsvorm wanneer jy die splitsing wil hê sonder om te verander hoe die resolver ’n kaal naam voltooi.

Maak dan die voorkeur eksplisiet en heraktiveer:

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"

’n Negatiewe prioriteit is die gedokumenteerde manier om te sê “verkies hierdie verbinding”, en om albei adresfamilies te stel hou die gedrag konsekwent op ’n gasheer met IPv6-verbinding. Om die eienskap te verander sonder om die verbinding te heraktiveer, verander niks wat tans loop nie, en daarom eindig die reeks met ’n eksplisiete up.

Laat systemd-resolved die splitsing hou

Die verstek dnsmasq-inprop stuur navrae in een plaaslike resolver in, so skeiding per skakel bly grof. systemd-resolved stel die splitsing per skakel bloot, en resolvectl query noem die skakel wat geantwoord het.

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

Daarna dra die korporatiewe skakel corp.example en ’n openbare resolver bedien die res. Wanneer ’n opsoektog die verkeerde skakel bereik, noem die opdrag die skakel wat dit geantwoord het, en om dit te weet is beter as om net die adres te ken.

Pas die DNS-ontwerp by die tonneltipe aan

Privaatheidsontwerpe wat alles deur die tonnel stuur, moet nie ’n splitlys dra nie, want dit sou openbare name aan die plaaslike resolver teruggee en die bedoeling verydel. Split-tonnel-ontwerpe het een nodig: sonder dit sien die korporatiewe resolver elke openbare navraag, en die opstelling breek die oomblik wanneer die tonnel val.

Dan is daar die doodskakelaar wat DNS buite die tonnel blokkeer. Name los op vir die tonnel se sones en misluk oral elders terwyl die verbinding heeltemal gesond is. Die werkbare antwoorde is ’n eksplisiete toelating vir die LAN-resolver of ’n plaaslike kas wat net die korporatiewe sone aanstuur, en enige van die twee is ’n uitsondering met ’n eienaar eerder as ’n fout in die tonnel.

’n Profiel wat die resolver-konfigurasie by koppelvlakbegin herskryf, werk omtrent dieselfde: sodra die plaaslike resolver onbereikbaar is, los net die name op wat die tonnel ken. Watter meganisme ook al geld, skryf neer watter name in elke toestand bedoel is om te werk, en gee daardie lys aan wie ook al die verslae hanteer.

Verifieer per skakel, en weer ná herverbinding

Vra een interne en een openbare naam, en kyk waar die navraag werklik gaan. ’n Lekkontrole-bladsy sê watter resolver geantwoord het, nie watter skakel die stelsel gekies het nie, so dit sê niks oor die ordening wat jy pas opgestel het nie.

Hardloop die twee navrae weer ná ’n ontkoppeling en herverbinding. Prioriteite word weer toegepas wanneer ’n verbinding aktiveer, en ’n ou sinakkoppeling kan ’n opgradering oorleef wat niemand onthou nie. Wat jy aan die einde neergeskryf wil hê, is watter resolver watter agtervoegsel besit, plus ’n kontrole wat môre nog geld.