Tengdu skrifstofu-VPN-ið og skyndilega fer hver nafnuppfletting til fyrirtækis resolver. Opinber nöfn leysast enn, svo ekkert virðist í ólagi fyrr en nafn staðbundinnar prentara bregst eða split-horizon-færsla skilar skrifstofuheimilinu. Í sumum Fedora-uppsetningum gerist hið gagnstæða: resolver þjónustuveitunnar heldur áfram að svara eftir að göngin eru komin upp. Bæði eru ein spurning — hvaða resolver á þessa fyrirspurn — og á NetworkManager-kerfum býr svarið í DNS-eiginleikum hverrar tengingar.

Tvær tengingar, einn sigurvegari

Hver tenging tilgreinir DNS-forgang. Venjulegar tengingar eru sjálfgefið 50 og VPN-tengingar 0, og lægra gildið vinnur. Einmitt þessi sjálfgefna stilling er ástæðan fyrir því að VPN-tenging fer hljóðlega fram úr snúrutengingu fyrir hvert lén sem hún gerir tilkall til: núll vinnur fimmtíu án þess að nokkur hafi valið það.

Forgangurinn raðar umsækjendunum. Hann takmarkar ekki við hvað sigurvegarinn er spurður. VPN-tenging án leitar-léns gerir tilkall til alls, svo að velja hana sendir líka opinberar fyrirspurnir inn í göngin og, í skiptri göngum, þangað sem fyrirtækis resolver framsendir.

Forgangur raðar, leitarlistinn ræður eignarhaldi

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

Leitarlistinn er eignarhaldsyfirlýsingin. Bert lén eins og corp.example verður leitarviðskeyti og beiningalén. Aðeins-beiningar formið ~corp.example sendir uppflettingar undir því viðskeyti til þessarar tengingar án þess að bæta léninu við stutt nöfn. Þessi tilda er munurinn á „spyrðu þennan netþjón“ og „spyrðu þennan netþjón og kláraðu skrifin mín“.

Notaðu bæði formin þegar notendur slá inn stutt hýsilnöfn og færslurnar eru líka áfangaðar með fullum hæfum nöfnum. Notaðu aðeins beiningarformið þegar þú vilt skiptinguna án þess að breyta því hvernig resolver klárar bert nafn.

Gerðu því næst valið skýrt og endurvirkjaðu:

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"

Neikvæður forgangur er skjalfesta leiðin til að segja „vilja þessa tengingu frekar“, og að stilla báðar heimilisfangafjölskyldur heldur hegðuninni samkvæmri á hýsli með IPv6-tengingu. Að breyta eiginleikanum án þess að endurvirkja tenginguna breytir engu sem er í gangi núna, þess vegna endar röðin á skýru up.

Láttu systemd-resolved halda skiptingunni

Sjálfgefna dnsmasq-viðbótin streymir fyrirspurnum í einn staðbundinn resolver, svo aðskilnaður eftir hlekkjum verður grófur. systemd-resolved sýnir skiptinguna eftir hlekkjum, og resolvectl query nefnir hlekkinn sem svaraði.

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

Eftir það ber fyrirtækishlekkurinn corp.example og opinber resolver þjónar afganginum. Þegar fyrirspurn lendir á röngum hlekk nefnir skipunin hlekkinn sem svaraði henni, og að vita það er betra en að þekkja aðeins heimilisfangið.

Lagaðu DNS-hönnunina að gerð ganganna

Næðishönnun sem sendir allt í gegnum göngin ætti ekki að bera skiptingarlista, því hann myndi skila opinberum nöfnum til staðbundins resolver og ógilda ætlunina. Skiptigönguhönnun þarf einn: án hans sér fyrirtækis resolver hverja opinbera fyrirspurn, og uppsetningin brotnar á þeirri sekúndu sem göngin falla.

Svo er kill switch sem lokar DNS utan ganganna. Nöfn leysast fyrir svæði ganganna og bregðast alls staðar annars staðar á meðan tengingin er fullkomlega heilbrigð. Vinnanleg svör eru skýrt leyfi fyrir resolver LAN-svæðisins eða staðbundið skyndiminni sem framsendir aðeins fyrirtækjavatnið, og hvort tveggja er undantekning með eiganda en ekki galli í göngunum.

Prófíll sem endurskrifar resolver-stillinguna við ræsingu viðmótsins hagar sér nánast eins: þegar staðbundni resolverinn er óaðgengilegur leysast aðeins nöfnin sem göngin þekkja. Hvaða fyrirkomulag sem gildir, skrifaðu niður hvaða nöfn eiga að virka í hverju ástandi og gefðu þann lista þeim sem tekur við tilkynningunum.

Sannprófaðu eftir hlekkjum og svo aftur eftir endurtengingu

Spyrðu eitt innra og eitt opinbert nafn og fylgstu með hvert fyrirspurnin fer í raun. Lekkaprófunarsíða segir þér hvaða resolver svaraði, ekki hvaða hlekk kerfið valdi, svo hún segir ekkert um röðina sem þú varst að stilla.

Keyrðu fyrirspurnirnar tvær aftur eftir að hafa aftengt og endurtengt. Forgangar eru settir aftur þegar tenging verður virk, og gamall táknrænn hlekkur getur lifað uppfærslu sem enginn man eftir. Það sem þú vilt hafa skrifað niður að lokum er hvaða resolver á hvaða viðskeyti, auk athugunar sem gildir á morgun líka.

Tengdir greinar