VPN DNS жұмыс істейді, бірақ .local атаулары әлі шешілмейді: оларды кім шешеді?

Бір VPN-де екі машина, бірдей хост атауы, және олардың тек біреуі ғана оны шешеді: айырмашылық әдетте туннельде емес, қай шешуші жауап бергенінде. Linux жұмыс үстелінде бұл атау атау қызметінің ауыстырғышынан, systemd-resolved stub-ынан немесе қолданба өзімен әкелген шешушіден өтуі мүмкін, және олардың әрқайсысы сол бір суффикске өз ережесін қолданады. Ережелер дәл суффиксте ажырайды, өйткені .local бейтарап белгі емес. Бірдеңенің қандай ретпен жүретінін өзгертуден бұрын сәтсіз программаның шын мәнінде қай жолмен жүретінін анықтаңыз.

Екі шешуші, екі түрлі жауап

Дәстүрлі glibc іздеуі nsswitch.conf-нің hosts: жолымен жүреді және біреуі жауап бергенше әр модульден кезекпен сұрайды. Stub тыңдаушысы арқылы systemd-resolved-пен сөйлесетін клиент оның орнына бір процестен сұрайды, ал бұл процесс әр қосылым үшін саясатты және өзінің ерекше жағдайларын қолданады. Өз шешушісін алып келетін немесе солай істейтін кітапхананы байланыстыратын қолданба екеуін де айналып өте алады. Осылайша бір хост атауының бір машинада үш иесі болуы мүмкін, және олардың тек біреуі VPN нені көздегенін біледі.

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

Қай команда шын мәнінде сіздің шешушіңізден сұрады

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Біріншісі конфигурацияланған модульдер арқылы сұрайды, типтік программа осыны бастан кешіреді. Екіншісі systemd-resolved-тен тікелей сұрайды және жауап берген қосылым, протокол және сервер туралы хабарлайды. Серверден мекенжай бойынша сұрау тек серверде жазба бар екенін дәлелдейді, өйткені ол қолданбаның одан қашан да сұрағанын білдірмейді. VPN таситын қосылымды және ол мәлімдеген домендерді оқыңыз, содан кейін бұл тізімді сәтсіз атаудағы суффикспен салыстырыңыз.

Неге .local сіздің unicast аймағыңызды аттап кетеді

systemd-resolved анықтамасы бойынша .local-мен аяқталатын көпбелгілі атаулар mDNS қосулы болса, әдеттегі unicast DNS-ке емес, multicast DNS-ке барады. RFC 6762 бұл атау кеңістігін link-local multicast үшін бөліп қояды, сондықтан корпоративтік аймақ сол суффикс үшін ешқашан сұралмайтын дұрыс жазбаны сақтай алады. Туннель шешушіні мінсіз маршруттай алады және бәрібір жарыста ұтылады. Кэштен сәтті ping жаңа ғана болған іздеу туралы ештеңе айтпайды.

Құжатталған ерекшелік бар, және ол осы жағдайлардың көбін шешеді: қосылым сол суффиксті іздеу домені немесе маршруттау домені деп жарияласа, демон оны unicast жолында ұстайды және multicast ерекше жағдайын аттап кетеді. Бұл әр қосылымның саясаты, жаһандық артықшылық емес. Бір VPN сервері бар екі машина әртүрлі әрекет етуі мүмкін, егер бір желілік профиль доменді жариялап, екіншісі жарияламаса, сондықтан өңдегеніңіз есіңізде қалған профильді емес, белсенді профильді оқыңыз.

Тар ерекшелік жаһандық қайта реттеуден басым

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

Ол үзілістен кейін де сақталады, өйткені қосылым қайта келгенде қосылым саясаты қайта қолданылады. Ортақ nsswitch.conf-ні өңдеу — азғызарлық және қымбатырақ балама, өйткені ол машинадағы әр атау үшін іздеу мінез-құлқын өзгертеді, соның ішінде жергілікті анықтау. Multicast демонын өшіру де балама емес: ол жергілікті мінез-құлықты алып тастайды, бірақ ешбір шешушіге корпоративтік аймақты үйретпейді. Егер қызмет мұрагерлік емес, жаңа болса, оны ұйымыңыз бақылайтын қосымша доменге орналастырыңыз және бәсекелестікті толығымен аттап өтіңіз. Атау firmware-де бекітілген немесе затбелгіге басылған болса, тар ерекшелікті таңдаңыз, ал клиентті әлі бақылайтын болсаңыз, жаңа қосымша доменді таңдаңыз.

Өзгерістен кейін нені дәлелдеу керек

Түзетуді сынау үшін орнатқан құралмен емес, қолданбаның өз іздеуімен дәлелдеңіз және оның орнына жауап бере алатын кез келген кэшті тазалаңыз. Содан кейін шешуші жолын және жауап берген қосылымды растаңыз. Соңында жергілікті анықтаудың өзгеріске дейінгідей әрекет ететінін тексеріңіз, өйткені көрінбей қалған принтер — адамдар ең соңында байқайтын бөлік. Бұл үш команда атауды, жолды және TLS сәйкестігін дәл осы ретпен тексереді:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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