DNS ಮರುನಿರ್ದೇಶಿಸಿದ ನಂತರ dnsmasq ಪ್ರಶ್ನೆಗಳು VPN ನಿಂದ ಹೊರಬರುವುದು ಏಕೆ

LAN ಕ್ಲೈಂಟ್ ತನ್ನ VPN ತಲುಪುತ್ತದೆ, ಹಾಗಿದ್ದರೂ ಅದರ DNS ಪ್ರಶ್ನೆಗಳು ತಪ್ಪು ಮೇಲ್ಮುಖ ಕೊಂಡಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಇದು ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ ಸೋರಿಕೆ ಅಲ್ಲ; ರೌಟರ್ ಪ್ರಶ್ನೆಯನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ತಾನೇ ಉತ್ತರಿಸಿದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಪ್ರತಿಬಂಧವು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಳೀಯ ಸಾಕೆಟ್ಗೆ ಮರುಬರೆಯುತ್ತದೆ, ನಂತರ ರೆಸಾಲ್ವರ್ ತನ್ನದೇ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ತನ್ನದೇ ಮಾರ್ಗನಿರ್ಣಯದೊಂದಿಗೆ ಎರಡನೇ, ಸಂಬಂಧವಿಲ್ಲದ ಸಂಭಾಷಣೆಯನ್ನು ತೆರೆಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಹರಿವಿನ ಮೇಲೆ ಹಾಕಿದ ಗುರುತುಗಳು ಮೊದಲ ಸಂಭಾಷಣೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ ಮತ್ತು ಎರಡನೆಯದರ ಬಗ್ಗೆ ಸ್ವಲ್ಪವೂ ಹೇಳುವುದಿಲ್ಲ.

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

ಪ್ಯಾಕೆಟ್ ಗುರುತುಗಳು conntrack ನಮೂದು ಮತ್ತು ಹಾರಾಟದಲ್ಲಿರುವ ಪ್ಯಾಕೆಟ್ನಲ್ಲಿ ಜೀವಿಸುತ್ತವೆ. REDIRECT ನಿಯಮವು ಆ ಹಾರಾಟವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ: ಪೇಲೋಡ್ ಸ್ಥಳೀಯ ಸಾಕೆಟ್ಗೆ ನೀಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಮೂಲ ನಮೂದು ತನ್ನ ಕೆಲಸ ಮುಗಿಸಿದೆ. ನಂತರ ರೌಟರ್ನಿಂದ ಹೊರಬರುವುದು ರೆಸಾಲ್ವರ್ ಪ್ರಕ್ರಿಯೆ ಸೃಷ್ಟಿಸಿದ ಹೊಸ ಸಾಕೆಟ್, ಅದರ ಮೂಲ ರೌಟರ್ನದೇ ವಿಳಾಸ.

ಆದ್ದರಿಂದ LAN ಕ್ಲೈಂಟ್ನ ವಿಳಾಸದ ಮೇಲೆ ಕೀಲಿ ಹಾಕಿದ ನೀತಿ ಮಾರ್ಗವು ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರಶ್ನೆಗೆ ಎಂದಿಗೂ ಹೊಂದುವುದಿಲ್ಲ. ಹೊಸ ಸಾಕೆಟ್ ಕ್ಲೈಂಟ್ನದಲ್ಲ, dnsmasq ನದು, ಮತ್ತು ಕರ್ನಲ್ ಮಾರ್ಗವನ್ನು ರೌಟರ್ನದೇ ಸಂಚಾರಕ್ಕೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಮೂಲ ನಿಯಮಗಳು, ಇಂಟರ್ಫೇಸ್ ನಿಯಮಗಳು ಮತ್ತು ಗುರುತು ನಿಯಮಗಳು ಎಲ್ಲವೂ ಬೇರೆ tuple ನೋಡುತ್ತವೆ. ಗುರುತು ಹರಡುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು ಈ ಸೆಟಪ್ನಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯ ಕ್ಯಾಪ್ಚರ್ನಲ್ಲಿ ಅದು ಅಗೋಚರ.

ಎರಡೂ ಸಂಭಾಷಣೆಗಳು ಒಂದು ಹೆಸರು ಮತ್ತು ಒಂದು ಸಮಯವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಕ್ಯಾಪ್ಚರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ನೋಡಿದಾಗ ಅವು ಒಂದೇ ಹರಿವಿನಂತೆ ಕಾಣಲು ಅದೇ ಕಾರಣ.

ಎಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಸ್ಥಳೀಯ ಪರಿಹಾರವಾಗುತ್ತದೆ

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

