Ուղղորդել 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 պորտը, այլ խնդիր է, որը սպասում է տեղի ունենալուն։