VPN DNS работи, но .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-от, а не само од канцеларискиот опсег. Запишете го опсегот на доменот, серверот и сопственикот во документацијата на врската. Инаку следниот човек што ќе налета на овој дефект ќе посегне по истото глобално уредување што штотуку го избегнавте.