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 යෙන් සාර්ථකව පිටවන ඉල්ලීමක් ආපසු මාර්ගයේදී තවමත් ඉවත දැමිය හැක, සම්පූර්ණ මාර්ගය පෙනෙන එකම තැන සේවාලාභියා පමණි.