Pi hotspoti Pi-hole va VPN bilan: har bir xizmatga o'z vazifasini bering

Telefon Pi hotspotiga ulanadi, manzil oladi, sahifa esa baribir ochilmaydi. Pi hotspot yordamchisi, Pi-hole va VPN mijozi ishlaydi va ularning har biri yo'lning bir qismiga ega deb o'ylaydi. Bunday yig'ilishlarning ko'pchiligi komponent buzilgani uchun emas, ikki komponent bir xil ishni qilgani uchun muvaffaqiyatsiz bo'ladi. Har qaysisini sozlashdan oldin har bir funksiyaga bitta ega tayinlang.

Har bir funksiyaga bitta ega tayinlang

Bu yerda to'rt funksiya muhim va har biriga aynan bitta ega kerak. Quyidagi jadval funksiyani, ishlaydigan egasini va unga ikki xizmat da'vo qilganda nima buzilishini ko'rsatadi.

Qoplanish odatda bir paketdan keladi. Hotspot yordamchisi o'z dnsmasq nusxasini o'rnatadi, Pi-hole 53-portni xohlaydi, VPN mijozi esa marshrutlar qo'shadi. Har bir qadam alohida o'rinli ko'rinadi, birgalikda esa ikkinchi ishga tushgan xizmat birinchisining xatti-harakatini sezdirmay o'zgartiradigan mashina hosil qiladi.

Boshqa narsani yoqishdan oldin egalarni yozib qo'ying. Yig'ish qaydlaridagi qisqa jadval keyingi o'rnatishning allaqachon egasi bo'lgan funksiyani egallashiga yo'l qo'ymaydi.

Bitta diapazon tanlang va uni tunneldan uzoq tuting

Hotspot diapazonini, undagi Pi manzilini, DHCP hovuzini va mijozlar oladigan resolverni tanlang. Bu diapazonni yuqori LANdan va VPN tunnel diapazonidan alohida tuting, chunki kesishuvchi quyi tarmoqlar marshrutlash muammosini manzillarni tarjima qilish loyihasiga aylantiradi. Tunnel bilan kesishuvchi diapazon Pi ni ikkita bir xil prefiks orasidagi tasodifiy routerga aylantiradi. Diapazon va hovuzni standart qiymatga qoldirmay, hotspot konfiguratsiyasiga yozing.

Agar hotspotga NetworkManager'ning umumiy rejimi ega bo'lsa, DHCP serverini qo'shishdan oldin amaldagi ulanishni ko'rib chiqing. Umumiy rejim o'z yordamchilarini ishga tushiradi va uzatishni yoqadi, shuning uchun u o'sha interfeys uchun manzil rejasining egasi. Mavjud bo'lgani uchun ikkinchi server qo'shish zaxira emas, raqobatlashuvchi takliflar yaratadi.

IPv6 haqida ataylab qaror qiling. Router e'lonlari va DHCPv6 ko'p sozlamalarda DHCPv4 dan boshqa yordamchidan keladi, VPN siyosati faqat IPv4 ni qamrab olganda IPv6 ni yoqib qo'yish esa mijozlarga tunnelni chetlab o'tuvchi yo'l beradi. Yo IPv6 tomonini rejalashtiring, yo uni hotspot interfeysida yozma sabab bilan o'chiring.

53-portda aslida kim javob beradi

Konfiguratsiyani o'zgartirishdan oldin 53-portni tinglayotgan har bir jarayonni sanab chiqing. Lokal resolver stub, Pi-hole va bo'lishish yordamchisi ishlaydigan Pi da tinglovchilar ro'yxati so'rovlarga kim javob berishining yagona ishonchli xaritasi:

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

Pi-hole'ning interfeyslar qo'llanmasi bitta interfeys bilan cheklangan qabul rejimi ham wildcard soketdan foydalanib, boshqa joyga kelganlarni tashlab yuborishi mumkinligini tushuntiradi. Bu faqat tanlangan interfeyslarni bog'lash bilan bir xil emas; boshqa DNS xizmati mashinani bo'lishishi kerak bo'lganda aynan shu tuzilma ko'zda tutilgan.

Ikki jarayon odatda bir xil manzil va portni bog'lay olmaydi, garchi SO_REUSEPORT umumiy bog'lashning muvaffaqiyatli bo'lishiga imkon bersa ham; shunda ham wildcard tinglovchi torroq xizmatga mo'ljallangan kelishlarni olishi mumkin. Kerakli rol uchun hujjatlashtirilgan rejimni tanlang va xizmatlarni mo'ljallangan tartibda qayta ishga tushiring.

Pi-hole'ning boshqaruv sahifasini hotspot tarmog'idan tashqarida tuting. Mijozlarga resolver kerak, resolver konfiguratsiyasini o'zgartira oladigan veb-interfeys yoki API emas.

Ikki DNS tarmog'i, har biriga bitta siyosat

Mijoz so'rovi telefondan Pi ga boradi, alohida so'rov esa Pi dan uning yuqori resolveriga boradi. Hotspotning uzatilgan trafigiga mos keladigan marshrutlash qoidasi ikkinchi tarmoqqa avtomatik qo'llanilmaydi, chunki Pi bu trafikni lokal hosil qiladi. Agar VPN DNS tashishi kerak bo'lsa, lokal yo'lga o'z siyosati kerak.

Halqani kuzating. Pi-hole'ning yuqori resolverini Pi o'zi xizmat qiladigan manzilga yo'naltirish, to'g'ridan-to'g'ri yoki port-forward orqali, vaqt tugaguncha aylanadigan so'rovlar hosil qiladi. Unga haqiqiy yuqori resolver yoki javob bera olmaydigan domenlar uchun shartli forwarder bering.

Tunnel uzilganda nima bo'lishini hal qiling. Lokal resolverga qaytish ko'rishni saqlaydi, lekin nomlarni VPN tashqarisiga oqizishi mumkin; bloklash siyosatni buzmasdan saqlaydi va uzilishni ko'rinadigan xatoga aylantiradi. Ikkala tanlov ham oqlanadi, lekin ularni standart qiymatdan meros qilib olmasdan tanlash kerak.

Yo'lni va uzilish paytidagi xatti-harakatni isbotlang

Qatlamlab sinang: mijoz manzil oladi, mijoz nomni Pi orqali hal qiladi, Pi mo'ljallangan yuqori resolver orqali hal qiladi va dastur so'rovni yakunlaydi. Muvaffaqiyatli ping DNS haqida hech narsa demaydi, muvaffaqiyatli qidiruv esa uzatish haqida hech narsa demaydi.

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

So'ng tunnelni to'xtatib, takrorlang. Mo'ljallangan xatti-harakat bir necha soniya ichida paydo bo'lishi kerak, Pi-hole yoki hotspot xizmatini qo'lda qayta ishga tushirgandan keyin emas. Uzilish paytida mijozning resolver sozlamasini tekshiring, chunki ikkilamchi ochiq resolver siyosat xatoni kutgan bo'lsa ham javob berishda davom etadi.

Uzatish va NAT uchun bitta ega tuting va uni Pi ning o'zidan emas, mijozdan tekshiring. Pi dan muvaffaqiyatli chiqqan so'rov qaytish yo'lida baribir tashlab yuborilishi mumkin, va mijoz butun yo'l ko'rinadigan yagona joy.