ಎರಡೂ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ನೋಡಿ. UDP ಮತ್ತು TCP ಮೂಲಕ ತಲುಪಬಹುದಾದ ರೆಸಾಲ್ವರ್ ಎರಡರಲ್ಲೂ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು UDP ಅನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುವ ನಿಯಮ ಸಮೂಹವು ದೊಡ್ಡ ಉತ್ತರಗಳಿಗೆ ಶಾಂತ ಕುಳಿಯನ್ನು ಬಿಡುತ್ತದೆ. ರೌಟರ್ನದೇ ಸಂರಚನಾ ನಿರ್ವಾಹಕ ಸೃಷ್ಟಿಸಿದ ನಿಯಮಗಳೂ ಎಣಿಕೆಗೆ ಬರುತ್ತವೆ, ಮತ್ತು ಸೃಷ್ಟಿಸಿದ ಫೈಲ್ ಸಂಪಾದನೆ ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದಿನ ಮರುಲೋಡ್ಗೆ ಸೋಲುತ್ತದೆ.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

ಆ ಔಟ್ಪುಟ್ಗಳು ಕ್ರಮವಾಗಿ ಮೂರು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ: ಪ್ರಶ್ನೆಯನ್ನು ಯಾವುದು ಮರುಬರೆಯುತ್ತದೆ, ಯಾವುದು ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಕೇಳುತ್ತಿರುವ ಸಾಕೆಟ್ ಯಾವ ಪ್ರಕ್ರಿಯೆಯ ಒಡೆತನದಲ್ಲಿದೆ. ಮಾಲೀಕರು ತಿಳಿದ ನಂತರ ಅಪ್ಸ್ಟ್ರೀಮ್ ನೀತಿಗೆ ವಾಸಿಸಲು ಸ್ಥಳವಿದೆ.

ರೆಸಾಲ್ವರ್ಗೆ ಅದರದೇ ನಿರ್ಗಮನ ನೀತಿ ನೀಡಿ

ಕೆಲವು ಹೆಸರುಗಳಿಗೆ ಮಾತ್ರ ಸುರಂಗ ಬೇಕಾದಾಗ ಡೊಮೇನ್-ನಿರ್ದಿಷ್ಟ ಅಪ್ಸ್ಟ್ರೀಮ್ ಅತ್ಯಂತ ಸ್ವಚ್ಛ ಸಾಧನ. dnsmasq ಡೊಮೇನ್ಗೆ ಸೀಮಿತವಾದ server ಸಾಲನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಐಚ್ಛಿಕ ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಪ್ರಶ್ನೆಯನ್ನು ಆಯ್ದ ಸಾಧನದಿಂದ ಹೊರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಆ ಮಾರ್ಗದರ್ಶನವೇ ಎರಡನೇ ಸಂಭಾಷಣೆಯನ್ನು VPN ಅನುಸರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

server=/corp.example/10.30.0.53@tun_work
log-queries

ಮೇಲಿನ ಡೊಮೇನ್, ವಿಳಾಸ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಸ್ವಂತ ಮೌಲ್ಯಗಳಿಗೆ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗಳು. ಡೊಮೇನ್ ಆಯ್ಕೆ ಮತ್ತು ನಿರ್ಗಮನ ನಿಯಂತ್ರಣ ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳಾಗಿ ಉಳಿಯುತ್ತವೆ: ಮಾರ್ಗ ಇರಬೇಕು, ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಅಪ್ಸ್ಟ್ರೀಮ್ ರೆಸಾಲ್ವರ್ ಅನುಮತಿ ನೀಡಬೇಕು, ಮತ್ತು ಫೈರ್ವಾಲ್ ಉತ್ತರಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು. ಕೇವಲ ಇಂಟರ್ಫೇಸ್ ಮಾರ್ಗದರ್ಶನ fail-closed ಅಲ್ಲ, ಏಕೆಂದರೆ ಕಣ್ಮರೆಯಾದ ಸುರಂಗ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಇನ್ನೊಂದು ಮಾರ್ಗಕ್ಕೆ ಬೀಳಲು ಬಿಡಬಹುದು. ಯಾವುದೇ ಸಾರ್ವಜನಿಕ ಪರ್ಯಾಯವನ್ನು ಖಾಸಗಿಯಾಗಿ ಉಳಿಯಬೇಕಾದ ಹೆಸರಿನ ಜಾಗದಿಂದ ದೂರವಿಡಿ.

