dnsmasq адкідае прыватны DNS-адказ: ці вінаватая абарона ад rebinding?

DNS-сервер кампаніі вяртае чаканы прыватны адрас, і ўсё ж запыт праз лакальны перасылальны рэзалвер не ўдаецца. Адказ існуе, што выключае зону вышэй і сам запіс. Застаецца крок, на якім рэзалвер вырашае, ці вяртаць гэты адказ кліенту. Калі гэты рэзалвер — dnsmasq, адмова, верагодна, ужо ў журнале.

Атрымаць адказ і вырашыць яго вярнуць — гэта два розныя крокі.

Параўнайце тое самае імя на абодвух рэзалверах

Запішыце, які рэзалвер насамрэч выкарыстоўвае праграма, і дакладнае імя хоста, якое яна запытвае. Затым параўнайце вынік зверху з падзеяй перасылальнага рэзалвера для таго ж імя. Адсутны адказ зверху, адмоўны адказ з кэша і адмова ў журнале патрабуюць трох розных выпраўленняў.

Адрас, бачны ў прамым дыягнастычным запыце, не даказвае, што праграма атрымала яго звычайным шляхам. Два запыты могуць выходзіць з розных рэзалвераў або з аднаго рэзалвера пры розных правілах. Запішыце абодва вынікі, перш чым будаваць тэорыі, бо менавіта на гэтым кроку адно падмяняюць другім. Параўнанне — гэта ўся дыягностыка.

Чытайце адмову, а не сімптом

Параметр stop-dns-rebind у dnsmasq адкідае адпаведныя прыватнаму адрасу адказы, атрыманыя зверху, і запісвае іх у журнал, калі гэта робіць. Гэтая абарона існуе з паважнай прычыны: публічнае імя, якое раптам паказвае на прыватны адрас, — гэта класічная rebinding-атака. Яна таксама перасякаецца з наўмысна прыватнай службай, і гэта ваш выпадак.

Пошукайце адмову ў журнале, перш чым нешта змяняць, бо паведамленне называе механізм.

Калі няма ні адмовы, ні адказу зверху, абарона ад rebinding не з'яўляецца вашай праблемай, і яе адключэнне было б зменай, якая нічога не выпраўляе і пашырае ўразлівасць. Гэта горш за зыходную няспраўнасць, бо прыбірае кантроль і пакідае дэфект. Спачатку пацвердзіце канкрэтны радок журнала. Потым вырашайце.

Абмяжуйце выключэнне адным даменам

Для праверанага дамена кіраўніцтва dnsmasq прапануе выключэнне, абмежаванае даменам, а не глабальны пераключальнік.

rebind-domain-ok=corp.example

Дамен вышэй прыведзены толькі для прыкладу. Выкарыстоўвайце адміністрацыйны дамен, якім вы сапраўды кіруеце, і зразумейце вобласць супадзення параметра, перш чым ужываць яго, бо правіла суфікса ахоплівае больш, чым адзін правераны хост. Генератар канфігурацыі маршрутызатара можа паказаць тую ж наладку праз уласны элемент кіравання замест сырой дырэктывы. Абодва шляхі прыдатныя, калі атрыманая вобласць — тая, што патрэбна.

Выключэнне з выяўлення rebinding робіць роўна адно: прапускае адказы гэтага дамена.

Яно не наладжвае перасыланне split-DNS, не робіць недасяжную крыніцу зверху дасяжнай і не стварае маршрут да вернутага адрасу. Кожнае з гэтых патрабаванняў асобнае, мае ўласны подпіс няспраўнасці, і кожнае даецца ў знакі ў кліенце па-свойму.

Праверце, не прыбіраючы мяжы

Запытайце імя хоста яшчэ раз шляхам перасылання, а потым падключыцеся да службы з яе звычайнымі праверкамі ідэнтычнасці. Выключэнне ў DNS не падстава прымаць нечаканы сертыфікат, і гэтыя дзве няспраўнасці лёгка спутаць, калі абедзве выглядаюць як памылка браўзера. Правярайце імя і службу асобна. Толькі адно з іх калі-небудзь было праблемай DNS.

Трымайце прычыну выключэння побач з канфігурацыяй, з датай і адказнай асобай.

Пераправярайце яго, калі прыватная служба пераязджае або дамен змяняецца. Глабальнае адключэнне абароны змяніла б апрацоўку не звязаных адказаў і ўсё роўна пакінула б няспраўнасць маршруту ці службы, калі rebinding ніколі не быў прычынай.