Разделен DNS и VPN: правилата за домейни не са IP маршрути
Разделеният DNS избира резолвер по име, а отговорът все още се нуждае от маршрут. Тествайте правилото за домейн и пътя поотделно, на платформата, която действително използвате.
Лаптопът ви разрешава intranet.corp през тунела, докато gitlab.com продължава да отива към резолвера на доставчика, и това е подредбата, работеща както е проектирана. Две отделни решения я създадоха: правило за съвпадение на име избра резолвера, а маршрут върна отговора. Счупете което и да е от двете и браузърът показва повреда, която отвън изглежда еднакво. Повечето доклади за разделен DNS описват второто пропадане, цитирайки доказателства за първото.
Двете половини живеят на различни места и обикновено се редактират от различни хора. Едната е DNS политика, прикачена към VPN профила, другата е маршрут, който тунелът инсталира или задържа. Отстраняването на грешки спира, когато никой не установи коя половина всъщност се е преместила.
Две решения, скрити в една заявка
Половината с името е обект на политика, а не маршрут. В Windows това е политика за разрешаване на имена във VPN профила; в платформите на Apple — набор от домейни за съвпадение в обект с DNS настройки; в Linux — домейн за маршрутизиране, ред за разделен резолвер или редът на превключване на услугата за имена. Половината с пътя е обикновено маршрутизиране, инсталирано от тунела или на ръка, и то няма представа какво е име на хост. Профил, който допуска суфикс, решава само кой отговаря; той никога не прави отговора достъпен.
Бърз тест на симптомите ги разделя: заменете името с адрес. Ако адресът работи, пътят е наред, а правилото е грешно. Ако адресът също се провали, правилото може да е правилно, а пътят да липсва.
Как всяка платформа изразява същото правило за имена
Намерението е идентично, а имената на полетата не са. Пример, копиран от един клиент в друг, се анализира чисто и никога не съвпада. Трите форми изглеждат така:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Домейн за съвпадение или маршрутизиране е тест за суфикс, така че 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 задава същите два въпроса с различни команди. Втората съобщава интерфейса, който системата действително би използвала:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Ако търсенето върне адрес и проверката на пътя посочи физическия интерфейс, правилото за имена е работило, а маршрутът не. Ако краткото име се провали, докато пълното име се разрешава, списъкът със суфикси е грешен, а не резолверът.
Къде сравнението обикновено се обърква
Първата грешка е да питате несвързан публичен резолвер за частно име и да четете отказа като доказателство за VPN. Втората е да приемате, че работещо публично търсене доказва пътя на резолвера на тунела. Третата е да третирате разделното тунелиране и разделния DNS като едно проектно решение, когато едно внедряване може да е правилно в едното и счупено в другото. Всяка грешка дава уверени заключения от тест, който никога не е упражнявал обвиняваната част.
Браузър със свой собствен защитен DNS също може да заобиколи системното правило, поради което един браузър да се проваля, докато друг успява, не е противоречие. Сравнявайте резолвера, който е отговорил, а не браузъра, който се е оплакал.
Щом двете половини са видими, оставащият въпрос е въпрос на политика, а не технически: кои пространства от имена принадлежат на организацията, кой притежава всеки отговор и кои от тях трябва изобщо да напуснат машината. Запишете това до профила, защото следващият човек, който докосне правилото, ще се нуждае от него.