Hotspot Pi me Pi-hole dhe VPN: jepini secilës shërbim një punë

Një telefon bashkohet me hotspotin e Pi, merr një adresë dhe faqja prapë nuk hapet. Pi ekzekuton një ndihmës hotspot, Pi-hole dhe një klient VPN, dhe secili mendon se zotëron një pjesë të rrugës. Shumica e këtyre ndërtimeve dështojnë jo sepse një komponent është prishur, por sepse dy komponentë bëjnë të njëjtën punë. Caktoni një pronar për çdo funksion përpara se të rregulloni ndonjë prej tyre.

Caktoni një pronar për çdo funksion

Këtu rëndësi kanë katër funksione, dhe secili kërkon saktësisht një pronar. Tabela më poshtë tregon funksionin, një pronar të zbatueshëm dhe çfarë shkon keq kur dy shërbime e kërkojnë atë.

Mbivendosja zakonisht vjen një paketë në herë. Ndihmësi i hotspotit instalon instancën e vet të dnsmasq, Pi-hole kërkon portin 53 dhe klienti VPN shton rrugë. Çdo hap duket i arsyeshëm veçmas, dhe së bashku prodhojnë një makinë ku shërbimi i dytë që niset ndryshon në heshtje sjelljen e të parit.

Shkruani pronarët përpara se të aktivizoni çdo gjë tjetër. Një tabelë e shkurtër në shënimet e ndërtimit pengon një instalim të mëvonshëm të marrë një funksion që kishte tashmë pronar.

Zgjidhni një interval dhe mbajeni larg tunelit

Zgjidhni intervalin e hotspotit, adresën e Pi në të, grupin DHCP dhe resolverin që marrin klientët. Mbajeni atë interval të ndarë nga LAN-i i sipërm dhe nga intervali i tunelit VPN, sepse nënrrjetet që mbivendosen e kthejnë një problem rrugëtimi në një projekt përkthimi adresash. Një interval që mbivendoset me tunelin e bën Pi një ruter aksidental midis dy prefiksave identikë. Shkruani intervalin dhe grupin në konfigurimin e hotspotit në vend që t'i lini në një vlerë të paracaktuar.

Nëse hotspotin e zotëron modaliteti i ndarë i NetworkManager, inspektoni lidhjen efektive përpara se të shtoni një server DHCP. Modaliteti i ndarë nis ndihmësit e vet dhe aktivizon përcjelljen, kështu që është tashmë pronari i planit të adresave për atë ndërfaqe. Shtimi i një serveri të dytë sepse është i disponueshëm krijon oferta konkurruese, jo tepricë.

Vendosni për IPv6 me qëllim. Njoftimet e ruterit dhe DHCPv6 në shumë konfigurime vijnë nga një ndihmës tjetër sesa DHCPv4, dhe lënia e IPv6 ndezur ndërsa politika e VPN mbulon vetëm IPv4 u jep klientëve një rrugë që shmang tunelin. Ose planifikoni anën IPv6, ose çaktivizojeni atë në ndërfaqen e hotspotit me një arsye të shkruar.

Kush përgjigjet në të vërtetë në portin 53

Listoni çdo proces që dëgjon në portin 53 përpara se të ndryshoni një konfigurim. Në një Pi që ekzekuton një stub lokal resolver, Pi-hole dhe një ndihmës ndarjeje, lista e dëgjuesve është harta e vetme e besueshme e kush përgjigjet ndaj kërkesave:

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

Udhëzuesi i ndërfaqeve i Pi-hole shpjegon se një modalitet pritjeje i kufizuar në një ndërfaqe mund të përdorë ende një socket wildcard dhe të hedhë poshtë mbërritjet diku tjetër. Kjo nuk është e njëjtë me lidhjen vetëm me ndërfaqet e zgjedhura, që është rregullimi i synuar kur një shërbim tjetër DNS duhet të ndajë makinën.

Dy procese zakonisht nuk mund të lidhin të njëjtën adresë dhe port, edhe pse SO_REUSEPORT mund ta bëjë të suksesshme një lidhje të përbashkët; edhe atëherë, një dëgjues wildcard mund të marrë mbërritjet e destinuara për shërbimin më të ngushtë. Zgjidhni modalitetin e dokumentuar për rolin që dëshironi dhe rinisni shërbimet në rendin e synuar.

Mbajeni faqen e administrimit të Pi-hole jashtë rrjetit të hotspotit. Klientët kanë nevojë për një resolver, jo për ndërfaqen web ose API-n që mund të ndryshojë konfigurimin e resolverit.

Dy këmbë DNS, një politikë secila

Një kërkesë klienti udhëton nga telefoni në Pi, dhe një kërkesë e veçantë udhëton nga Pi në resolverin e tij të sipërm. Një rregull rrugëtimi që përputhet me trafikun e përcjellë të hotspotit nuk zbatohet automatikisht për këmbën e dytë, sepse Pi e gjeneron atë trafik lokalisht. Nëse VPN duhet të transportojë DNS, rruga lokale ka nevojë për politikën e vet.

Kujdes nga një cikël. Drejtimi i resolverit të sipërm të Pi-hole në një adresë që e shërben vetë Pi, drejtpërdrejt ose përmes një port-forward, prodhon kërkesa që rrotullohen derisa të skadojnë. Jepini një resolver të sipërm të vërtetë ose një forwarder të kushtëzuar për domenet të cilave nuk mund t'u përgjigjet.

Vendosni çfarë ndodh kur tuneli bie. Kthimi te resolveri lokal e mban shfletimin gjallë, por mund të rrjedhë emra jashtë VPN; bllokimi e mban politikën të paprekur dhe e kthen ndërprerjen në një gabim të dukshëm. Të dyja zgjedhjet janë të mbrojtshme, por duhet të zgjidhen, jo të trashëgohen nga një vlerë e paracaktuar.

Provoni rrugën dhe sjelljen gjatë ndërprerjes

Testoni në shtresa: klienti merr një adresë, klienti zgjidh një emër përmes Pi, Pi zgjidh përmes resolverit të synuar të sipërm, dhe një aplikacion përfundon një kërkesë. Një ping i suksesshëm nuk thotë asgjë për DNS, dhe një kërkim i suksesshëm nuk thotë asgjë për përcjelljen.

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

Më pas ndaloni tunelin dhe përsëritni. Sjellja e synuar duhet të shfaqet brenda disa sekondash, jo pas një rinisjeje manuale të Pi-hole ose të shërbimit të hotspotit. Kontrolloni cilësimin e resolverit të klientit gjatë ndërprerjes, sepse një resolver publik dytësor do të vazhdojë të përgjigjet edhe kur politika priste një dështim.

Mbajini një pronar për përcjelljen dhe NAT dhe verifikojeni atë nga një klient, jo nga vetë Pi. Një kërkesë që del me sukses nga Pi mund të hidhet ende në rrugën e kthimit, dhe klienti është i vetmi vend ku e gjithë rruga është e dukshme.