Hotspot ya Pi pamoja na Pi-hole na VPN: ipe kila huduma kazi yake

Simu inajiunga na hotspot ya Pi, inapata anwani, lakini ukurasa bado haufunguki. Pi inaendesha msaidizi wa hotspot, Pi-hole na mteja wa VPN, na kila mmoja anadhani anamiliki sehemu ya njia. Mengi ya miundo hii hushindwa si kwa sababu kipengele kimeharibika, bali kwa sababu vipengele viwili hufanya kazi moja. Toa mmiliki mmoja kwa kila kazi kabla ya kurekebisha yoyote kati yao.

Toa mmiliki mmoja kwa kila kazi

Hapa kazi nne ni muhimu, na kila moja inahitaji mmiliki mmoja hasa. Jedwali lililo hapa chini linaonyesha kazi, mmiliki anayewezekana na kinachoharibika wakati huduma mbili zinaidai.

Mwingiliano kwa kawaida huja pakiti moja kwa wakati. Msaidizi wa hotspot hufunga dnsmasq yake mwenyewe, Pi-hole inataka lango 53, na mteja wa VPN anaongeza njia. Kila hatua inaonekana kuwa nzuri peke yake, na kwa pamoja hutengeneza mashine ambayo huduma ya pili kuanza hubadilisha kwa utulivu tabia ya kwanza.

Andika wamiliki kabla ya kuwasha kitu kingine. Jedwali fupi katika maelezo ya ujenzi huzuia usakinishaji wa baadaye kuchukua kazi ambayo tayari ilikuwa na mmiliki.

Chagua anuwai moja na uweke mbali na handaki

Chagua anuwai ya hotspot, anwani ya Pi ndani yake, dimbwi la DHCP na resolver ambayo wateja wanapata. Weka anuwai hiyo tofauti na LAN ya juu na na anuwai ya handaki ya VPN, kwa sababu subnet zinazoingiliana hugeuza tatizo la uelekezaji kuwa mradi wa kutafsiri anwani. Anuwai inayoingiliana na handaki hufanya Pi kuwa kipanga njia cha bahati mbaya kati ya viambishi viwili sawa. Andika anuwai na dimbwi katika usanidi wa hotspot badala ya kuviachia kwenye chaguo-msingi.

Ikiwa hali ya kushiriki ya NetworkManager inamiliki hotspot, kagua muunganisho unaotumika kabla ya kuongeza seva ya DHCP. Hali ya kushiriki huanzisha wasaidizi wake na huwasha upelekaji, kwa hivyo tayari ni mmiliki wa mpango wa anwani kwa kiolesura hicho. Kuongeza seva ya pili kwa sababu inapatikana huzalisha ofa shindani badala ya upungufu wa akiba.

Amua kuhusu IPv6 kwa makusudi. Matangazo ya kipanga njia na DHCPv6 katika usanidi mwingi hutoka kwa msaidizi tofauti na DHCPv4, na kuacha IPv6 imewashwa wakati sera ya VPN inashughulikia IPv4 pekee huwapa wateja njia inayopita handaki. Ama panga upande wa IPv6 au uzime kwenye kiolesura cha hotspot ukiwa na sababu iliyoandikwa.

Nani hasa anajibu kwenye lango 53

Orodhesha kila mchakato unaosikiliza lango 53 kabla ya kubadilisha usanidi. Kwenye Pi inayoendesha stub ya resolver ya ndani, Pi-hole na msaidizi wa kushiriki, orodha ya wasikilizaji ndiyo ramani pekee ya kuaminika ya nani anajibu maswali:

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

Mwongozo wa violesura wa Pi-hole unaeleza kwamba hali ya upokeaji iliyozuiwa kwa kiolesura kimoja bado inaweza kutumia soketi ya wildcard na kutupa yanayowasili mahali pengine. Hiyo si sawa na kufunga violesura vilivyochaguliwa pekee, ambao ni mpango unaokusudiwa wakati huduma nyingine ya DNS inapaswa kushiriki mashine.

Michakato miwili kwa kawaida haiwezi kufunga anwani na lango moja, ingawa SO_REUSEPORT inaweza kufanikisha ufungaji wa pamoja; hata hivyo, msikilizaji wa wildcard anaweza kuchukua yanayowasili yaliyokusudiwa huduma nyembamba zaidi. Chagua hali iliyoandikwa kwa jukumu unalotaka na uanzishe upya huduma kwa mpangilio uliokusudiwa.

Weka ukurasa wa usimamizi wa Pi-hole nje ya mtandao wa hotspot. Wateja wanahitaji resolver, si kiolesura cha wavuti au API inayoweza kubadilisha usanidi wa resolver.

Miguu miwili ya DNS, sera moja kwa kila mmoja

Swali la mteja husafiri kutoka simu hadi Pi, na swali tofauti husafiri kutoka Pi hadi resolver yake ya juu. Kanuni ya uelekezaji inayolingana na trafiki ya hotspot iliyopekezwa haitumiki kiotomatiki kwa mguu wa pili, kwa sababu Pi huzalisha trafiki hiyo ndani. Ikiwa VPN inapaswa kubeba DNS, njia ya ndani inahitaji sera yake mwenyewe.

Kuwa mwangalifu na kitanzi. Kuelekeza resolver ya juu ya Pi-hole kwenye anwani ambayo Pi yenyewe inahudumia, moja kwa moja au kupitia upelekaji wa lango, huzalisha maswali yanayozunguka hadi muda uishe. Ipe resolver ya juu halisi au kipeleka cha masharti kwa vikoa ambavyo haiwezi kujibu.

Amua kinachotokea handaki inapoanguka. Kurudi kwenye resolver ya ndani huweka uvinjari hai lakini kunaweza kuvujisha majina nje ya VPN; kuzuia huweka sera bila kubadilika na hugeuza hitilafu kuwa kosa linaloonekana. Chaguo zote mbili zinaweza kuteteleka, lakini ni lazima zichaguliwe badala ya kurithiwa kutoka chaguo-msingi.

Thibitisha njia na tabia wakati wa hitilafu

Jaribu kwa tabaka: mteja anapata anwani, mteja hutatua jina kupitia Pi, Pi hutatua kupitia resolver ya juu iliyokusudiwa, na programu hukamilisha ombi. Ping iliyofanikiwa haisemi chochote kuhusu DNS, na utafutaji uliofanikiwa hausemi chochote kuhusu upelekaji.

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

Kisha simamisha handaki na urudie. Tabia iliyokusudiwa inapaswa kuonekana ndani ya sekunde chache, si baada ya kuanzisha upya Pi-hole au huduma ya hotspot kwa mkono. Kagua mpangilio wa resolver wa mteja wakati wa hitilafu, kwa sababu resolver ya umma ya akiba itaendelea kujibu hata sera ilipokuwa ikitarajia kushindwa.

Weka mmiliki mmoja kwa upelekaji na NAT na uthibitishe kutoka kwa mteja, si kutoka kwa Pi yenyewe. Ombi linalotoka Pi kwa mafanikio bado linaweza kutupwa njiani kurudi, na mteja ndio mahali pekee ambapo njia yote inaonekana.