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