Раздзелены 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 таксама можа абыйсці сістэмнае правіла, таму адзін браўзер, які збаіць, пакуль іншы паспяховы, — не супярэчнасць. Параўноўвайце рэзалвер, які адказаў, а не браўзер, які паскардзіўся.
Калі абедзве паловы бачныя, астатняе пытанне — гэта пытанне палітыкі, а не тэхнічнае: якія прасторы імёнаў належаць арганізацыі, хто валодае кожным адказам і якія з іх павінны наогул пакінуць машыну. Запішыце гэта побач з профілем, бо наступнаму чалавеку, які дакранецца да правіла, гэта спатрэбіцца.