VPN-DNS nimt elke sykopdracht: reparearje dns-priority yn NetworkManager

In VPN-ferbining hat standert prioriteit 0 en easket elk domein op. Set foar de folchoarder in negative prioriteit, en brûk dêrnei routingdomeinen om de rest werom te jaan.

Ferbyn it kantoar-VPN en ynienen giet elke namsoere sykopdracht nei de bedriuwssolver. Iepenbiere nammen wurde noch oplost, dus neat liket stikken oant in lokale printernamme mislakket of in split-horizon-record it kantoaradres weromjout. Op guon Fedora-ynstallaasjes bart it tsjinoerstelde: de resolver fan de provider antwurdet troch nei’t de tunnel omheech is. Beide binne ien fraach — hokker resolver is eigner fan dizze oanfraach — en op NetworkManager-systemen wennet it antwurd yn de DNS-eigenskippen fan elke ferbining.

Twa ferbinings, ien winnende resolver

Elke ferbining ferklearret in DNS-prioriteit. Gewoane ferbinings steane standert op 50 en VPN-ferbinings op 0, en de legere wearde wint. Krekt dy standert is de reden dat in VPN-ferbining de kabelferbining stil foarby giet foar elk domein dat se easket: nul ferslacht fyftich sûnder dat immen it keazen hat.

Prioriteit oardert de kandidaten. It beheindet net wêr’t de winner oer frege wurdt. In VPN-ferbining sûnder sykdomein easket alles op, dus har foarkar stjoert ek iepenbiere oanfragen de tunnel yn en, yn in split-tunnel-ûntwerp, dêr’t de bedriuwssolver nei trochstjoert.

Prioriteit beslist de folchoarder, de syklist beslist it eigendom

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

De syklist is de eigendomsferklearring. In keal domein lykas corp.example wurdt in syk-efterheaksel en in routingdomein. De foarm allinnich foar routing ~corp.example stjoert sykopdrachten ûnder dat efterheaksel nei dizze ferbining sûnder it domein oan koarte nammen ta te foegjen. Dy tilde is it ferskil tusken «freegje dizze server» en «freegje dizze server en meitsje myn typwurk ôf».

Brûk beide foarmen as brûkers koarte hostnammen type en de records ek mei folslein kwalifisearre nammen adressearre wurde. Brûk allinnich de routingfoarm as jo de splitsing wolle sûnder te feroarjen hoe’t de resolver in keal namme foltôget.

Meitsje dan de foarkar eksplisyt en reaktivearje:

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"

In negative prioriteit is de dokumintearre manier om te sizzen «foarkar dizze ferbining», en beide adresfamyljes ynstelle hâldt it gedrach konsekwint op in host mei IPv6-ferbining. De eigenskip feroarje sûnder de ferbining te reaktivearjen feroaret neat fan wat no rint, dêrom einiget de sekwinsje mei in eksplisite up.

Lit systemd-resolved de splitsing hâlde

De standert dnsmasq-plug-in sammelet oanfragen yn ien lokale resolver, dus de skieding per keppeling bliuwt grof. systemd-resolved lit de splitsing per keppeling sjen, en resolvectl query neamt de keppeling dy’t antwurde.

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

Dêrnei draacht de bedriuwskeppeling corp.example en in iepenbiere resolver tsjinnet de rest. As in oanfraach by de ferkearde keppeling útkomt, neamt it kommando de keppeling dy’t derop antwurde, en dat witte is better as allinnich it adres witte.

Bring it DNS-ûntwerp yn oerienkomst mei it tunneltype

Privacy-ûntwerpen dy’t alles troch de tunnel stjoere, moatte gjin splitsingslist drage, om’t dy iepenbiere nammen weromjaan soe oan de lokale resolver en it doel tsjinwurkje soe. Split-tunnel-ûntwerpen hawwe der ien nedich: sûnder dy sjocht de bedriuwssolver elke iepenbiere oanfraach, en de opset brekt op it stuit dat de tunnel falt.

Dan is der de kill switch dy’t DNS bûten de tunnel blokkearret. Nammen wurde oplost foar de sônes fan de tunnel en mislûkje oeral oars wylst de ferbining hielendal sûn is. De wurkbere antwurden binne in eksplisite tastimming foar de LAN-resolver of in lokale cache dy’t allinnich de bedriuwssône trochstjoert, en beide binne in útsûndering mei in eigner, gjin mankement yn de tunnel.

In profyl dat de resolver-konfiguraasje by it starten fan de ynterface oerskriuwt, docht hast itselde: sadree’t de lokale resolver net berikber is, wurde allinnich de nammen dy’t de tunnel ken oplost. Hokker meganisme ek jildt, skriuw op hokker nammen yn hokker steat wurkje moatte, en jou dy list oan wa’t de meldingen behannelet.

Kontrolearje per keppeling, en nochris nei opnij ferbinen

Freegje ien ynterne en ien iepenbiere namme, en sjoch wêr’t de oanfraach echt hinne giet. In lek-kontrôle-side fertelt hokker resolver antwurde, net hokker keppeling it systeem keas, dus it seit neat oer de oardering dy’t jo krekt ynsteld hawwe.

Rin de beide oanfragen nochris nei in ûntkoppeling en opnij ferbinen. Prioriteiten wurde opnij tapast as in ferbining aktivearret, en in âlde symboalyske keppeling kin in upgrade oerlibje dy’t nimmen him betinkt. Wat jo oan ’e ein opskriuwegje wolle, is hokker resolver eigner is fan hokker efterheaksel, plus in kontrôle dy’t moarn noch jildt.

Relatearre artikelen