Pi-hole v6 WireGuard ಕ್ಲೈಂಟ್‌ಗಳ DNS ಪ್ರಶ್ನೆಗಳನ್ನು ಏಕೆ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ

Pi-hole v6 ಪೋರ್ಟ್ 53 ನಲ್ಲಿ DNS ಪ್ರಶ್ನೆಯನ್ನು ಸ್ವೀಕರಿಸಿ, ನಂತರ ಬಂದ ಪ್ಯಾಕೆಟ್‌ಗೆ ಉತ್ತರಿಸಲು ಅನುಮತಿ ಇದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. WireGuard ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಈ ಎರಡನೇ ನಿರ್ಧಾರವೇ ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್‌ಗೆ ಟೈಮೌಟ್ ಆಗುವ ಕಾರಣ, ಆದರೆ LAN ನಿಂದ ರಿಜಾಲ್ವರ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ. ಪೋರ್ಟ್ ತೆರೆದಿದೆ, FTL ಚಾಲನೆಯಲ್ಲಿದೆ, ಆದರೂ 10.90.0.1 ನಿಂದ ಏನೂ ಹಿಂತಿರುಗುತ್ತಿಲ್ಲ. ಉತ್ತರ ಹೊರಡುವ ಮೊದಲು ಮೂರು ವಿಷಯಗಳು ಪರಸ್ಪರ ಕ್ರಿಯಿಸುತ್ತವೆ: dns.interface, dns.listeningMode ಮತ್ತು ಎರಡರ ಮುಂದೆ ಇರುವ ಫೈರ್‌ವಾಲ್.

ಆಲಿಸುವ ಸಾಕೆಟ್ ಯಾರಿಗೆ ಉತ್ತರ ಸಿಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ

FTL ಪೋರ್ಟ್ 53 ನಲ್ಲಿ UDP ಮತ್ತು TCP ಆಲಿಸುವವರನ್ನು ತೆರೆಯುತ್ತದೆ. ಡಿಫಾಲ್ಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಸಾಕೆಟ್ ಸಾಮಾನ್ಯವಾಗಿ wildcard ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ss -lunp | grep :53 VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ಸಿಗುತ್ತಿದೆಯೋ ಇಲ್ಲವೋ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ 0.0.0.0:53 ಮತ್ತು [::]:53 ತೋರಿಸುತ್ತದೆ. wildcard ಸಾಕೆಟ್ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುತ್ತದೆ, ನಂತರ FTL ಉತ್ತರಿಸುವ ಮೊದಲು ತನ್ನ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ "ಪೋರ್ಟ್ ಆಲಿಸುತ್ತಿದೆ" ಎಂಬ ಮಾತು ಟನೆಲ್ ಕ್ಲೈಂಟ್ ಬಗ್ಗೆ ಬಹಳ ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ.

ನೀವು ಸಕ್ರಿಯ ಎಂದು ಭಾವಿಸುವ ಫೈಲ್‌ಗಿಂತ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂರಚನೆಯನ್ನು ಓದಿ. pihole-FTL --config dns.interface ಮತ್ತು pihole-FTL --config dns.listeningMode ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯಗಳನ್ನು ಮುದ್ರಿಸುತ್ತವೆ, ಮತ್ತು ಕಂಟೇನರ್, ಪರಿಸರ ಚರ ಅಥವಾ ನಿಯೋಜನಾ ನಿರ್ವಾಹಕವು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಹೊಂದಿದಾಗ ಅವು ಹೋಸ್ಟ್ ಫೈಲ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿರಬಹುದು. Pi-hole FTL ಸಂರಚನಾ ಉಲ್ಲೇಖ ಮೋಡ್‌ಗಳನ್ನು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

LOCAL ಯಾವ ಸಬ್‌ನೆಟ್ ಎಂದು ಕೇಳುತ್ತದೆ, SINGLE ಯಾವ ಇಂಟರ್ಫೇಸ್ ಎಂದು ಕೇಳುತ್ತದೆ

