Pi hotspotu, Pi-hole və VPN: hər xidmətə bir vəzifə verin

Bir telefon Pi-nin hotspotuna qoşulur, ünvan alır, amma səhifə hələ də açılmır. Pi-də hotspot köməkçisi, Pi-hole və VPN müştərisi işləyir və hər biri yolun bir hissəsinə sahib olduğuna inanır. Bu qurğuların çoxu komponent xarab olduğu üçün deyil, ona görə uğursuz olur ki, iki komponent eyni işi görür. Hər hansı birini tənzimləməzdən əvvəl hər funksiyaya bir sahib təyin edin.

Hər funksiyaya bir sahib təyin edin

Burada dörd funksiya vacibdir və hər birinə tam olaraq bir sahib lazımdır. Aşağıdakı cədvəl funksiyanı, işlək sahibi və iki xidmət ona iddia etdikdə nəyin pozulduğunu göstərir.

Üst-üstə düşmə adətən hər dəfə bir paketlə gəlir. Hotspot köməkçisi öz dnsmasq nüsxəsini quraşdırır, Pi-hole 53 portunu istəyir, VPN müştərisi isə marşrutlar əlavə edir. Hər addım tək başına məqul görünür, birlikdə isə ikinci başlayan xidmətin birincinin davranışını səssizcə dəyişdirdiyi bir maşın yaradır.

Başqa heç nəyi aktivləşdirməzdən əvvəl sahibləri yazın. Quraşdırma qeydlərindəki qısa cədvəl sonrakı quraşdırmanın artıq sahibi olan funksiyanı ələ keçirməsinin qarşısını alır.

Bir diapazon seçin və onu tuneldən uzaq saxlayın

Hotspot diapazonunu, Pi-nin onun üzərindəki ünvanını, DHCP hovuzunu və müştərilərin aldığı həlledicini seçin. Bu diapazonu yuxarı LAN-dan və VPN tunel diapazonundan ayrı saxlayın, çünki üst-üstə düşən subnetlər marşrutlaşdırma problemini ünvan tərcüməsi layihəsinə çevirir. Tunellə üst-üstə düşən diapazon Pi-ni iki eyni prefiks arasında təsadüfi marşrutlaşdırıcıya çevirir. Diapazonu və hovuzu standart dəyərə buraxmaq əvəzinə hotspot konfiqurasiyasına yazın.

Əgər hotspot NetworkManager-in paylaşılan rejiminə aiddirsə, DHCP serveri əlavə etməzdən əvvəl faktiki bağlantını yoxlayın. Paylaşılan rejim öz köməkçilərini işə salır və yönləndirməni aktivləşdirir, yəni o, artıq həmin interfeys üçün ünvan planının sahibidir. Mövcud olduğu üçün ikinci server əlavə etmək ehtiyat yox, rəqabətli təkliflər yaradır.

IPv6 barədə qəsdən qərar verin. Router reklamları və DHCPv6 bir çox quraşdırmada DHCPv4-dən fərqli köməkçidən gəlir və VPN siyasəti yalnız IPv4-ü əhatə edərkən IPv6-nı açıq buraxmaq müştərilərə tuneli yan keçən yol verir. Ya IPv6 tərəfini planlaşdırın, ya da yazılı səbəblə hotspot interfeysində onu söndürün.

53 portunda əslində kim cavab verir

Konfiqurasiyanı dəyişməzdən əvvəl 53 portunu dinləyən hər prosesi sadalayın. Yerli həlledici stub-u, Pi-hole və paylaşma köməkçisini işlədən Pi-də dinləyicilər siyahısı sorğulara kimin cavab verdiyinin yeganə etibarlı xəritəsidir:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Pi-hole-un interfeys bələdçisi izah edir ki, bir interfeyslə məhdudlaşan qəbul rejimi yenə də wildcard soketindən istifadə edib gəlişləri başqa yerdə ata bilər. Bu, yalnız seçilmiş interfeysləri bağlamaqla eyni şey deyil; başqa DNS xidməti maşını paylaşmalı olanda nəzərdə tutulan düzüm elə budur.

İki proses adətən eyni ünvanı və portu bağlaya bilməz, baxmayaraq ki, SO_REUSEPORT paylaşılan bağlantını uğurlu edə bilər; o halda belə wildcard dinləyici daha dar xidmət üçün nəzərdə tutulan gəlişləri götürə bilər. İstədiyiniz rol üçün sənədləşdirilmiş rejimi seçin və xidmətləri nəzərdə tutulan ardıcıllıqla yenidən başladın.

Pi-hole-un idarəetmə səhifəsini hotspot şəbəkəsindən uzaq saxlayın. Müştərilərə həlledici lazımdır, həlledicinin konfiqurasiyasını dəyişə bilən veb interfeys və ya API yox.

İki DNS ayağı, hər birinə bir siyasət

Müştəri sorğusu telefondan Pi-yə gedir, ayrı bir sorğu isə Pi-dən yuxarı həlledicisinə gedir. Yönləndirilmiş hotspot trafikinə uyğun gələn marşrut qaydası ikinci ayağa avtomatik tətbiq olunmur, çünki Pi həmin trafiki yerli olaraq yaradır. Əgər VPN DNS-i daşımalıdırsa, yerli yolun öz siyasəti olmalıdır.

Döngəyə diqqət edin. Pi-hole-un yuxarı həlledicisini Pi-nin özünün təqdim etdiyi ünvana yönəltmək, birbaşa və ya port yönləndirməsi ilə, vaxt aşımına qədər dövr edən sorğular yaradır. Ona real yuxarı həlledici və ya cavab verə bilmədiyi domenlər üçün şərti yönləndirici verin.

Tunel düşəndə nə olacağına qərar verin. Yerli həllediciyə qayıtmaq gəzintini davam etdirir, amma adları VPN-dən kənara sızdıra bilər; bloklama siyasəti toxunulmaz saxlayır və kəsintini görünən xətaya çevirir. Hər iki seçim müdafiə oluna bilər, amma onu standart dəyərdən miras almaq əvəzinə seçmək lazımdır.

Yolu və kəsinti davranışını sübut edin

Qat-qat test edin: müştəri ünvan alır, müştəri adı Pi vasitəsilə həll edir, Pi nəzərdə tutulan yuxarı həlledici vasitəsilə həll edir və tətbiq sorğunu tamamlayır. Uğurlu ping DNS barədə heç nə demir, uğurlu axtarış isə yönləndirmə barədə heç nə demir.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

Sonra tuneli dayandırın və təkrarlayın. Nəzərdə tutulan davranış bir neçə saniyə içində görünməlidir, Pi-hole və ya hotspot xidmətinin əl ilə yenidən başladılmasından sonra yox. Kəsinti zamanı müştərinin həlledici ayarını yoxlayın, çünki ikinci dərəcəli ictimai həlledici siyasət uğursuzluq gözləyəndə belə cavab verməyə davam edəcək.

Yönləndirmə və NAT üçün bir sahib saxlayın və bunu Pi-nin özündən deyil, müştəridən yoxlayın. Pi-dən uğurla çıxan sorğu geri yolda yenə də atıla bilər, və bütün yolun göründüyü yeganə yer müştəridir.