OpenVPN ಕ್ಲೈಂಟ್ಗಳನ್ನು ಇನ್ನೊಂದು ಹೋಸ್ಟ್ನಲ್ಲಿರುವ Pi-hole ರಿಸಾಲ್ವರ್ಗೆ ಕಳುಹಿಸಿ

OpenVPN ಪ್ರೊಫೈಲ್ನಲ್ಲಿ Pi-hole ವಿಳಾಸವನ್ನು ಹಾಕುವುದು ಅದಕ್ಕೆ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ಪ್ರಶ್ನಿಸಲು ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. Pi-hole ಬೇರೆ LAN ಯಂತ್ರದಲ್ಲಿದ್ದಾಗ ನಾಲ್ಕು ವಿಷಯಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕು: ಕ್ಲೈಂಟ್ನಿಂದ ಮಾರ್ಗ, ಗೇಟ್ವೇಯಿಂದ ಫಾರ್ವರ್ಡಿಂಗ್, ಪೂಲ್ನತ್ತ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು Pi-hole ಮೇಲೆಯೇ ಸ್ವೀಕೃತಿ ನೀತಿ. ಪ್ರತಿ ವೈಫಲ್ಯವೂ ಲಾಗ್ನಲ್ಲಿ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತದೆ. ಅವುಗಳನ್ನು ಇದೇ ಕ್ರಮದಲ್ಲಿ ನಿಭಾಯಿಸುವುದು ಕೊನೆಯದನ್ನು ಮೊದಲು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿದೆ. ಸಾಮಾನ್ಯ ಶಾರ್ಟ್ಕಟ್, ಪ್ರತಿ ಮೂಲಕ್ಕೂ ಪುನರಾವರ್ತನೆಯನ್ನು ತೆರೆಯುವುದು, ಸಣ್ಣ ಸಮಸ್ಯೆಯನ್ನು ಶಾಶ್ವತ ಸಮಸ್ಯೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.

ತಳ್ಳಲಾದ DNS ಆಯ್ಕೆ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನು ಮಾಡುವುದಿಲ್ಲ

ಸರ್ವರ್ ಕೆಳಗಿನ ಸೂಚನೆಯೊಂದಿಗೆ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ, 192.168.50.53 Pi-hole ಹೋಸ್ಟ್ ಎಂದು ಊಹಿಸಿ. ಕ್ಲೈಂಟ್ ಆಯ್ಕೆಯನ್ನು ಸ್ವೀಕರಿಸಿ, ತನ್ನ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮತ್ತು ರಿಸಾಲ್ವರ್ ಏಕೀಕರಣವನ್ನು ಅವಲಂಬಿಸಿ, ಅದನ್ನು ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತದೆ ಅಥವಾ ಸ್ಥಳೀಯ ಸ್ಟಬ್ಗೆ ಅನುಕೂಲವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ರೂಟ್ ಸಾಲು DNS ಸಾಲಿನಷ್ಟೇ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ತಲುಪಲಾಗದ ರಿಸಾಲ್ವರ್ ಯಾವುದೇ ರಿಸಾಲ್ವರ್ ಅಲ್ಲ. ಇದರಲ್ಲಿ ಯಾವುದೂ ಸರ್ವರ್ ಕಡೆಯಿಂದ ಕಾಣುವುದಿಲ್ಲ.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

ಆಯ್ಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದು ಅದನ್ನು ಬಳಸುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ. ರಿಸಾಲ್ವರ್ ಮ್ಯಾನೇಜರ್ ಇರುವ Linux ಕ್ಲೈಂಟ್ ತಳ್ಳಲಾದ ಸರ್ವರ್ ಅನ್ನು ಒಪ್ಪಿಕೊಂಡು ಕೆಲವು ಡೊಮೇನ್ಗಳನ್ನು ಮಾತ್ರ ಅದಕ್ಕೆ ಕಳುಹಿಸಬಹುದು; DNS ಅನ್ನು ತಾನೇ ನಿರ್ವಹಿಸುವ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮೇಲೆ ಬರೆಯಬಹುದು. ತಳ್ಳಲಾದ ರೂಟ್ಗಳು ಕೆಲವು ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಲ್ಲಿ ಸೀಮಿತವಾಗಿವೆ, ಇದು ಆಯ್ಕೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟರೂ ರಿಸಾಲ್ವರ್ ಅನ್ನು ತಲುಪಲಾಗದಂತೆ ಬಿಡುತ್ತದೆ. ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, ಸರ್ವರ್ನಲ್ಲಿ ಏನು ಕಳುಹಿಸಲಾಯಿತು ಎಂದಲ್ಲ.

