OpenVPN müştərilərini başqa hostdakı Pi-hole resolverinə yönəltmək

OpenVPN profilində Pi-hole ünvanı yazmaq ona yol yaratmır, onu sorğulamaq icazəsi vermir və müştərinin ondan istifadə edəcəyinə zəmanət vermir. Pi-hole ayrı LAN maşınında olduqda dörd şey uyğun gəlməlidir: müştəridən marşrut, şlüzdən yönləndirmə, hovuza geri yol və Pi-hole-un özündə qəbul siyasəti. Hər nasazlıq jurnalda fərqli görünür. Onları bu sıra ilə keçmək sonuncunu birinci düzəltməkdən sürətlidir. Adi qısa yol, hər mənbəyə rekursiyanı açmaq, kiçik problemi daimi bir problemlə dəyişir.

İtilən DNS seçiminin nə etdiyi və nə etmədiyi

Server 192.168.50.53-ün Pi-hole hostu olduğunu fərz edərək aşağıdakı direktivlə bir resolver elan edir. Müştəri seçimi alır və, platformasından və resolver inteqrasiyasından asılı olaraq , onu tunel interfeysinə tətbiq edir və ya yerli stub xeyrinə nəzərə almır. Marşrut sətri DNS sətri qədər vacibdir, çünki müştərinin çata bilmədiyi resolver heç bir resolver deyil. Bunların heç biri server tərəfindən görünmür.

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"

Seçimi almaq ondan istifadə etməklə eyni şey deyil. Resolver meneceri olan Linux müştərisi itilən serveri qəbul edib ona yalnız müəyyən domenlər göndərə bilər; DNS-i özü idarə edən müştəri ayarı tamamilə üzərinə yaza bilər. İtilən marşrutlar bəzi platformalarda da məhduddur və seçim qəbul olunsa da resolver əlçatmaz qalır. Hansı serverin cavab verdiyini müştəridə yoxlayın, serverdə nə göndərildiyini deyil.

Seçim server tərəfi haqqında da heç nə demir. DNS trafiki hər hansı seçim əhəmiyyət qazanmazdan əvvəl hələ də müştəridən şlüzə və şlüzdən Pi-hole-a getməlidir. Çatışmayan marşrut və rədd edilən sorğu müştəri tərəfindən eyni görünür, ona görə əvvəlcə şlüzdə yönləndirməni təsdiqləyin.

Pi-hole-dan hovuza geri yol

Müştərinin mənbə ünvanı saxlanılarsa, Pi-hole VPN hovuzunun içindəki bir ünvana cavab verir. Onun öz marşrutlaşdırma cədvəli bu hovuz haqqında yəqin ki heç nə bilmir, ona görə cavab standart şlüzünə gedir və yox olur. Sorğu jurnalı uyğun cavabı olmayan sorğu göstərir, bunu da firewall problemi ilə səhv salmaq asandır.

LAN marşrutlaşdırıcısına OpenVPN şlüzü növbəti hop olmaqla hovuz üçün statik marşrut verin və ya Pi-hole-a yönləndirməzdən əvvəl mənbəyi şlüzdə tərcümə edin. Birincisi hər müştərinin ünvanlarını Pi-hole-un sorğu jurnalında görünən saxlayır. İkincisi geri marşrut tələbini aradan qaldırır, amma hər sorğunu şlüzdən gəlmiş kimi göstərir. Heç biri səhv deyil; onlar fərqli suallara cavab verir.

Müştəri üzrə hesabat və ya siyasət vacibdirsə, statik marşrut daha yaxşı mübadilədir. LAN-ı başqası idarə edirsə və marşrut yoxdursa, tərcümə praqmatik seçimdir, müştəri kimliyinin itkisi qeyd edilməlidir. Hansını seçdiyinizi qeyd edin, çünki sonrakı hər jurnal sualı bundan asılıdır.

Yönləndirilmiş müştərilər üçün Pi-hole-un dinləmə rejimi