LOCAL, ಡಿಫಾಲ್ಟ್, ಮೂಲ ವಿಳಾಸವು ಹೋಸ್ಟ್‌ನ ಒಂದು ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸಂರಚಿಸಿದ ಸಬ್‌ನೆಟ್‌ಗೆ ಸೇರಿದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. 10.90.0.1/24 ಹೊಂದಿರುವ ಸರಳ wg0 ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ 10.90.0.2 ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಸಬ್‌ನೆಟ್ ಒಳಗಿದೆ. ಪೀರ್‌ನ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ರೂಟ್ ಆದ ಕ್ಲೈಂಟ್, ಅಥವಾ ಬೇರೆ ಪ್ರಿಫಿಕ್ಸ್‌ನಲ್ಲಿ NAT ಹಿಂದೆ ಅಡಗಿರುವ ಕ್ಲೈಂಟ್, ಪ್ಯಾಕೆಟ್ wg0 ಗೆ ಬಂದರೂ ಅದನ್ನು ದಾಟುವುದಿಲ್ಲ, ಮತ್ತು ಲಾಗ್‌ನಲ್ಲಿ ಯಾವುದೇ ಪ್ರಶ್ನೆ ಕಾಣಿಸುವುದಿಲ್ಲ.

SINGLE ಪ್ರಶ್ನೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ. ಇದು dns.interface ನಲ್ಲಿ ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಲೂಪ್‌ಬ್ಯಾಕ್ ಸೇರಿದಂತೆ, ಮತ್ತು ಮೂಲ ಸಬ್‌ನೆಟ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಸರಪಳಿ ಅಥವಾ ರೂಟ್ ಮಾಡಿದ VPN ಟೋಪಾಲಜಿಯಲ್ಲಿ ಉಳಿಯುವ ಮೋಡ್ ಇದೇ. ಎರಡೂ ಕೀಗಳನ್ನು ಒಟ್ಟಿಗೆ ಹೊಂದಿಸಿ, ಏಕೆಂದರೆ ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲದ ಮೋಡ್ ಪೂರ್ಣ ಸೂಚನೆ ಅಲ್ಲ:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND ಸಾಕೆಟ್ ಅನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಬೆಲೆ ಇದೆ

BIND wildcard ಸಾಕೆಟ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದಿಲ್ಲ; ಅದು ಪೋರ್ಟ್ 53 ಅನ್ನು ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಇರುವ ವಿಳಾಸಗಳಿಗೆ ಮಾತ್ರ ಬಂಧಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕರ್ನಲ್ ಬೇರೆಡೆ ಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ. ಇದು SINGLE ಗಿಂತ ಕಠಿಣ ಮತ್ತು ಅದರ ಸಮಾನಾರ್ಥಕವಲ್ಲ. FTL ಪ್ರಾರಂಭವಾದಾಗ wg0 ಮೇಲಿಲ್ಲದಿದ್ದರೆ ಬಂಧಿಸಲು ವಿಳಾಸ ಇಲ್ಲದಿರಬಹುದು, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಕಾಣಿಸಿ FTL ಮರುಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ರಿಜಾಲ್ವರ್ ಆಲಿಸುವವನಿಲ್ಲದೆ ಚಲಿಸಬಹುದು ಎಂಬುದು ಬೂಟ್‌ನಲ್ಲಿ ಬೆಲೆ ಕಾಣುತ್ತದೆ.

ಪ್ರಾರಂಭದ ಕ್ರಮವನ್ನು ನೀವು ನಿಯಂತ್ರಿಸಿದಾಗ BIND ಆಯ್ಕೆಮಾಡಿ, ಉದಾಹರಣೆಗೆ WireGuard ಇಂಟರ್ಫೇಸ್ ನಂತರ ಜೋಡಿಸಿದ systemd ಘಟಕ, ಮತ್ತು FTL ನೋಡುವ ಮೊದಲೇ ಅಲೆದಾಡುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕರ್ನಲ್ ಬಿಸಾಡಬೇಕೆಂದು ಬಯಸಿದಾಗ. ಟನೆಲ್ ಬಂದು ಹೋಗುವಾಗ, ಅಥವಾ FTL ನಂತರ ಪ್ರಾರಂಭವಾಗುವ ಸಾಧನ ಇಂಟರ್ಫೇಸ್ ರಚಿಸಿದಾಗ SINGLE ಆಯ್ಕೆಮಾಡಿ.

ಫೈರ್‌ವಾಲ್ ಎರಡನೇ ದ್ವಾರ

ಸರಿಯಾದ FTL ಮೋಡ್ ಕೂಡ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ wg0 ನಲ್ಲಿ ಪೋರ್ಟ್ 53 ಬಿಸಾಡಿದರೆ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ VPN ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ಅನುಮತಿಸಿ ಮತ್ತು ಇಂಟರ್ನೆಟ್ ಬದಿಯನ್ನು ಮುಚ್ಚಿಡಿ. inet filter ಕೋಷ್ಟಕದಲ್ಲಿ ಇರುವ input ಸರಪಳಿಯೊಂದಿಗೆ nftables ನಲ್ಲಿ ನಿಯಮಗಳು ಹೀಗೆ ಕಾಣುತ್ತವೆ:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

