Ваш VPN-дамен у dnsmasq — гэта не перадача зоны

Вы шукаеце карпаратыўную зону ў канфігурацыі dnsmasq кліента, не знаходзіце яе і робіце выснову, што VPN не адправіў свой дамен. Тое, што было адпраўлена, — гэта падказка маршрутызацыі, а не зона. Кліент запісвае дамен і рэзалвер, які павінен на яго адказваць, а кіраваны бэкенд ператварае гэта ва ўмоўнае перасыланне. Пошук не ў тым месцы дае ўпэўнены і цалкам ілжывы дыягназ.

Тое, што прыняў кліент, — не тое, што прапанаваў шлюз

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

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

Два віды запісаў дамена

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

Для прыватнай прасторы імёнаў форма толькі для маршрутызацыі звычайна тая, якую вы хочаце. Яна трымае карпаратыўны суфікс накіраваным на карпаратыўны рэзалвер і пакідае ўсё іншае ў спакоі.

localhost у resolv.conf — не памылка

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

Замена гэтага запісу публічным рэзалверам — класічнае памылковае выпраўленне. Яно вяртае публічнае развязанне імёнаў і ў тым жа рэдагаванні адкідвае ўмоўную палітыку.

Не блытайце бэкенды

Кіраваны экземпляр dnsmasq і сістэмны рэзалвер — гэта розныя праграмы з рознай канфігурацыяй і рознымі прадстаўленнямі стану. Каманда стану для аднаго не дае нічога карыснага пра другі.

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

Правярайце прастору імёнаў, а не толькі адказ

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

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