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 портуна да уруксат берген кенен багыттоо эрежеси — болушун күтүп турган башка маселе.