ಆಯ್ಕೆ ಸರ್ವರ್ ಕಡೆಯ ಬಗ್ಗೆ ಸಹ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. DNS ಸಂಚಾರವು ಇನ್ನೂ ಕ್ಲೈಂಟ್ನಿಂದ ಗೇಟ್ವೇಗೆ ಮತ್ತು ಗೇಟ್ವೇಯಿಂದ Pi-holeಗೆ ಪ್ರಯಾಣಿಸಬೇಕು, ಯಾವುದೇ ಆಯ್ಕೆ ಅರ್ಥಪೂರ್ಣವಾಗುವ ಮೊದಲು. ಕಳೆದುಹೋದ ಮಾರ್ಗ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಪ್ರಶ್ನೆ ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಮೊದಲು ಗೇಟ್ವೇಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ.

Pi-hole ನಿಂದ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ

ಕ್ಲೈಂಟ್ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಸಂರಕ್ಷಿಸಿದರೆ, Pi-hole VPN ಪೂಲ್ನೊಳಗಿನ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ಅದರ ಸ್ವಂತ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಈ ಪೂಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಉತ್ತರವು ಅದರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಗೆ ಹೋಗಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಪ್ರಶ್ನೆ ಲಾಗ್ ಹೊಂದಿಕೆಯಾಗುವ ಉತ್ತರವಿಲ್ಲದ ವಿನಂತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದನ್ನು ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದು ಸುಲಭ.

LAN ರೌಟರ್ಗೆ ಪೂಲ್ಗಾಗಿ ಸ್ಥಿರ ಮಾರ್ಗವನ್ನು ನೀಡಿ, OpenVPN ಗೇಟ್ವೇ ಮುಂದಿನ ಹಾಪ್ ಆಗಿ, ಅಥವಾ Pi-holeಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮೊದಲು ಗೇಟ್ವೇಯಲ್ಲಿ ಮೂಲವನ್ನು ಅನುವಾದಿಸಿ. ಮೊದಲನೆಯದು ಪ್ರತಿ ಕ್ಲೈಂಟ್ನ ವಿಳಾಸಗಳನ್ನು Pi-hole ಪ್ರಶ್ನೆ ಲಾಗ್ನಲ್ಲಿ ಕಾಣುವಂತೆ ಇಡುತ್ತದೆ. ಎರಡನೆಯದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಆದರೆ ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನೂ ಗೇಟ್ವೇಯಿಂದ ಬಂದಂತೆ ತೋರಿಸುತ್ತದೆ. ಯಾವುದೂ ತಪ್ಪಲ್ಲ; ಅವು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ.

ಕ್ಲೈಂಟ್ವಾರು ವರದಿ ಅಥವಾ ನೀತಿ ಮುಖ್ಯವಾದರೆ ಸ್ಥಿರ ಮಾರ್ಗವೇ ಉತ್ತಮ ವಿನಿಮಯ. LAN ಬೇರೆಯವರ ನಿರ್ವಹಣೆಯಲ್ಲಿದ್ದು ಮಾರ್ಗ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಅನುವಾದವೇ ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆ, ಕ್ಲೈಂಟ್ ಗುರುತು ಕಳೆದುಕೊಳ್ಳುವುದನ್ನು ದಾಖಲಿಸಿ. ನೀವು ಯಾವುದನ್ನು ಆರಿಸಿದಿರಿ ಎಂದು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪ್ರತಿ ಲಾಗ್ ಪ್ರಶ್ನೆಯೂ ಅದನ್ನು ಅವಲಂಬಿಸಿದೆ.

ರೂಟ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್ಗಳಿಗೆ Pi-hole ನ ಆಲಿಸುವ ಮೋಡ್

