VPN-aren DNSak kontsulta guztiak hartzen ditu: konpondu NetworkManager-en dns-priority

Konektatu bulegoko VPN-a eta bat-batean izen-kontsulta guztiak enpresako resolver-era joaten dira. Izen publikoak oraindik ebazten dira, beraz ezer ez dirudi hautsita tokiko inprimagailu baten izenak huts egiten duen arte edo split-horizon erregistro batek bulegoko helbidea itzultzen duen arte. Fedora instalazio batzuetan kontrakoa gertatzen da: hornitzailearen resolver-ak tunela altxatu ondoren ere erantzuten jarraitzen du. Biak galdera bakarra dira — zein resolver den kontsulta honen jabe — eta NetworkManager sistemetan erantzuna konexio bakoitzeko DNS propietateetan bizi da.

Bi konexio, resolver irabazle bakarra

Konexio bakoitzak DNS lehentasun bat adierazten du. Konexio arruntek 50 dute lehenespenez eta VPN konexioek 0, eta balio txikiagoak irabazten du. Lehenespen hori da VPN konexio batek kablearen esteka isilean gainditzen duen arrazoia eskatzen duen domeinu bakoitzerako: zero-k berrogeita hamar gainditzen ditu inork aukeratu gabe.

Lehentasunak hautagaiak ordenatzen ditu. Ez du mugatzen irabazleari zeri buruz galdetzen zaion. Bilaketa-domeinurik gabeko VPN konexio batek dena eskatzen du, beraz hura hobesteak kontsulta publikoak tunelean sartzen ditu eta, tunel zatituaren diseinuan, enpresako resolver-ak birbidaltzen duen tokira.

Lehentasunak ordena erabakitzen du, bilaketa-zerrendak jabetza

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

Bilaketa-zerrenda jabetza-adierazpena da. corp.example bezalako domeinu hutsa bilaketa-atzeranzkin eta bideratze-domeinu bihurtzen da. Bideratze hutseko forma ~corp.example atzeranzkin horren peko kontsultak konexio honetara bidaltzen ditu, domeinua izen laburrei erantsi gabe. Tilde hori da «galdetu zerbitzari honi» eta «galdetu zerbitzari honi eta amaitu nire idazketa» arteko aldea.

Erabili bi formak erabiltzaileek ostalari-izen laburrak idazten dituztenean eta erregistroak erabat kualifikatutako izenekin ere helbideratzen direnean. Erabili bideratze-forma soilik zatitzea nahi duzunean resolver-ak izen hutsa nola osatzen duen aldatu gabe.

Gero egin lehentasuna esplizitu eta aktibatu berriro:

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"

Lehentasun negatiboa «hobetsi konexio hau» esateko modu dokumentatua da, eta bi helbide-familia ezartzeak jokabidea koherente mantentzen du IPv6 konektibitatea duen ostalari batean. Propietatea aldatu eta konexioa berriro aktibatu gabe, orain martxan dagoen ezerk ez du aldatzen, horregatik sekuentzia up esplizitu batekin amaitzen da.

Utzi systemd-resolved-i zatiketa eusten

Lehenespenezko dnsmasq pluginak kontsultak resolver lokal bakarrera bideratzen ditu, beraz esteka bakoitzeko bereizketa zakar geratzen da. systemd-resolved-ek zatiketa esteka bakoitzeko erakusten du, eta resolvectl query-k erantzun zuen estekaren izena ematen du.

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

Horren ondoren enpresako estekak corp.example darama eta resolver publiko batek gainerakoa zerbitzatzen du. Kontsulta esteka okerrean iristen denean, komandoak hari erantzun zion estekaren izena ematen du, eta hori jakitea helbidea soilik ezagutzea baino hobea da.

Egokitu DNS diseinua tunel motari

Dena tuneletik bidaltzen duten pribatutasun-diseinuek ez lukete zatiketa-zerrendarik eraman behar, izen publikoak resolver lokalari itzuliko lizkiokeelako eta asmoa deuseztatuko lukeelako. Tunel zatituaren diseinuek bai behar dute: hura gabe enpresako resolver-ak kontsulta publiko guztiak ikusten ditu, eta konfigurazioa tunelegia erortzen den unean bertan hausten da.

Gero tunelaz kanpoko DNS blokeatzen duen kill switch delakoa dago. Izenak tunelaren zonen arabera ebazten dira eta beste leku guztietan huts egiten dute konexioa erabat osasuntsu dagoen bitartean. Emaitza bideragarriak LANeko resolver-rako baimen esplizitua edo enpresa-eremua soilik birbidaltzen duen cache lokala dira, eta bietako edozein jabea duen salbuespena da, ez tuneleko akatsa.

Interfazea abiatzean resolver konfigurazioa berridazten duen profilek ia berdin jokatzen du: resolver lokala eskuraezin bihurtzen denean, tunelak ezagutzen dituen izenak soilik ebatziko dira. Zein mekanismo aplikatzen den, idatzi zein izenek funtzionatu behar duten egoera bakoitzean, eta eman zerrenda hori txostenak kudeatzen dituenari.

Egiaztatu esteka bakoitzeko, eta berriro berriz konektatu ondoren

Galdetu barne-izen bat eta izen publiko bat, eta begira ezazu kontsulta benetan nora doan. Ihes-egiaztapen orriak zein resolver-ek erantzun duen esaten dizu, ez sistemak zein esteka aukeratu duen, beraz ez du ezer esaten oraintxe konfiguratu duzun ordenari buruz.

Exekutatu bi kontsultak berriro deskonektatu eta berriz konektatu ondoren. Lehentasunak berriro aplikatzen dira konexio bat aktibatzean, eta esteka sinboliko zahar batek inork gogoratzen ez duen eguneraketa bat gaindi dezake. Amaieran idatzita nahi duzuna zein resolver den zein atzeranzkinen jabe da, gehi bihar ere balio duen egiaztapen bat.