Прыватны DNS у Pritunl не працуе? Дадайце вузкі маршрут рэзалвера
Прыватны рэзалвер, які ігнаруе пул VPN, патрабуе выключэння для крыніцы, а не шырэйшага маршруту. Дадайце /32 з уключаным NAT і праверце сапраўдны прыватны запыт.
Прыватныя імёны вырашаюцца для ўсіх у карпаратыўнай сетцы і сканчаюцца па тайм-ауце для ўсіх у VPN. Рэзалвер адказвае шлюзу, маршрут да яго існуе, а запыт так і не атрымлівае адказу. Не хапае не іншага публічнага рэзалвера і не шырэйшага маршруту: не хапае адраса крыніцы, на які прыватны DNS-сервер гатовы адказаць.
Пераканайцеся, што рэзалвер адмаўляе вашаму пулу кліентаў
Пачніце з доказу, што збой звязаны з крыніцай, а не з дасяжнасцю. З падключанага кліента запытайце прыватны рэзалвер напросткі і паназірайце, ці запыт сканчаецца па тайм-ауце, ці вяртаецца як адмова. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 з тайм-аутам, тады як той жа запыт са шлюза паспяховы, паказвае на палітыку доступу на рэзалверы. Адказ SERVFAIL паказвае зусім у іншае месца, звычайна на зону або вышэйшы форвардар.
Запішыце адрас кліента перад праверкай. ip -4 addr show tun0 на кліенце або арэнда, паказаная ў кансолі, скажуць, які пул бачыць рэзалвер.
Затым пераканайцеся, што шлях увогуле існуе. Маршрут, які накіроўвае адрас рэзалвера ў тунель, — гэта перадумова, а не рашэнне; калі пакеты ніколі не прыходзяць, палітыка крыніцы нават не разглядаецца. Праверце гэта з дапамогай ip route get 10.40.0.53 на кліенце.
Дадайце адзін маршрут да хоста замест трансляцыі ўсяго
Кіраўніцтва Pritunl па прыватным DNS апісвае вузкае рашэнне: маршрут /32 з уключаным NAT для адраса рэзалвера, прычым гэты адрас выбраны як DNS-сервер кліентаў. Маршрут змяняе крыніцу, якую бачыць рэзалвер, толькі для DNS-трафіку. Трафік праграм захоўвае дызайн з захаваннем крыніцы, які вы для яго выбралі.
Наладзьце яго праз падтрымліванага ўладальніка маршруту на серверы, папярэдне праверыўшы існуючыя маршруты на перасячэнне. У прыкладзе вышэй прызначэнне — 10.40.0.53/32 з уключаным NAT, а пул кліентаў застаецца 10.90.0.0/24. Не транслюйце ўвесь прыватны дыяпазон, каб выправіць адну паслугу, бо кожная ніжэйшая палітыка, якая абапіраецца на рэальны адрас кліента, пачне бачыць замест яго шлюз. Пацвердзіце адрас, які рэзалвер фактычна атрымлівае, назіраючы за яго журналам запытаў падчас тэставага пошуку. Адзін маршрут да хоста нічога не даказвае пра трансляцыю ці дазвол.
Рэзалвер па-ранейшаму павінен дазваляць трансляваную крыніцу па UDP і TCP, і яго адказы павінны мець магчымасць вярнуцца. Змяненне крыніцы не можа стварыць адсутную зону ці запіс.
Вырашыце, хто адпраўляе запыт — сервер ці кліент
Pritunl таксама апісвае схему DNS-проксі, звязаную з VPN Client DNS Mapping, дзе сервер перасылае вышэйшыя запыты за кліентаў. У гэтай мадэлі крыніца вышэйшага ўзроўню належыць уласнаму сеткаваму кантэксту сервера, і выключэнне на баку кліента — няправільнае рашэнне.
Вызначце, якая мадэль актыўная, перш чым нешта дадаваць. Тры перасякаючыяся выпраўленні, проксі, перакрыццё рэзалвера на кліенце і ручны скрыпт NAT звычайна азначаюць, што ніхто не ўстанавіў: які кампанент павінен адпраўляць запыт. Праверце таксама bootstrap: прыватны рэзалвер не можа быць адзіным спосабам знайсці канцавы пункт да стварэння тунеля, а пастаяннае змяненне рэзалвера не павінна перажываць злучэнне.
Праверце прыватны пошук, а не публічную вэб-старонку
Пасля прымянення змены і паўторнага падключэння агледзіце эфектыўную канфігурацыю рэзалвера кліента, затым вызначце імя, пра якое вы ведаеце, што яно існуе толькі ў прыватнай зоне. dig intranet.example.net без яўнага сервера паказвае, што кліент фактычна выкарыстоўвае. Затым адпраўце запыт на адрас, які вярнуў гэты пошук, бо вызначэнне і доступ да паслугі — асобныя крокі. Браўзер, які загружае публічныя сайты праз DNS-over-HTTPS, нічога не даказвае пра шлях прыватнага рэзалвера ў аперацыйнай сістэме. Публічны другасны рэзалвер таксама не з’яўляецца аўтарытэтам для ўнутранай зоны.
Запішыце адрас рэзалвера, маршрут /32 і наладу DNS кліента разам у нататках сервера. Палова гэтай канфігурацыі, адноўленая асобна, узнаўляе зыходны збой.
Нарэшце, пераканайцеся, што тунель па-ранейшаму маршрутызуе прызначэнне праграмы пасля паспяховага DNS. Маршрут, доступ да паслугі і аўтэнтыфікацыя застаюцца незалежнымі ад вызначэння імёнаў, і працоўны пошук нічога не кажа пра прапускную здольнасць. Калі прыватная старонка павольная, але вырашаецца, рэзалвер зрабіў сваю справу, і праблема перайшла на шлях.