DNS ಅಡಿಯಲ್ಲಿರುವ ಸೆಟ್ಟಿಂಗ್ಗಳ ಪುಟದಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಆಲಿಸುವ ವರ್ತನೆಯ ಡ್ರಾಪ್ಡೌನ್ Pi-hole ಯಾವ ಮೂಲಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕಟ್ಟುನಿಟ್ಟಾದ ಆಯ್ಕೆ ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸಲಾದ ನೆಟ್ವರ್ಕ್ಗಳ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತದೆ; ಸಾಧನಗಳಿಗೆ ಗರಿಷ್ಠ ಒಂದು ಹಾಪ್ ದೂರ ಅನುಮತಿಸುವ ಆಯ್ಕೆ ಅದನ್ನು ಪಕ್ಕದ ರೌಟರ್ನ ಹಿಂದಿನ ಉಪಜಾಲಗಳಿಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ರೂಟ್ ಮಾಡಿದ VPN ಕ್ಲೈಂಟ್ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಕಾಣುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ LAN ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ, ಆದರೆ ಅದರ ಮೂಲ ವಿಳಾಸ ಬೇರೆ ಉಪಜಾಲಕ್ಕೆ ಸೇರಿದೆ. ಇದು ನೀತಿ ನಿರಾಕರಣೆ, ರೂಟಿಂಗ್ ವೈಫಲ್ಯವಲ್ಲ, ಮತ್ತು ಲಾಗ್ಗಳನ್ನು ಓದುವಾಗ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ.

Pi-hole ನ ಆಲಿಸುವ ಮಾರ್ಗದರ್ಶಿ ಸ್ಥಳೀಯವಾಗಿ ಸಂಪರ್ಕಿಸಲಾದ ಮೂಲಗಳನ್ನು ರೂಟ್ ಮಾಡಿದ ಮೂಲಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಆಗಮನ ಇಂಟರ್ಫೇಸ್ ಮಾನದಂಡವಲ್ಲ. ಇಡೀ ಇಂಟರ್ನೆಟ್ಗೆ ಅನುಮತಿ ನೀಡದೆ VPN ಪೂಲ್ಗೆ ಅನುಮತಿ ನೀಡುವ ಮೋಡ್ ಆರಿಸಿ, ನಂತರ ಅದನ್ನು ಪೂಲ್ನಿಂದ ಮಾತ್ರ DNS ಸ್ವೀಕರಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮದೊಂದಿಗೆ ಜೋಡಿಸಿ.

ಮೊದಲ ಪ್ರಶ್ನೆ ಕೆಲಸ ಮಾಡಲು ಎಲ್ಲಾ ಮೂಲಗಳಿಗೆ ಪುನರಾವರ್ತನೆಯನ್ನು ತೆರೆಯುವುದು ತಪ್ಪು ದುರಸ್ತಿ. ಅದು ಖಾಸಗಿ ರಿಸಾಲ್ವರ್ ಅನ್ನು ತೆರೆದದ್ದಾಗಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಸೀಮಿತ ಅನುಮತಿ, ಜಾಗತಿಕವಲ್ಲ.

ಉತ್ತರವನ್ನು ಪ್ರಶ್ನೆ ಲಾಗ್ಗೆ ಹೊಂದಿಸಿ

ಕ್ಲೈಂಟ್ಗೆ ಕೇಳಿ, ನಂತರ ಸರ್ವರ್ ಪರಿಶೀಲಿಸಿ ಎರಡನ್ನೂ ಹೋಲಿಸಿ. systemd-resolved ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಕೆಳಗಿನ ಆದೇಶಗಳು ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರವನ್ನು ಉತ್ಪಾದಿಸಿತು ಮತ್ತು ಪ್ರತಿ ಲಿಂಕ್ಗೆ ಯಾವ ಸರ್ವರ್ಗಳು ಸಂರಚಿಸಲಾಗಿವೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತವೆ. Pi-hole ಮಾತ್ರ ತಿಳಿದಿರುವ ಹೆಸರನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ Pi-hole ವಿಳಾಸಕ್ಕೆ ನೇರ ಪ್ರಶ್ನೆ ತಲುಪುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಸಂರಚನೆಯನ್ನಲ್ಲ.

resolvectl query intranet.example.lan
resolvectl dns

