Коя връзка отговаря: домейни за маршрутизиране на DNS при VPN с разделен тунел

Дръжте обикновеното сърфиране на локалната връзка, докато имената на компанията се резолвират през 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 избира най-добре съответстващия домейн за маршрутизиране, така че по-конкретен домейн на друга връзка все още може да спечели надпреварата. Ако заявката се върне от връзка, която не очаквате, прочетете списъците с домейни, преди да пипате DNS сървъра на VPN. Коренов домейн ~. съвпада с всичко и ако вече присъства, вашият конкретен домейн пак печели за собствените си имена, докато връзката отговаря на много повече, отколкото сте поискали. Премахнете или стеснете този коренов запис, когато целта е била само имена на компанията.

Ако връзката на VPN изобщо не изброява DNS сървър, клиентът никога не е регистрирал такъв. Домейн за маршрутизиране без сървър зад него се проваля различно от липсващ домейн, затова първо поправете регистрацията.

Стъпка четвърта: когато името се резолвира, но услугата не работи

Правилният отговор доказва само, че резолвирането е проработило, а приложението все още се нуждае от маршрут до получения адрес. Този маршрут трябва да оцелее след разделения маршрут по подразбиране, който току-що настроихте, затова го проверете, преди отново да обвинявате DNS. После проверете достъпността на порта на услугата, защото файлов дял или услуга за директория се проваля при резолвиране, маршрутизиране или удостоверяване и дава много сходни съобщения във всеки случай. Дръжте тези три слоя отделно, когато докладвате резултата, иначе следващият човек проверява отново DNS, който вече е бил правилен.

Промяната в Samba, която циркулира заедно с този въпрос, засяга слоя за достъп, а не избора на DNS. Прилагането ѝ към неизправност в резолвирането на имена е начинът, по който малък проблем придобива втори.

Стъпка пета: не заменяйте резолвера, за да поправите липсващ домейн

Съвет, който презаписва файла на резолвера или инсталира друг мениджър на резолвера, решава друг проблем. Това са промени в системната интеграция със собствени режими на отказ и нито една от тях не добавя домейн за маршрутизиране, който никога не е бил конфигуриран. Установете кой компонент притежава резолвирането на имена на машината, преди да го замените, защото на десктоп с NetworkManager и systemd-resolved това притежание вече е определено. Борбата с него е начинът, по който работеща настройка се превръща в нещо, което никой не може да възпроизведе.

Ред на работа: потвърдете, че тунелът предоставя резолвер, добавете домейна само за маршрутизиране, свържете се отново през контролите на профила, проверете отговарящата връзка, после тествайте услугата на нейния порт. Тази последователност оставя резултат, който можете да предадете на следващия човек без втори разговор.