VPN DNS әр сұранысты өзіне алады: NetworkManager-дегі dns-priority-ді түзетіңіз

Кеңсе VPN-іне қосылыңыз, сонда кенеттен әрбір атау сұранысы корпоративтік resolver-ге кетеді. Жалпыға ортақ атаулар әлі шешіледі, сондықтан жергілікті принтер атауы сәтсіз болмайынша немесе split-horizon жазбасы кеңсе мекенжайын қайтармайынша, бірдеңе сынғандай көрінбейді. Кейбір Fedora конфигурацияларында керісінше болады: провайдердің resolver-і туннель көтерілгеннен кейін де жауап беруді жалғастырады. Екеуі де бір сұрақ — бұл сұраныстың иесі қай resolver — және NetworkManager жүйелерінде жауап әр қосылымның DNS қасиеттерінде тұрады.

Екі қосылым, бір жеңімпаз resolver

Әр қосылым DNS басымдығын жариялайды. Қарапайым қосылымдар әдепкіде 50, ал VPN қосылымдары 0 болады, және төменгі мән жеңеді. Дәл осы әдепкі мән VPN қосылымының талап еткен әр домені үшін сымды қосылымнан үнсіз басым түсуінің себебі: ешкім таңдамаса да нөл елуді жеңеді.

Басымдық үміткерлерді реттейді. Ол жеңімпаздан нені сұрауға болатынын шектемейді. Іздеу домені жоқ VPN қосылымы бәрін талап етеді, сондықтан оны артық көру жалпыға ортақ сұраныстарды да туннельге, ал бөлінген туннель дизайнында корпоративтік resolver бағыттайтын жерге жібереді.

Басымдық ретті, іздеу тізімі иелікті шешеді

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

Іздеу тізімі — иелік туралы мәлімдеме. corp.example сияқты жалаң домен іздеу жұрнағы мен маршруттау доменіне айналады. Тек маршруттауға арналған нысан ~corp.example осы жұрнақ астындағы сұраныстарды доменді қысқа атауларға қоспай осы қосылымға жібереді. Сол тильда «осы серверден сұра» мен «осы серверден сұра және менің теруімді аяқта» арасындағы айырмашылық.

Пайдаланушылар қысқа хост атауларын тергенде және жазбалар толық білікті атаулармен де мекенделгенде екі нысанды да қолданыңыз. Тек маршруттау нысанын бөлу керек болғанда, resolver жалаң атауды қалай толықтыратынын өзгертпей қолданыңыз.

Содан кейін артықшылықты айқын етіп, қайта белсендіріңіз:

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"

Теріс басымдық — «осы қосылымды артық көр» деп айтудың құжатталған жолы, ал екі мекенжай тобын да орнату IPv6 қосылымы бар хостта мінез-құлықты біркелкі ұстайды. Қосылымды қайта белсендірмей қасиетті өзгерту қазір жұмыс істеп тұрған ешнәрсені өзгертпейді, сондықтан реттілік айқын up-пен аяқталады.

Бөлуді systemd-resolved ұстасын

Әдепкі dnsmasq плагині сұраныстарды бір жергілікті resolver-ге құяды, сондықтан байланыс бойынша бөлу дөрекі күйінде қалады. systemd-resolved бөлуді әр байланыс бойынша ашады, ал resolvectl query жауап берген байланысты атайды.

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

Осыдан кейін корпоративтік байланыс corp.example мекенжайын алып жүреді, ал жалпыға ортақ resolver қалғанына қызмет етеді. Сұраныс дұрыс емес байланысқа жеткенде, бұйрық оған жауап берген байланысты атайды, және мұны білу тек мекенжайды білуден артық.

DNS дизайнын туннель түріне сәйкестендіріңіз

Барлығын туннель арқылы жіберетін құпиялылық дизайндары бөлу тізімін алып жүрмеуі керек, өйткені ол жалпыға ортақ атауларды жергілікті resolver-ге қайтарып, ниетті жояды. Бөлінген туннель дизайндарына ол қажет: онсыз корпоративтік resolver әрбір жалпыға ортақ сұранысты көреді, және конфигурация туннель құлаған сәтте бұзылады.

Содан кейін туннельден тыс DNS-ті бөгейтін kill switch бар. Атаулар туннель аймақтары үшін шешіледі және қалған барлық жерде сәтсіз болады, ал қосылым мүлдем сау. Жұмысқа жарамды жауаптар — LAN resolver-іне айқын рұқсат немесе тек корпоративтік аймақты жіберетін жергілікті кэш, және екеуі де туннельдегі ақау емес, иесі бар ерекшелік.

Интерфейс іске қосылғанда resolver конфигурациясын қайта жазатын профиль да дәл осылай әрекет етеді: жергілікті resolver қолжетімсіз болғаннан кейін туннель білетін атаулар ғана шешіледі. Қай механизм қолданылса да, әр күйде қандай атаулар жұмыс істеуі керектігін жазып, сол тізімді есептермен айналысатын адамға беріңіз.

Әр байланыс бойынша тексеріңіз, содан кейін қайта қосылғаннан кейін тағы тексеріңіз

Бір ішкі және бір жалпыға ортақ атауды сұраңыз, және сұраныстың шын мәнінде қайда кететінін қараңыз. Ағу тексеру беті қай resolver жауап бергенін айтады, жүйе қай байланысты таңдағанын емес, сондықтан ол жаңа ғана конфигурациялаған реттілік туралы ештеңе айтпайды.

Ажыратып, қайта қосқаннан кейін екі сұранысты қайта орындаңыз. Қосылым белсенді болғанда басымдықтар қайта қолданылады, ал ескі символдық сілтеме ешкім есінде жоқ жаңартудан кейін де қалуы мүмкін. Соңында жазғыңыз келетіні — қай resolver қай жұрнақтың иесі екені, қоса алғанда ертең де күшінде болатын тексеру.