OpenVPN клиенттерін басқа хосттағы Pi-hole шешушісіне бағыттау

OpenVPN профиліне Pi-hole мекенжайын жазу оған жол жасамайды, оны сұрауға рұқсат бермейді және клиент оны пайдаланатынына кепілдік бермейді. 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 портына да рұқсат беретін кең қайта бағыттау ережесі — болуын күтіп тұрған басқа мәселе.