ಸಾಲನ್ನು ಸೃಷ್ಟಿಸಿದ ಫೈಲ್ನಲ್ಲಿ ಅಲ್ಲ, ರೌಟರ್ ಬೆಂಬಲಿಸುವ ಸಂರಚನಾ ಮಾಲೀಕರಲ್ಲಿ ಇರಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಮರುಲೋಡ್ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಅಳಿಸುತ್ತದೆ.

ಹಂಚಿದ ಕ್ಯಾಶ್ ಏನನ್ನು ಸಂರಕ್ಷಿಸಲಾರದು

ಒಂದು ಕ್ಯಾಶ್ನ ಒಂದು ಮುಂದುಕಳುಹಿಸುವಿ ಪ್ರತಿ LAN ಕ್ಲೈಂಟ್ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕೆಲವು ಜಾಲಗಳಿಗೆ ಬೇಕಾದ ವ್ಯತ್ಯಾಸವನ್ನು ಒಡೆಯುತ್ತದೆ. ಎರಡು ಕ್ಲೈಂಟ್ಗಳು ಒಂದೇ ಹೆಸರನ್ನು ಬೇರೆ ಬೇರೆಯಾಗಿ ಪರಿಹರಿಸಬೇಕಾದರೆ, ಹಂಚಿದ ಸಾಕೆಟ್ಗೆ ಯಾರು ಕೇಳಿದರು ಎಂಬುದನ್ನು ಮರಳಿ ಪಡೆಯುವ ದಾರಿ ಇಲ್ಲ. ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ನೀತಿ ಪ್ರತ್ಯೇಕ ರೆಸಾಲ್ವರ್ ನಿದರ್ಶನಗಳಲ್ಲಿ ಅಥವಾ ಗುರುತನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಮುಂದುಕಳುಹಿಸುವ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಇರಬೇಕು.

ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರವೂ ಹೊಸ ಮಾರ್ಗದ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅಪ್ಸ್ಟ್ರೀಮ್ ಮಾರ್ಗ ಮುರಿದಿದ್ದರೂ ಉತ್ತರ ಜ್ಞಾಪಕದಿಂದ ಬರಬಹುದು.

ಪೋರ್ಟ್ 53 ನಿಯಮಗಳು DNS ಅನ್ನು HTTPS ಅಥವಾ TLS ಮೇಲೆ ಮಾತನಾಡುವ ಅಪ್ಲಿಕೇಶನ್ಗಳ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಆ ಪ್ರಶ್ನೆಗಳು ಎಂದಿಗೂ ಮರುನಿರ್ದೇಶನವನ್ನು ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೇವಲ ಪೋರ್ಟ್ 53 ಮೇಲೆ ಕಟ್ಟಿದ ನೀತಿ ಸಂಚಾರದ ಒಂದು ಉಪಗುಂಪನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಉಪಗುಂಪಾಗಿ ದಾಖಲಿಸಬೇಕು.

ಎರಡನೇ ಸಂಭಾಷಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮೊದಲನೆಯದಲ್ಲ

ನೀವು ನಿಯಂತ್ರಿಸುವ ಒಂದು ಹೆಸರಿನಿಂದ ಪರೀಕ್ಷಿಸಿ ಎರಡೂ ಬದಿಗಳನ್ನು ನೋಡಿ. ಕ್ಲೈಂಟ್ ಬದಿಯ ಕ್ಯಾಪ್ಚರ್ ಪ್ರಶ್ನೆ LAN ಬಿಟ್ಟಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ; ನಂತರ ಅದು ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂಬುದನ್ನು ರೌಟರ್ ಬದಿ ಮಾತ್ರ ಸಾಬೀತು ಮಾಡುತ್ತದೆ.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

ಪ್ರತಿ ಪ್ರಯತ್ನಕ್ಕೂ ಮೊದಲು ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಬೆಚ್ಚಗಿನ ಉತ್ತರ ಮುರಿದ ಅಪ್ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಮುಚ್ಚಿಡುತ್ತದೆ. TCP ಮೇಲೆ ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಸುರಂಗ ಆಫ್ ಇರುವಾಗ ಪುನರಾವರ್ತಿಸಿ ರೆಸಾಲ್ವರ್ ತನ್ನ ಆದ್ಯತೆಯ ಮಾರ್ಗ ಹೋದಾಗ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ನೋಡಲು. ಆ ಕೊನೆಯ ವರ್ತನೆಯೇ ವಿನ್ಯಾಸ fail-closed ಆಗಿದೆಯೇ ಅಥವಾ ಸುಮ್ಮನೆ ಅದೃಷ್ಟವಂತೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.