Подељени DNS и VPN: правила домена нису IP руте

Ваш лаптоп разрешава intranet.corp кроз тунел, док gitlab.com наставља да иде ка резолверу провајдера, и то је поставка која ради како је пројектована. Две одвојене одлуке су је створиле: правило подударања имена изабрало је резолвер, а рута је вратила одговор. Покварите било коју од њих и прегледач приказује квар који споља изгледа исто. Већина извештаја о подељеном DNS-у описује други квар, цитирајући притом доказе о првом.

Две половине живе на различитим местима и обично их уређују различити људи. Једна је DNS политика повезана са VPN профилом, друга је рута коју тунел инсталира или задржава. Отклањање грешака стаје када нико не утврди која се половина заиста померила.

Две одлуке скривене у једном захтеву

Половина са именом је објекат политике, а не рута. На Windows-у то је политика разрешавања имена на VPN профилу; на Apple платформама скуп домена подударања на објекту DNS подешавања; на Linux-у домен рутирања, линија подељеног резолвера или редослед прекидача услуге имена. Половина са путањом је обично рутирање, инсталирано од тунела или ручно, и нема појма шта је име домаћина. Профил који допушта суфикс само одлучује ко одговара; никада не чини одговор доступним.

Брзи тест симптома их раздваја: замените име адресом. Ако адреса ради, путања је у реду, а правило је погрешно. Ако и адреса не успе, правило може бити тачно, а путања недостаје.

Како свака платформа изражава исто правило имена

Намера је иста, а имена поља нису. Пример копиран са једног клијента на други парсира се чисто и никада се не поклапа. Три облика изгледају овако:

Домен подударања или рутирања је тест суфикса, па intranet.corp покрива git.intranet.corp и не покрива corp.intranet, и његово окретање је најчешћа грешка у целој поставци. Windows носи мапирање као политику разрешавања имена повезану са профилом, са сопственим редоследом приоритета према било којој листи суфикса коју је интерфејс већ имао. Apple платформе повезују домене подударања са објектом DNS подешавања мрежног проширења, а систем их примењује за сваки ограничени резолвер. Ниједан од ових облика није рута и ниједан не може учинити недоступну адресу доступном. Политика разрешавања имена на Windows-у наводи имена поља и правила приоритета за ту платформу, и то нису она која користе документи Apple-а или systemd-а.

Тачан одговор и даље захтева путању

Одговор резолвера је само адреса, а апликација и даље мора да стигне до ње. Дизајн подељеног тунела често гура 10.20.0.0/16 и задржава подразумевану руту, па се унутрашње име разреши, а веза затим виси. Супротан случај је једнако чест: рута постоји, јавни резолвер одговара на приватно име са NXDOMAIN, и квар се региструје као проблем рутирања. Тестирање путање прво вас оставља да зурите у руте за име које се никада не би разрешило.

Постоји и трећа капија коју ниједна половина не покрива. ACL на пролазу, правило заштитног зида или политика на страни клијента могу да одбаце везу након што су обе одлуке биле тачне. Када се име разреши, рута постоји, а веза ипак истиче, престаните да тестирате DNS.

Тестирање имена и путања у фиксном редоследу

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

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Клијент на Windows-у поставља иста два питања другим cmdlet-има. Други извештава интерфејс који би систем заиста користио:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Ако претрага врати адресу и провера путање наведе физички интерфејс, правило имена је радило, а рута није. Ако кратко име не успе док се пуно име разрешава, листа суфикса је погрешна, а не резолвер.

Где поређење обично пође наопако

Прва грешка је питати неповезани јавни резолвер о приватном имену и читати одбијање као доказ о VPN-у. Друга је претпоставити да успешна јавна претрага доказује путању резолвера тунела. Трећа је третирати подељено тунеловање и подељени DNS као једну пројектну одлуку, док распоређивање може бити исправно у једном и покварено у другом. Свака грешка даје самоуверене закључке из теста који никада није вежбао део који се окривљује.

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

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