Пункт доступу Pi з Pi-hole і VPN: кожнай службе — свая задача

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

Прызначце аднаго ўладальніка на кожную функцыю

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

Накладванне звычайна прыходзіць па адным пакеце. Памочнік пункта доступу ставіць уласны асобнік dnsmasq, Pi-hole хоча порт 53, а кліент VPN дадае маршруты. Кожны крок асобна выглядае разумна, а разам яны ствараюць машыну, дзе другая служба, якая запускаецца, ціха мяняе паводзіны першай.

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

Выберыце адзін дыяпазон і трымайце яго далей ад тунеля

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

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

Вырашыце пра IPv6 свядома. Аб'явы маршрутызатара і DHCPv6 у многіх канфігурацыях прыходзяць ад іншага памочніка, чым DHCPv4, і калі пакінуць IPv6 уключаным, а палітыка VPN ахоплівае толькі IPv4, кліенты атрымаюць шлях па-за тунелем. Альбо сплануйце бок IPv6, альбо адключыце яго на інтэрфейсе пункта доступу з запісанай прычынай.

Хто насамрэч адказвае на порце 53

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

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

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

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

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

Дзве галіны DNS, па адной палітыцы на кожную

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

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

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

Дакажыце шлях і паводзіны пры збоі

Тэстуйце па ўзроўнях: кліент атрымлівае адрас, кліент развязвае імя праз Pi, Pi развязвае праз патрэбны вышэйшы рэзалвер, а праграма завяршае запыт. Паспяховы ping нічога не кажа пра DNS, а паспяховы пошук нічога не кажа пра перасылку.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

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

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