Hotspot ng Pi kasama ang Pi-hole at VPN: bigyan ng sariling gawain ang bawat serbisyo

Kumokonekta ang telepono sa hotspot ng Pi, nakakakuha ng address, ngunit hindi pa rin bumubukas ang pahina. Nagpapatakbo ang Pi ng katulong ng hotspot, Pi-hole at client ng VPN, at bawat isa ay iniisip na may-ari ito ng bahagi ng landas. Karamihan sa mga ganitong build ay nabibigo hindi dahil sira ang isang bahagi, kundi dahil dalawang bahagi ang gumagawa ng parehong gawain. Magtalaga ng isang may-ari sa bawat tungkulin bago i-tune ang alinman sa kanila.

Magtalaga ng isang may-ari sa bawat tungkulin

Apat na tungkulin ang mahalaga dito, at bawat isa ay nangangailangan ng eksaktong isang may-ari. Ipinapakita ng talahanayan sa ibaba ang tungkulin, ang praktikal na may-ari at ang nasisira kapag dalawang serbisyo ang nag-aangkin nito.

Kadalasan ay isang pakete sa isang pagkakataon ang pagtatagpo. Nag-iinstall ang katulong ng hotspot ng sarili nitong dnsmasq, gusto ng Pi-hole ang port 53, at nagdaragdag ng ruta ang client ng VPN. Mukhang makatwiran ang bawat hakbang nang mag-isa, ngunit kapag pinagsama ay gumagawa sila ng makina kung saan tahimik na binabago ng ikalawang serbisyong nagsimula ang pag-uugali ng una.

Isulat ang mga may-ari bago i-enable ang anumang iba. Ang maikling talahanayan sa mga tala ng build ay pumipigil sa susunod na pag-install na angkinin ang isang tungkuling mayroon nang may-ari.

Pumili ng isang saklaw at ilayo ito sa tunnel

Piliin ang saklaw ng hotspot, ang address ng Pi dito, ang pool ng DHCP at ang resolver na natatanggap ng mga client. Ilayo ang saklaw na iyon sa upstream na LAN at sa saklaw ng tunnel ng VPN, dahil ang magkakapatong na subnet ay ginagawang proyekto ng pagsasalin ng address ang problema sa routing. Ang saklaw na kapareho ng tunnel ay ginagawang aksidenteng router ang Pi sa pagitan ng dalawang magkaparehong prefix. Isulat ang saklaw at pool sa configuration ng hotspot sa halip na iwanan sila sa default.

Kung pag-aari ng shared mode ng NetworkManager ang hotspot, suriin ang aktwal na koneksyon bago magdagdag ng server ng DHCP. Ang shared mode ay nagpapatakbo ng sarili nitong mga katulong at binubuksan ang pagpapasa, kaya may-ari na ito ng plano ng address para sa interface na iyon. Ang pagdaragdag ng pangalawang server dahil available ito ay lumilikha ng magkaribal na alok sa halip na redundancy.

Magpasya tungkol sa IPv6 nang sinasadya. Sa maraming setup, ang mga anunsyo ng router at DHCPv6 ay nagmumula sa ibang katulong kaysa sa DHCPv4, at ang pagpapanatiling bukas ng IPv6 habang ang patakaran ng VPN ay sumasaklaw lamang sa IPv4 ay nagbibigay sa mga client ng landas na lumalabas sa tunnel. Planuhin ang panig ng IPv6 o patayin ito sa interface ng hotspot na may nakasulat na dahilan.

Sino ba talaga ang sumasagot sa port 53

Ilista ang bawat prosesong nakikinig sa port 53 bago baguhin ang configuration. Sa isang Pi na nagpapatakbo ng lokal na stub ng resolver, Pi-hole at katulong ng pagbabahagi, ang listahan ng nakikinig ang tanging mapagkakatiwalaang mapa kung sino ang sumasagot sa mga query:

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

Ipinapaliwanag ng gabay sa interface ng Pi-hole na ang mode ng pagtanggap na limitado sa isang interface ay maaari pa ring gumamit ng wildcard socket at itapon ang dumarating sa ibang lugar. Hindi iyon katulad ng pag-bind lamang sa mga piling interface, na siyang kaayusang nilalayon kapag kailangang ibahagi ng ibang serbisyo ng DNS ang makina.

Karaniwang hindi kayang i-bind ng dalawang proseso ang parehong address at port, kahit na kayang gawing matagumpay ng SO_REUSEPORT ang pinagsasaluhang bind; kahit gayon, maaaring kunin ng wildcard listener ang dumarating na para sa mas makitid na serbisyo. Piliin ang dokumentadong mode para sa tungkuling gusto mo at i-restart ang mga serbisyo sa nilalayong pagkakasunod-sunod.

Ilayo ang pahina ng administrasyon ng Pi-hole sa network ng hotspot. Kailangan ng mga client ang resolver, hindi ang web interface o API na maaaring magbago ng configuration ng resolver.

Dalawang binti ng DNS, isang patakaran bawat isa

Ang query ng client ay naglalakbay mula sa telepono patungo sa Pi, at ang hiwalay na query ay naglalakbay mula sa Pi patungo sa upstream na resolver nito. Ang tuntunin sa routing na tumutugma sa ipinapasang trapiko ng hotspot ay hindi awtomatikong nalalapat sa ikalawang binti, dahil ang Pi ang gumagawa ng trapikong iyon sa lokal. Kung dapat magdala ng DNS ang VPN, kailangan ng lokal na landas ang sarili nitong patakaran.

Mag-ingat sa loop. Ang pagturo sa upstream ng Pi-hole sa isang address na pinaglilingkuran mismo ng Pi, direkta man o sa pamamagitan ng port-forward, ay gumagawa ng mga query na umiikot hanggang mag-timeout. Bigyan ito ng tunay na upstream o conditional forwarder para sa mga domain na hindi nito masagot.

Magpasya kung ano ang mangyayari kapag bumagsak ang tunnel. Ang pagbabalik sa lokal na resolver ay nagpapanatili ng pagba-browse ngunit maaaring magtagas ng mga pangalan palabas ng VPN; ang pagharang ay nagpapanatili ng patakaran at ginagawang nakikitang error ang pagkawala. Pareho silang may katwiran, ngunit kailangang piliin at hindi mamanahin mula sa default.

Patunayan ang landas at ang pag-uugali kapag may pagkawala

Subukan nang pa-layer: nakakakuha ng address ang client, niresolba ng client ang pangalan sa pamamagitan ng Pi, niresolba ng Pi sa pamamagitan ng nilalayong upstream, at nakukumpleto ng application ang isang kahilingan. Ang matagumpay na ping ay walang sinasabi tungkol sa DNS, at ang matagumpay na paghahanap ay walang sinasabi tungkol sa pagpapasa.

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

Pagkatapos ay itigil ang tunnel at ulitin. Dapat lumitaw ang nilalayong pag-uugali sa loob ng ilang segundo, hindi pagkatapos ng manu-manong pag-restart ng Pi-hole o ng serbisyo ng hotspot. Suriin ang setting ng resolver ng client habang may pagkawala, dahil ang pangalawang pampublikong resolver ay patuloy na sasagot kahit inaasahan ng patakaran ang pagkabigo.

Panatilihin ang isang may-ari para sa pagpapasa at NAT at i-verify ito mula sa client, hindi mula sa Pi mismo. Ang kahilingang matagumpay na lumabas sa Pi ay maaari pa ring itapon sa pagbabalik, at ang client ang tanging lugar kung saan nakikita ang buong landas.