Қай байланыс жауап береді: split-tunnel VPN DNS үшін маршруттау домендері

Қарапайым шолуды жергілікті байланыста қалдырып, компания атаулары туннель ұсынатын DNS сервері арқылы шешілсін. VPN-тің әдепкі маршрутын өшіру бірінші жартысын береді, екіншісін салынбай қалдырады. Әрі қарай жетіспейтін параметр, оның мағынасын өзгертетін тыныс белгісі және қай байланыс шын мәнінде жауап бергенін көрсететін жалғыз пәрмен келеді. Бүкіл мәтінде NetworkManager мен systemd-resolved болжанады, өйткені шатасу әдетте осы жұптан басталады.

Бірінші қадам: маршрутты шешушіден бөлектеңіз

ipv4.never-default маршруттау сұрағына жауап береді және NetworkManager-ге бұл қосылымды барлық IPv4 трафигінің жолы ретінде орнатуға жол бермейді. DNS маршруттау домені басқа сұраққа жауап береді: сәйкес суффикс үшін сұранысты қай байланыстың атау серверлері алады. Екеуі де бірін-бірі талап етпейді, ал профиль біреуін жылдар бойы ұстап, екіншісін жоғалтуы мүмкін. Тек маршрут дегеніміз туннель компанияның қосымша желілерін тасымалдайды және оның шешушісі компания атауларына жауап береді, ал қалғанының бәрі тиіспеген күйде қалады.

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

Екінші қадам: профильге тек-маршруттау доменін қосыңыз

Қосылым corp-vpn деп аталады, компания суффиксі internal.example, ал туннель шешушісіне қазірдің өзінде қол жеткізуге болады деп есептеңіз. Алдымен ағымдағы мәндерді оқыңыз, өйткені төмендегі пәрмендер бұрыннан жазбалары болуы мүмкін қасиеттерді өзгертеді.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Өз қосылым атауыңызбен және суффиксіңізбен алмастырыңыз, өйткені жоғарыдағы мәндер мысал. Қосу таңбасы көрінгенінен маңыздырақ: онымен мән бар тізімге қосылады, ал онсыз қасиет алмастырылады және кеше жұмыс істеген профильден байланыссыз домендер жоғалады. Тильда стильді емес, мінез-құлықты өзгертеді, ал төмендегі абзац оның нені таңдайтынын түсіндіреді. Жазбас бұрын оқуды сақтаңыз, алмастыру пішіні сізді ешқашан таңқалдырмасын.

Бастапқы тильда тек-маршруттау доменін белгілейді, сондықтан сәйкес сұраныстар осы байланыстың серверлеріне кетеді және суффикс қысқа атауларға қосылмайды. Тильданы алып тастасаңыз, сол жол іздеу суффиксіне де айналады, бұл адамдар сирек көздейтін басқа нәтиже. Жоғарыдағы екі параметр де IPv4, сондықтан қос стекті профильге ipv6.never-default және ipv6.dns-search ішінде сол маршруттау домені қажет, әйтпесе IPv6 жағы әдепкі маршрутты қолдана береді және онда ішкі атаулар сәтсіз болады.

Үшінші қадам: resolvectl-ден қай байланыс жауап бергенін сұраңыз

resolvectl status іске қосып, әр байланыстың DNS серверлері мен домендерін оқыңыз, содан кейін сұрауға рұқсатыңыз бар нақты ішкі атауға resolvectl query host.internal.example орындаңыз. Екінші пәрмен маршруттау домені өз жұмысын атқарып жатқанының жалғыз тікелей дәлелі, өйткені ол жауап берген байланысты атайды. Тек күй тізімі конфигурацияны дәлелдейді; сұрау шешуді дәлелдейді.

systemd-resolved ең жақсы сәйкес маршруттау доменін таңдайды, сондықтан басқа байланыстағы неғұрлым нақты домен жарысты әлі де ұтып алуы мүмкін. Сұрау күтпеген байланыстан қайтса, VPN-тің DNS серверіне тиюден бұрын домен тізімдерін оқыңыз. ~. түбір домені бәріне сәйкес келеді, ал егер ол бұрыннан болса, сіздің нақты доменіңіз өз атаулары үшін әлі де ұтады, ал байланыс сұрағаныңыздан әлдеқайда көп нәрсеге жауап береді. Мақсат тек компания атаулары болғанда сол түбір жазбасын жойыңыз немесе тарылтыңыз.

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

Төртінші қадам: атау шешілгенде, бірақ қызмет шешілмегенде

Дұрыс жауап шешудің жұмыс істегенін ғана дәлелдейді, ал қолданбаға әлі де алған мекенжайға маршрут қажет. Бұл маршрут жаңа ғана конфигурацияланған бөлінген әдепкі маршруттан өтуі керек, сондықтан DNS-ті қайта кінәламас бұрын оны тексеріңіз. Содан кейін қызметтің портында қолжетімділікті тексеріңіз, өйткені файл алмасу немесе каталог қызметі шешуде, маршруттауда немесе аутентификацияда сәтсіз болады және әр жағдайда өте ұқсас хабарламалар береді. Нәтижені хабарлағанда осы үш қабатты бөлек ұстаңыз, әйтпесе келесі адам бұрыннан дұрыс болған DNS-ті қайта тексереді.

Осы сұрақпен бірге жүретін Samba өзгерісі қатынау қабатына қатысты, DNS таңдауына емес. Оны атау шешу ақауына қолдану — шағын мәселенің екіншісін алу жолы.

Бесінші қадам: жоғалған доменді түзету үшін шешушіні алмастырмаңыз

Шешуші файлының үстінен жазатын немесе басқа шешуші менеджерін орнататын кеңес басқа мәселені шешеді. Бұлар жүйелік интеграцияның өз сәтсіздік режимдері бар өзгерістері және олардың ешқайсысы ешқашан конфигурацияланбаған маршруттау доменін қоспайды. Машинада атау шешуге қай компонент ие екенін оны алмастырмас бұрын анықтаңыз, өйткені systemd-resolved бар NetworkManager үстелінде бұл иелік бұрыннан анықталған. Оған қарсы күресу — жұмыс істеп тұрған конфигурацияны ешкім қайталай алмайтын нәрсеге айналдыру жолы.

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