ಟನೆಲ್ IPv6 ಸಾಗಿಸಿದರೆ ಹೊಂದುವ IPv6 ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿ, ಮತ್ತು ಅವನ್ನು ಸರಪಳಿಯ drop ನೀತಿಗಿಂತ ಮೊದಲು ಇರಿಸಿ. ಹೋಸ್ಟ್ ufw ಅಥವಾ firewalld ಬಳಸಿದರೆ, ಸಾಧನಗಳನ್ನು ಮಿಶ್ರ ಮಾಡುವ ಬದಲು ಅದೇ ನಿರ್ವಾಹಕದಲ್ಲಿ ಅದೇ ಹೊಂದಾಣಿಕೆಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಿ. ಇಂಟರ್ನೆಟ್ ರೌಟರ್‌ನಿಂದ ಪೋರ್ಟ್ 53 ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಡಿ; ಕ್ಲೈಂಟ್‌ಗಳು ಟನೆಲ್ ಮೂಲಕ ರಿಜಾಲ್ವರ್‌ನ VPN ವಿಳಾಸವನ್ನು ತಲುಪಬೇಕು.

ಎರಡು ಮಾರ್ಗಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಉಳಿಯುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಪ್ರಶ್ನೆಗಳು FTL ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. FTL ನ ಸ್ವಂತ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಹುಡುಕಾಟಗಳು ಹೋಸ್ಟ್‌ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಪ್ರಕಾರ ಹೊರಡುತ್ತವೆ, ಅದು ಟನೆಲ್ ಬಳಸಬಹುದು ಅಥವಾ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಉತ್ತರಿಸಿ ಆದರೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹಿಂತಿರುಗಿಸದ ರಿಜಾಲ್ವರ್ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸಮಸ್ಯೆ. ವೆಬ್ ನಿರ್ವಾಹಕೆ ಮತ್ತು API ತಮ್ಮ ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ ಆಲಿಸುತ್ತವೆ ಮತ್ತು ತಮ್ಮದೇ ನಿರ್ಬಂಧ ಬೇಕು.

ಉತ್ತರ ಮತ್ತು ನಿರಾಕರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ, ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ರಿಜಾಲ್ವರ್ ವಿಳಾಸವನ್ನು ಕೇಳಿ: dig @10.90.0.1 example.com ಮತ್ತು dig +tcp @10.90.0.1 example.com. ನಂತರ FTL ಪ್ರಶ್ನೆಯನ್ನು ದಾಖಲಿಸಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಲು ನಿರ್ವಾಹಕ ಇಂಟರ್ಫೇಸ್‌ನ ಪ್ರಶ್ನೆ ಲಾಗ್ ಪರಿಶೀಲಿಸಿ. ಲಾಗ್ ನಮೂದು ಇಲ್ಲದ ಕ್ಲೈಂಟ್ ಟೈಮೌಟ್ ಫೈರ್‌ವಾಲ್ ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಫಿಲ್ಟರ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ; ಉತ್ತರವಿಲ್ಲದ ಲಾಗ್ ನಮೂದು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಪರಿಹಾರಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ.

VPN ನ ಹೊರಗಿನ ಹೋಸ್ಟ್‌ನಿಂದ ಋಣಾತ್ಮಕ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ. dig @10.90.0.1 example.com ಟೈಮೌಟ್ ಆಗಬೇಕು, ಮತ್ತು ss -lunp ರಿಜಾಲ್ವರ್‌ನಲ್ಲಿ ಪೋರ್ಟ್ 53 ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿದಂತೆ ತೋರಿಸಬಾರದು. ಸೇವೆಯನ್ನು ಒಮ್ಮೆ ಮರುಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಹೋಸ್ಟ್ ಮರುಬೂಟ್ ಮಾಡಿ ಮತ್ತು wg0 ಮತ್ತೆ ಕಾಣಿಸಿದ ನಂತರವೂ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಮುಂದಿನ ಮರುಬೂಟ್ ವರೆಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಪ್ರಶ್ನೆ ಪೂರ್ಣಗೊಂಡ ಬದಲಾವಣೆ ಅಲ್ಲ.