DNS преко VPN-а ради, али .local имена и даље не успевају: ко их решава?

Две машине на истом VPN-у, исто име домаћина, и само једна од њих га решава: разлика обично није у тунелу, већ у томе који је резолвер одговорио. На Linux радној површини то име може проћи кроз прекидач услуга имена, кроз stub systemd-resolved или кроз резолвер који је апликација донела са собом, и сваки од њих примењује своје правило на исти суфикс. Управо на суфиксу се правила разилазе, јер .local није неутрална ознака. Откријте којим путем програм који не успева заиста иде, пре него што промените редослед по ком се нешто извршава.

Два резолвера, два различита одговора

Традиционална glibc претрага пролази кроз ред hosts: у nsswitch.conf и пита сваки модул редом док један не одговори. Клијент који разговара са systemd-resolved преко stub слушаоца уместо тога пита један процес, и тај процес примењује политику по вези плус своје посебне случајеве. Апликација која доноси сопствени резолвер или повезује библиотеку која то чини може да заобиђе оба. Тако једно име домаћина може имати три власника на једној машини, и само један од њих зна шта је VPN намеравао.

Утврдите власника пре него што било шта промените, јер је поправка другачија за сваког од тројице. Прегледач и алатка командне линије на истој радној површини могу легитимно да се не слажу, и то неслагање је траг, а не грешка. Ако прегледач решава име а алатка не, ви отклањате грешке на путу резолвера, а не на VPN путу. Потврдите пут одвојено, да се грешка усмеравања не помеша са грешком услуге имена. Када се оба слажу, грешка је изнад домаћина и конфигурација резолвера овде није вредна још једне измене.

Која команда је заиста питала ваш резолвер

Две команде само за читање одговарају на повезана питања, и њихово поређење локализује проблем брже од читања конфигурације. Користите стварно интерно име и држите излаз приватним, јер интерни записи остају интерни. Покрените обе у истој сесији у којој ради програм који не успева:

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

Прва пита преко конфигурисаних модула, што типичан програм доживљава. Друга пита директно systemd-resolved и извештава о вези, протоколу и серверу који је одговорио. Питање корпоративног сервера по адреси доказује само да сервер држи запис, јер не говори ништа о томе да ли га је апликација икада питала. Прочитајте везу која носи VPN и домене које тврди, а затим упоредите тај списак са суфиксом у имену које не успева.

Зашто .local заобилази вашу unicast зону

референца systemd-resolved наводи да имена са више ознака која се завршавају на .local, када је mDNS омогућен, обично иду у multicast DNS, а не у обични unicast DNS. RFC 6762 издваја тај простор имена за link-local multicast, па корпоративна зона може да држи исправан запис за који се за тај суфикс никада не пита. Тунел може савршено да рутира резолвер и да ипак изгуби трку. Успешан ping из кеша не говори ништа о претрази која се управо догодила.

Постоји документовани изузетак, и он решава већину ових случајева: када веза декларише тај суфикс као домен за претрагу или домен за рутирање, демон га држи на unicast путу и прескаче посебан multicast случај. То је политика по вези, а не глобална предност. Две машине са истим VPN сервером могу се понашати различито када један мрежни профил декларише домен, а други не, зато читајте активни профил, а не онај за који се сећате да сте га уређивали.

Уски изузетак побеђује глобално преуређење

За постојећу зону коју не можете да преименујете, затражите од власника резолвера и VPN-а да декларишу домен на вези која га носи. Запис домена за рутирање за тај један суфикс плус предвиђена адреса сервера је мала измена са именованим власником, и живи са везом, а не у ручно уређеној датотеци.

Она преживљава и прекид, јер се политика везе поново примењује када се веза врати. Уређивање заједничког nsswitch.conf је примамљива и скупља алтернатива, јер мења понашање претраге за свако име на машини, укључујући локално откривање. Искључивање multicast демона такође није еквивалентно: уклања локално понашање без учења било ког резолвера о корпоративној зони. Ако је услуга нова, а не наследна, ставите је под поддомен који контролише ваша организација и потпуно прескочите конкуренцију. Изаберите уски изузетак када је име фиксирано у фирмверу или одштампано на етикети, и изаберите нови поддомен када још увек контролишете клијента.

Шта доказати после измене

Докажите поправку сопственом претрагом апликације, а не алатом који сте инсталирали за тестирање, и очистите сваки кеш који би могао да одговори уместо ње. Затим потврдите пут резолвера и везу која је дала одговор. На крају проверите да се локално откривање понаша као пре измене, јер штампач који престане да се појављује је део који људи најкасније примете. Ове три команде проверавају име, пут и 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 адресе, а не само из канцеларијског опсега. Упишите обим домена, сервер и власника у документацију везе. Иначе ће следећа особа која наиђе на ову грешку посегнути за истом глобалном изменом коју сте управо избегли.