DNS altındakı ayarlar səhifəsində interfeyslərin dinləmə davranışı açılan siyahısı Pi-hole-un hansı mənbələrə cavab verəcəyini müəyyən edir. Ən sərt seçim yalnız birbaşa qoşulmuş şəbəkələrdəki müştəriləri qəbul edir; cihazlara ən çoxu bir hop məsafəyə icazə verən seçim bunu qonşu marşrutlaşdırıcının arxasındakı altşəbəkələrə genişlədir və yönləndirilmiş VPN müştərisi məhz belə görünür. Paket həqiqətən LAN interfeysinə çatır, amma mənbə ünvanı başqa altşəbəkəyə aiddir. Bu, marşrutlaşdırma nasazlığı deyil, siyasət imtinasıdır və jurnalları oxuyarkən fərq vacibdir.

Pi-hole-un dinləmə təlimatı yerli qoşulmuş mənbələri yönləndirilmiş mənşələrdən ayırır və gəliş interfeysi meyar deyil. Bütün internetə icazə vermədən VPN hovuzuna icazə verən rejim seçin, sonra onu yalnız hovuzdan DNS qəbul edən firewall qaydası ilə birləşdirin.

İlk sorğunun işləməsi üçün rekursiyanı bütün mənşələrə açmaq səhv təmirdir. Şəxsi resolveri açıq birinə çevirir və düzəliş qlobal deyil, məhdud icazədir.

Cavabı sorğu jurnalı ilə uyğunlaşdırın

Müştəridən soruşun, sonra serveri yoxlayın və ikisini müqayisə edin. systemd-resolved müştərisində aşağıdakı əmrlər hansı resolverin cavab yaratdığını və hər bağlantı üzrə hansı serverlərin konfiqurasiya edildiyini bildirir. Yalnız Pi-hole-un bildiyi bir ad istifadə edin, çünki Pi-hole ünvanına birbaşa sorğu konfiqurasiyanı deyil, əlçatanlığı sübut edir.

resolvectl query intranet.example.lan
resolvectl dns

Gözlənilən cavab 192.168.50.53-ü server kimi adlandırır və yalnız həmin resolverin biləcəyi bir ünvan qaytarır. Sonra Pi-hole-un öz görünüşünə baxın: pihole -t sorğu jurnalını canlı izləyir və hər sətir mənbə ünvanını daşıyır. Mənbə müştərinin tunel ünvanıdırsa, hovuz marşrutu toxunulmazdır. Şlüzün LAN ünvanıdırsa, mənbə tərcüməsi işdədir və müştərinin öz ünvanı heç vaxt görünməyəcək.

Jurnalda heç nə görünmürsə, sorğu Pi-hole-a heç vaxt çatmayıb və yoxlanılacaq növbəti şey şlüzdəki yönləndirmədir. Sorğu görünür, amma cavab qayıtmırsa, problem geri yoldur, yəni əvvəlki bölmə. Nasazlığı bu şəkildə ayırmaq marşrutlaşdırma xətasının firewall qaydası ilə səhv salınmasının qarşısını alır.

Şlüzün yönləndirmə qaydasını yoxlayın

Şlüz müştərinin DNS paketlərini Pi-hole-a doğru yönləndirməlidir və bunu edən qaydanı fərz etmək əvəzinə oxumağa dəyər. Aşağıdakı əmrlər 53 portuna toxunan qaydaları sayğaclarla sadalayır, bir nftables hostunda və bir iptables hostunda. Mövcud olan, amma sıfır uyğunluq göstərən qayda trafikin tərcümə edilməzdən əvvəl atıldığının siqnalıdır.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Sayğacları oxuyun, təkcə qaydaları deyil. Heç vaxt uyğun gəlməyən qayda paketin başqa interfeysdən çıxdığını və ya müştərinin onu heç göndərmədiyini bildirir. Hər sorğuda uyğun gələn qayda yönləndirmənin işlədiyini və problemin yolun irəlilərində olduğunu bildirir.

Host hansı aləti istifadə edirsə etsin, yoxlamanı dar saxlayın: mənbə kimi hovuz, təyinat kimi 53 portu və yeganə icazəli hədəf kimi Pi-hole. 80 portuna da icazə verən geniş yönləndirmə qaydası baş verəcəyini gözləyən başqa bir problemdir.