Pi હોટસ્પોટ Pi-hole અને VPN સાથે: દરેક સેવાને તેનું કામ સોંપો
એક જ Pi પર ત્રણ સહાયક ચાલુ કરતા પહેલા નક્કી કરો કે DHCP, DNS અને પેકેટ ફોરવર્ડિંગનો માલિક કોણ છે. બમણા માલિકો સ્પર્ધાત્મક લીઝ અને રિઝોલ્વર લૂપ પેદા કરે છે.
એક ફોન Pi ના હોટસ્પોટ સાથે જોડાય છે, સરનામું મેળવે છે, અને પૃષ્ઠ હજી પણ ખૂલતું નથી. Pi એક હોટસ્પોટ સહાયક, Pi-hole અને VPN ક્લાયંટ ચલાવી રહ્યું છે, અને દરેક માને છે કે તે માર્ગનો કોઈ ભાગ ધરાવે છે. આવા મોટા ભાગના બિલ્ડ ઘટક બગડવાથી નહીં, પણ એટલા માટે નિષ્ફળ જાય છે કે બે ઘટકો એક જ કામ કરે છે. કોઈપણ ટ્યુન કરતા પહેલા દરેક ફંક્શન માટે એક માલિક નક્કી કરો.
દરેક ફંક્શન માટે એક માલિક નક્કી કરો
અહીં ચાર ફંક્શન મહત્ત્વના છે, અને દરેકને બરાબર એક માલિક જોઈએ. નીચેનું કોષ્ટક ફંક્શન, વ્યવહારુ માલિક અને બે સેવાઓ દાવો કરે ત્યારે શું ખોટું જાય તે જણાવે છે.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
ઓવરલેપ સામાન્ય રીતે એક સમયે એક પેકેટ આવે છે. હોટસ્પોટ સહાયક પોતાની 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 routePi-hole ની ઇન્ટરફેસ માર્ગદર્શિકા સમજાવે છે કે એક ઇન્ટરફેસ સુધી મર્યાદિત સ્વીકૃતિ મોડ હજી પણ wildcard સોકેટ વાપરી શકે છે અને બીજે આવતા પેકેટ ફેંકી શકે છે. આ ફક્ત પસંદ કરેલા ઇન્ટરફેસ બાંધવા જેવું નથી, જે ત્યારે ઇચ્છિત ગોઠવણ છે જ્યારે બીજી DNS સેવાએ મશીન શેર કરવું પડે.
બે પ્રક્રિયાઓ સામાન્ય રીતે એક જ સરનામું અને પોર્ટ બાંધી શકતી નથી, જોકે SO_REUSEPORT શેર્ડ બાઇન્ડને સફળ બનાવી શકે છે; તો પણ wildcard સાંભળનાર સાંકડી સેવા માટે આવેલા પેકેટ લઈ શકે છે. ઇચ્છિત ભૂમિકા માટે દસ્તાવેજી મોડ પસંદ કરો અને સેવાઓને ઇચ્છિત ક્રમમાં ફરી શરૂ કરો.
Pi-hole નું વ્યવસ્થાપન પૃષ્ઠ હોટસ્પોટ નેટવર્કની બહાર રાખો. ક્લાયંટને રિઝોલ્વર જોઈએ, તે વેબ ઇન્ટરફેસ કે API નહીં જે રિઝોલ્વરની રૂપરેખાંકન બદલી શકે.
DNS ના બે પગ, દરેક માટે એક નીતિ
ક્લાયંટની ક્વેરી ફોનથી Pi સુધી જાય છે, અને અલગ ક્વેરી Pi થી તેના ઉપરના રિઝોલ્વર સુધી જાય છે. ફોરવર્ડ કરેલા હોટસ્પોટ ટ્રાફિક સાથે મેળ ખાતો રૂટિંગ નિયમ બીજા પગ પર આપમેળે લાગુ પડતો નથી, કારણ કે Pi તે ટ્રાફિક સ્થાનિક રીતે બનાવે છે. જો VPN એ DNS વહન કરવાનું હોય, તો સ્થાનિક માર્ગને તેની પોતાની નીતિ જોઈએ.
લૂપથી સાવધ રહો. Pi-hole ના ઉપરના રિઝોલ્વરને એવા સરનામા તરફ વાળવું જે Pi પોતે પરોવે છે, સીધું અથવા પોર્ટ-ફોરવર્ડ દ્વારા, એવી ક્વેરી બનાવે છે જે સમય પૂરો થાય ત્યાં સુધી ફરે છે. તેને સાચું ઉપરનું રિઝોલ્વર આપો અથવા જે ડોમેનનો જવાબ આપી શકતું નથી તેના માટે શરતી ફોરવર્ડર આપો.
ટનલ પડે ત્યારે શું થાય તે નક્કી કરો. સ્થાનિક રિઝોલ્વર પર પાછા જવું બ્રાઉઝિંગને જીવંત રાખે છે પણ નામ VPN બહાર લઈ જઈ શકે છે; બ્લોક કરવું નીતિને અકબંધ રાખે છે અને ખામીને દેખાતી ભૂલ બનાવે છે. બંને પસંદગી વાજબી છે, પણ તે પસંદ કરવી પડે, ડિફોલ્ટમાંથી વારસામાં નહીં લેવી.
માર્ગ અને ખામી વખતનું વર્તન સાબિત કરો
સ્તરોમાં ચકાસો: ક્લાયંટને સરનામું મળે છે, ક્લાયંટ Pi દ્વારા નામ ઉકેલે છે, Pi ઇચ્છિત ઉપરના રિઝોલ્વર દ્વારા ઉકેલે છે, અને એપ્લિકેશન વિનંતી પૂરી કરે છે. સફળ પિંગ 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 માંથી સફળતાપૂર્વક નીકળતી વિનંતી પાછા ફરતા માર્ગમાં હજી પણ પડી શકે છે, અને ક્લાયંટ એ એકમાત્ર જગ્યા છે જ્યાં આખો માર્ગ દેખાય છે.