Pi хотспоты Pi-hole және VPN-мен: әр қызметке өз міндетін беріңіз

Телефон Pi хотспотына қосылып, мекенжай алады, бірақ бет әлі ашылмайды. Pi хотспот көмекшісін, Pi-hole және VPN клиентін іске қосады, ал олардың әрқайсысы жолдың бір бөлігін иемденемін деп ойлайды. Мұндай құрастырулардың көбі компонент бұзылғандықтан емес, екі компонент бір жұмысты жасағандықтан сәтсіз болады. Кез келгенін реттемес бұрын әр функцияға бір ие жеке тағайындаңыз.

Әр функцияға бір ие тағайындаңыз

Мұнда төрт функция маңызды, және әрқайсысына дәл бір ие керек. Төмендегі кестеде функция, жарамды ие және оған екі қызмет талап еткенде не бұзылатыны көрсетілген.

Қабаттасу әдетте бір пакеттен келеді. Хотспот көмекшісі өзінің dnsmasq данасын орнатады, Pi-hole 53 портын қалайды, ал VPN клиенті маршруттар қосады. Әр қадам жеке алғанда орынды көрінеді, ал бірге алғанда екінші іске қосылған қызмет біріншісінің мінез-құлқын байқатпай өзгертетін машина жасайды.

Басқаны қоспас бұрын иелерді жазып қойыңыз. Құрастыру жазбаларындағы қысқа кесте кейінгі орнатудың бұрын иесі болған функцияны басып алуына жол бермейді.

Бір диапазон таңдап, оны туннельден алыс ұстаңыз

Хотспот диапазонын, ондағы Pi мекенжайын, DHCP пулын және клиенттер алатын резолверді таңдаңыз. Бұл диапазонды жоғары LAN-нан және VPN туннелінің диапазонынан бөлек ұстаңыз, себебі қиылысатын ішкі желілер маршруттау мәселесін мекенжайларды аудару жобасына айналдырады. Туннельмен қиылысатын диапазон Pi-ді екі бірдей префикс арасындағы кездейсоқ маршрутизаторға айналдырады. Диапазон мен пулды әдепкі мәнге қалдырмай, хотспот конфигурациясына жазыңыз.

Егер хотспотты NetworkManager-дің ортақ режимі иемденсе, DHCP серверін қоспас бұрын нақты қосылымды тексеріңіз. Ортақ режим өз көмекшілерін іске қосып, қайта жіберуді қосады, сондықтан ол сол интерфейс үшін мекенжай жоспарының иесі болып табылады. Қолжетімді болғандықтан екінші сервер қосу резервтеу емес, бәсекелес ұсыныстар жасайды.

IPv6 туралы әдейі шешім қабылдаңыз. Маршрутизатор хабарламалары мен DHCPv6 көптеген конфигурацияда DHCPv4-тен өзге көмекшіден келеді, ал VPN саясаты тек IPv4-ті қамтып жатқанда IPv6-ны қосулы қалдыру клиенттерге туннельді айналып өтетін жол береді. Не IPv6 жағын жоспарлаңыз, не оны хотспот интерфейсінде жазбаша себеппен өшіріңіз.

53 портында шын мәнінде кім жауап береді

Конфигурацияны өзгертудің алдында 53 портын тыңдайтын әр процесті тізіңіз. Жергілікті резолвер stub, Pi-hole және бөлісу көмекшісі істейтін Pi-де тыңдаушылар тізімі сұраныстарға кім жауап беретінінің жалғыз сенімді картасы болып табылады:

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

Pi-hole-дың интерфейстер нұсқаулығы бір интерфейспен шектелген қабылдау режимі wildcard сокетті пайдаланып, басқа жерге келген қосылымдарды тастай алатынын түсіндіреді. Бұл тек таңдалған интерфейстерді байланыстырумен бірдей емес, ал ол басқа DNS қызметі машинаны бөлісуге тиіс кезде көзделген реттеу болып табылады.

Екі процесс әдетте бір мекенжай мен портты байланыстыра алмайды, дегенмен SO_REUSEPORT ортақ байланыстыруды сәтті ете алады; тіпті сонда да wildcard тыңдаушы тар қызметке арналған қосылымдарды қабылдай алады. Қажет рөл үшін құжатталған режимді таңдап, қызметтерді көзделген тәртіппен қайта іске қосыңыз.

Pi-hole-дың әкімшілік бетін хотспот желісінен тыс ұстаңыз. Клиенттерге резолвер керек, ал резолвер конфигурациясын өзгерте алатын веб-интерфейс немесе API емес.

Екі DNS тармағы, әрқайсысына бір саясат

Клиент сұранысы телефоннан Pi-ге жүреді, ал жеке сұраныс Pi-ден оның жоғары резолверіне жүреді. Хотспоттың қайта жіберілген трафигіне сәйкес келетін маршруттау ережесі екінші тармаққа автоматты түрде қолданылмайды, себебі Pi бұл трафикті жергілікті жасайды. Егер VPN DNS тасымалдауы керек болса, жергілікті жолға өз саясаты қажет.

Циклды бақылаңыз. Pi-hole-дың жоғары резолверін Pi өзі қызмет көрсететін мекенжайға бағыттау, тікелей немесе порт арқылы, уақыты бітпейінше айналатын сұраныстар жасайды. Оған нақты жоғары резолвер немесе жауап бере алмайтын домендер үшін шартты форвардер беріңіз.

Туннель құлағанда не болатынын шешіңіз. Жергілікті резолверге оралу шолуды сақтайды, бірақ атауларды VPN сыртына шығаруы мүмкін; блоктау саясатты бұзбай сақтайды және ақауды көрінетін қатеге айналдырады. Екі таңдау да қорғауға болады, бірақ оны әдепкі мәннен мұра етпей, таңдау керек.

Жолды және ақау кезіндегі мінез-құлықты дәлелдеңіз

Қабаттап тексеріңіз: клиент мекенжай алады, клиент атауды Pi арқылы шешеді, Pi көзделген жоғары резолвер арқылы шешеді, ал қолданба сұранысты аяқтайды. Сәтті ping DNS туралы ештеңе айтпайды, ал сәтті шешу қайта жіберу туралы ештеңе айтпайды.

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

Содан кейін туннельді тоқтатып, қайталаңыз. Көзделген мінез-құлық бірнеше секунд ішінде пайда болуы керек, Pi-hole немесе хотспот қызметін қолмен қайта іске қосқаннан кейін емес. Ақау кезінде клиенттің резолвер параметрін тексеріңіз, себебі қосалқы жария резолвер саясат қатені күткенде де жауап береді.

Қайта жіберу мен NAT үшін бір ие ұстап, оны клиенттен тексеріңіз, Pi-дің өзінен емес. Pi-ден сәтті шыққан сұраныс қайтар жолда әлі де тасталуы мүмкін, ал клиент бүкіл жолдың көрінетін жалғыз орны.