Која веза одговара: рутинг домени за DNS split-tunnel 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 који је већ био исправан.

Промена у Sambи која кружи уз ово питање тиче се слоја приступа, не избора DNS-а. Применити је на квар разрешавања имена је начин на који мали проблем добија други.

Пети корак: не замењујте разрешивач да поправите домен који недостаје

Савет који преписује датотеку разрешивача или инсталира други менаџер разрешивача решава други проблем. То су промене системске интеграције са сопственим режимима отказа и ниједна не додаје рутинг домен који никада није конфигурисан. Утврдите који компонент поседује разрешавање имена на машини пре него што га замените, јер је на радној површини са NetworkManager-ом и systemd-resolved-ом то власништво већ дефинисано. Борба с тим је начин на који радна поставка постаје нешто што нико не може да понови.

Редослед рада: потврдите да тунел пружа разрешивач, додајте домен само за рутирање, поново се повежите преко контрола профила, проверите везу која одговара и затим тестирајте услугу на њеном порту. Тај след оставља резултат који можете предати следећој особи без другог разговора.