ನಿರೀಕ್ಷಿತ ಉತ್ತರ 192.168.50.53 ಅನ್ನು ಸರ್ವರ್ ಎಂದು ಹೆಸರಿಸಿ ಆ ರಿಸಾಲ್ವರ್ ಮಾತ್ರ ತಿಳಿಯಬಹುದಾದ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ನಂತರ Pi-hole ನ ಸ್ವಂತ ನೋಟವನ್ನು ನೋಡಿ: pihole -t ಪ್ರಶ್ನೆ ಲಾಗ್ ಅನ್ನು ನೇರವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಸಾಲೂ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊತ್ತಿದೆ. ಮೂಲವು ಕ್ಲೈಂಟ್ನ ಟನೆಲ್ ವಿಳಾಸವಾದರೆ ಪೂಲ್ ಮಾರ್ಗ ಅಚ್ಚಳಿಯದೆ ಇರುತ್ತದೆ. ಅದು ಗೇಟ್ವೇಯ LAN ವಿಳಾಸವಾದರೆ ಮೂಲ ಅನುವಾದ ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ವಿಳಾಸ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ.

ಲಾಗ್ನಲ್ಲಿ ಏನೂ ಕಾಣದಿದ್ದರೆ ಪ್ರಶ್ನೆ ಎಂದಿಗೂ Pi-hole ತಲುಪಿಲ್ಲ ಮತ್ತು ಮುಂದಿನ ಪರಿಶೀಲನೆ ಗೇಟ್ವೇಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್. ಪ್ರಶ್ನೆ ಕಾಣಿಸಿ ಉತ್ತರ ಹಿಂತಿರುಗದಿದ್ದರೆ ಸಮಸ್ಯೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ, ಅಂದರೆ ಹಿಂದಿನ ವಿಭಾಗದಲ್ಲಿ. ವೈಫಲ್ಯವನ್ನು ಹೀಗೆ ವಿಭಜಿಸುವುದು ರೂಟಿಂಗ್ ದೋಷವನ್ನು ಫೈರ್ವಾಲ್ ನಿಯಮ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಗೇಟ್ವೇಯ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸಿ

ಗೇಟ್ವೇ ಕ್ಲೈಂಟ್ನ DNS ಪ್ಯಾಕೆಟ್ಗಳನ್ನು Pi-hole ಕಡೆಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು, ಮತ್ತು ಅದನ್ನು ಮಾಡುವ ನಿಯಮವನ್ನು ಊಹಿಸದೆ ಓದಬೇಕು. ಕೆಳಗಿನ ಆದೇಶಗಳು ಪೋರ್ಟ್ 53 ಅನ್ನು ಸ್ಪರ್ಶಿಸುವ ನಿಯಮಗಳನ್ನು ಕೌಂಟರ್ಗಳೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ, nftables ಹೋಸ್ಟ್ನಲ್ಲಿ ಮತ್ತು iptables ಹೋಸ್ಟ್ನಲ್ಲಿ. ಇದ್ದರೂ ಶೂನ್ಯ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ತೋರಿಸುವ ನಿಯಮ, ಸಂಚಾರವು ಅನುವಾದಕ್ಕೆ ಮೊದಲೇ ಎಸೆಯಲ್ಪಡುತ್ತಿದೆ ಎಂಬ ಸೂಚನೆ.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

ಕೌಂಟರ್ಗಳನ್ನು ಓದಿ, ನಿಯಮಗಳನ್ನು ಮಾತ್ರವಲ್ಲ. ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮ ಎಂದರೆ ಪ್ಯಾಕೆಟ್ ಇನ್ನೊಂದು ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ, ಅಥವಾ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಎಂದಿಗೂ ಕಳುಹಿಸಿಲ್ಲ. ಪ್ರತಿ ಪ್ರಶ್ನೆಗೂ ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮ ಎಂದರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಮಾರ್ಗದಲ್ಲಿ ಮುಂದಿದೆ.

ಹೋಸ್ಟ್ ಯಾವ ಸಾಧನವನ್ನು ಬಳಸಿದರೂ ಪರಿಶೀಲನೆಯನ್ನು ಸಂಕುಚಿತವಾಗಿ ಇಡಿ: ಪೂಲ್ ಮೂಲವಾಗಿ, ಪೋರ್ಟ್ 53 ಗಮ್ಯವಾಗಿ ಮತ್ತು Pi-hole ಏಕೈಕ ಅನುಮತಿಸಿದ ಗುರಿಯಾಗಿ. ಪೋರ್ಟ್ 80ಗೂ ಅನುಮತಿ ನೀಡುವ ವಿಶಾಲ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮ ಸಂಭವಿಸಲು ಕಾಯುತ್ತಿರುವ ಇನ್ನೊಂದು ಸಮಸ್ಯೆ.