Накіраваць кліенты OpenVPN на рэзалвер Pi-hole на іншым хосце

Упісаць адрас Pi-hole у профіль OpenVPN не значыць стварыць шлях да яго, даць права яго апытваць або гарантаваць, што кліент ім скарыстаецца. Калі Pi-hole стаіць на асобнай машыне ў LAN, павінны супасці чатыры рэчы: маршрут ад кліента, пераадрасацыя ад шлюза, зваротны шлях да пула і палітыка прыёму на самім Pi-hole. Кожны збой выглядае ў журнале па-свойму. Прайсці іх у гэтым парадку хутчэй, чым спачатку рамантаваць апошні. Звычайнае спрашчэнне, адкрыць рэкурсію для любой крыніцы, мяняе малую праблему на пастаянную.

Што робіць і чаго не робіць праштурхнутая опцыя DNS

Сервер абвяшчае рэзалвер дырэктывай ніжэй, мяркуючы, што 192.168.50.53 — хост Pi-hole. Кліент атрымлівае опцыю і, у залежнасці ад платформы і інтэграцыі рэзалвера , прымяняе яе да інтэрфейса тунеля або ігнаруе на карысць лакальнага stub. Радок маршруту важны не менш за радок DNS, бо рэзалвер, да якога кліент не дацягваецца, — зусім не рэзалвер. Нічога з гэтага не відаць з боку сервера.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Атрымаць опцыю — не тое самае, што выкарыстоўваць яе. Linux-кліент з менеджарам рэзалвера можа прыняць праштурхнуты сервер і дасылаць да яго толькі пэўныя дамены; кліент, які сам кіруе DNS, можа цалкам перазапісаць наладу. Праштурхнутыя маршруты на некаторых платформах таксама абмежаваныя, і рэзалвер застаецца недасяжным, хоць опцыю было прынята. Правярайце на кліенце, які сервер адказвае, а не на серверы, што было даслана.

Опцыя таксама нічога не кажа пра бок сервера. DNS-трафік усё адно мусіць прайсці ад кліента да шлюза і ад шлюза да Pi-hole, перш чым любая опцыя пачне нешта значыць. Адсутны маршрут і адхілены запыт выглядаюць з боку кліента аднолькава, таму спачатку пацвердзіце пераадрасацыю на шлюзе.

Зваротны шлях ад Pi-hole да пула

Калі адрас крыніцы кліента захоўваецца, Pi-hole адказвае на адрас усярэдзіне пула VPN. Яго ўласная табліца маршрутызацыі, верагодна, нічога не ведае пра гэты пул, таму адказ ідзе на яго шлюз па змаўчанні і знікае. Журнал запытаў паказвае запыт без адпаведнага адказу, што лёгка ўспрыняць як праблему брандмаўэра.

Дайце LAN-роўтару статычны маршрут да пула са шлюзам OpenVPN як наступным пераходам або транслюйце крыніцу на шлюзе перад пераадрасацыяй да Pi-hole. Першае пакідае адрасы кожнага кліента бачнымі ў журнале запытаў Pi-hole. Другое прыбірае патрабаванне зваротнага маршруту, але робіць кожны запыт такім, нібы ён прыйшоў ад шлюза. Ні адно не з'яўляецца няправільным; яны адказваюць на розныя пытанні.

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

Рэжым праслухоўвання Pi-hole для маршрутызаваных кліентаў

Спадны спіс паводзін праслухоўвання інтэрфейсаў на старонцы налад у раздзеле DNS вырашае, якім крыніцам адказвае Pi-hole. Найстражэйшы варыянт прымае толькі кліентаў у непасрэдна падключаных сетках; варыянт, які дазваляе прылады не далей за адзін пераход, пашырае гэта на падсеткі за суседнім маршрутызатарам, і менавіта так выглядае маршрутызаваны кліент VPN. Пакет сапраўды прыходзіць на інтэрфейс LAN, але яго адрас крыніцы належыць іншай падсетцы. Гэта адмова па палітыцы, а не збой маршрутызацыі, і розніца важная, калі чытаеш журналы.

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

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

Супастаўце адказ з журналам запытаў

Спытайце кліент, потым праверце сервер і параўнайце абодва. На кліенце з systemd-resolved каманды ніжэй паказваюць, які рэзалвер даў адказ і якія серверы наладжаныя для кожнага злучэння. Выкарыстоўвайце імя, якое ведае толькі Pi-hole, бо прамы запыт на адрас Pi-hole даказвае дасяжнасць, а не канфігурацыю.

resolvectl query intranet.example.lan
resolvectl dns

Чаканы адказ называе 192.168.50.53 серверам і вяртае адрас, які ведаў бы толькі гэты рэзалвер. Потым паглядзіце на ўласнае прадстаўленне Pi-hole: pihole -t сочыць за журналам запытаў у рэальным часе, і кожны радок нясе адрас крыніцы. Калі крыніца — тунельны адрас кліента, маршрут пула цэлы. Калі гэта адрас LAN шлюза, працуе трансляцыя крыніцы, і ўласны адрас кліента ніколі не з'явіцца.

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

Праверце правіла пераадрасацыі шлюза

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

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

Які б інструмент ні выкарыстоўваў хост, трымайце праверку вузкай: пул як крыніца, порт 53 як прызначэнне і Pi-hole як адзіная дазволеная мэта. Шырокае правіла пераадрасацыі, якое дазваляе яшчэ і порт 80, — іншая праблема, якая толькі чакае свайго часу.