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 ಯಿಂದ ಯಶಸ್ವಿಯಾಗಿ ಹೊರಹೋಗುವ ವಿನಂತಿ ಹಿಂತಿರುಗುವ ದಾರಿಯಲ್ಲಿ ಇನ್ನೂ ಬೀಳಬಹುದು, ಮತ್ತು ಇಡೀ ಮಾರ್ಗ ಕಾಣುವ ಏಕೈಕ ಸ್ಥಳ ಕ್ಲೈಂಟ್ ಮಾತ್ರ.