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