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 дарегинен да кабыл алаганын ырастаңыз. Домендин аймагын, серверди жана ээсин туташуу документтерине жазыңыз. Болбосо, бул бузулушка туш болгон кийинки адам дал жаңы эле качкан глобалдык түзөтүүгө кайрылат.