Насочување на 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 е друг проблем што само чека да се случи.