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 ഉദ്ദേശിച്ച മുകളിലെ റിസോൾവർ വഴി പരിഹരിക്കുന്നു, ഒരു ആപ്ലിക്കേഷൻ അഭ്യർത്ഥന പൂർത്തിയാക്കുന്നു. വിജയകരമായ 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 വിട്ട് വിജയകരമായി പോകുന്ന അഭ്യർത്ഥന മടക്കയാത്രയിൽ ഇപ്പോഴും ഉപേക്ഷിക്കാം, മുഴുവൻ പാത കാണാവുന്ന ഏക സ്ഥലം ക്ലൈന്റ് മാത്രമാണ്.