VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಹಾಟ್‌ಸ್ಪಾಟ್ DNS ಅನ್ನು ಏಕೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ?
ಹಾಟ್‌ಸ್ಪಾಟ್ ತನ್ನ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಲುಕಪ್‌ಗಳನ್ನು ಮರುಬರೆಯುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಸುರಂಗ ಇರುವ ಮೊದಲೇ ಹೋಸ್ಟ್‌ನಾಮ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂಬುದನ್ನು ಪತ್ತೆ ಮಾಡಿ.
ಹೋಟೆಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೇರುವುದು ನಿಮ್ಮ ಮುಂದೆ ಬೇರೆ ಬೇರೆ ಕ್ಷಣಗಳಲ್ಲಿ ಎರಡು DNS ನಿರ್ಧಾರಗಳನ್ನು ಇಡುತ್ತದೆ: ಸೈನ್ ಇನ್ ಮಾಡುವಾಗ ಸಾಧನ ಮಾಡುವ ಲುಕಪ್‌ಗಳು, ಮತ್ತು ಸುರಂಗ ಏರಿದ ನಂತರ ಮಾಡುವ ಲುಕಪ್‌ಗಳು. ಹಾಟ್‌ಸ್ಪಾಟ್ ತಾನು ನಿಯಂತ್ರಿಸುವ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಮೊದಲನೆಯದಕ್ಕೆ ಪ್ರಭಾವ ಬೀರಬಹುದು. ಎರಡನೆಯದು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ನೀತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಇದು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕಾದ ವಿಷಯ.
ಸಂಪರ್ಕವನ್ನು ಕ್ರಮವಾಗಿ ನೋಡಿ, ಮೊದಲ DHCP ಲೀಸ್‌ನಿಂದ ಖಾಸಗಿ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿದ ಪ್ರಶ್ನೆಯವರೆಗೆ. ಆಗ ಬೆಂಬಲ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ವೈಫಲ್ಯಗಳು ಸ್ಪಷ್ಟವಾಗಿ ಬೇರ್ಪಡುತ್ತವೆ: ಒಂದು ಸುರಂಗಕ್ಕೆ ಮೊದಲು ಸಂಭವಿಸಿತು, ಇನ್ನೊಂದು ಅದರ ಒಳಗೆ ಸಂಭವಿಸಿತು.
ಹಾಟ್‌ಸ್ಪಾಟ್ ಏನನ್ನು ಮುಟ್ಟಬಹುದು ಮತ್ತು ಏನನ್ನು ಮುಟ್ಟಲು ಸಾಧ್ಯವಿಲ್ಲ
ಪ್ರವೇಶ ನೆಟ್‌ವರ್ಕ್ DHCP ನಲ್ಲಿ ರಿಜಾಲ್ವರ್ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಆ ವಿಳಾಸದ ಕಡೆಗೆ ಪೋರ್ಟ್ 53 ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಬಹುದು. ಇದು ಪ್ರತಿ ಅಸುರಕ್ಷಿತ ಲುಕಪ್‌ಗೆ ಪೋರ್ಟಲ್ ವಿಳಾಸ ಅಥವಾ ಬ್ಲಾಕ್ ಪುಟದಿಂದ ಉತ್ತರಿಸಲು ಸಾಕು. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೋಸ್ಟ್‌ನಾಮ್ ಆಗಿ ಬರೆಯಲಾದ VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಡೆಯಲು ಸಹ ಸಾಕು.
ಹಾಟ್‌ಸ್ಪಾಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದ್ದು ಪ್ರಶ್ನೆಯನ್ನು ಓದುವುದು ಅಥವಾ ಮರುಬರೆಯುವುದು, ಅದು ಸ್ಥಾಪಿತ ಸುರಂಗದ ಒಳಗೆ ಚಲಿಸಿದ ನಂತರ, ಸುರಂಗ ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಒಯ್ಯುತ್ತದೆ ಎಂದು ಭಾವಿಸಿದರೆ. ಪ್ರತಿಬಂಧವು ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಪ್ರಶ್ನೆಯನ್ನು ನೋಡುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಪ್ರಶ್ನೆಗಳು ಹಾಟ್‌ಸ್ಪಾಟ್‌ಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣಗಳಿಂದ ಸುರಂಗವನ್ನು ಬಿಡುತ್ತವೆ: ಬ್ರೌಸರ್‌ನ ಸುರಕ್ಷಿತ DNS ಸೆಟ್ಟಿಂಗ್, ಕಾರ್ಪೊರೇಟ್ ಪ್ರತ್ಯಯವನ್ನು ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್‌ನಲ್ಲಿ ಇಡುವ split-DNS ನಿಯಮ, ಅಥವಾ DNS ಅನ್ನು ಸುರಂಗದಿಂದ ಹೊರಗಿಡಲು ಸಂರಚಿಸಲಾದ ಕ್ಲೈಂಟ್. ಪ್ರತಿಯೊಂದೂ ಕ್ಲೈಂಟ್ ಬದಿಯ ಆಯ್ಕೆ, ಮತ್ತು ಹೊರಗಿನಿಂದ ನೋಡಿದಾಗ ಪ್ರತಿಯೊಂದೂ ಹಾಟ್‌ಸ್ಪಾಟ್‌ನ ಹಸ್ತಕ್ಷೇಪದಂತೆ ಕಾಣುತ್ತದೆ.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
ಆರಂಭಿಕ ಲುಕಪ್ ಸುರಂಗ ಇರುವ ಮೊದಲೇ ಸಂಭವಿಸುತ್ತದೆ
ಹೋಸ್ಟ್‌ನಾಮ್ ಪಡೆದ ಕ್ಲೈಂಟ್ ಮೊದಲು ಅದನ್ನು ಪರಿಹರಿಸಬೇಕು, ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಯಾವುದೇ ಸುರಂಗ ಪ್ರಶ್ನೆಯನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಹಾಟ್‌ಸ್ಪಾಟ್ ಪೋರ್ಟಲ್ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸಿದರೆ, ಸಮಾಲೋಚನೆ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ನೇತಾಡುತ್ತದೆ. ಏನೂ ಉತ್ತರಿಸದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಹೆಸರಿನ ದೋಷವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ಎರಡೂ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಇಲ್ಲದಿದ್ದರೆ ನಿರ್ದೋಷವಾಗಿ ಕಾಣುವ ಖಾಲಿ ಸುರಂಗ ಲಾಗ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ತಮ್ಮದೇ ಸಂಪರ್ಕ ಪರಿಶೀಲನೆಗಳನ್ನು ಮತ್ತು ಪೋರ್ಟಲ್ ಪತ್ತೆಯನ್ನು ಸಹ ನಡೆಸುತ್ತವೆ, ಅವು RFC 8910 ಮತ್ತು RFC 8952 ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ, ಮತ್ತು ಆ ವಿನಂತಿಗಳು ಯಾವುದೇ VPN ಏರುವ ಮೊದಲೇ ಹೊರಡುತ್ತವೆ. ಅವನ್ನು ಪ್ರಾಕ್ಸಿ ಲಾಗ್‌ನಲ್ಲಿ ನೋಡುವುದು ಸೋರಿಕೆಯ ಸಾಕ್ಷ್ಯವಲ್ಲ, ನಿರೀಕ್ಷಿತ ವರ್ತನೆ.
ಪ್ರಾಯೋಗಿಕ ಪರಿಹಾರವೆಂದರೆ ಕ್ಲೈಂಟ್‌ಗೆ ಯಾವುದೇ ಲುಕಪ್ ಅಗತ್ಯವಿಲ್ಲದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ನೀಡುವುದು. ಅದು ಅಸಾಧ್ಯವಾದಾಗ, ಮೊದಲು ಸೈನ್ ಇನ್ ಮುಗಿಸಿ ನಂತರ ಸಂಪರ್ಕಿಸಿ.
ಯಾವ ರಿಜಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ
ಬ್ರೌಸರ್‌ಗಲ್ಲ, ಸಿಸ್ಟಮ್‌ಗೆ ಕೇಳಿ, ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಎರಡು ಬಾರಿ ಚಲಾಯಿಸಿ: ಒಮ್ಮೆ ಸಾಧನವು ಈಗ ಬಳಸುತ್ತಿರುವ ರಿಜಾಲ್ವರ್ ಮೂಲಕ, ಒಮ್ಮೆ ಸ್ಥಿರ ವಿಳಾಸದ ವಿರುದ್ಧ.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
ಮೊದಲ ಆದೇಶದ ಉತ್ತರ ಮೂರನೆಯದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದ್ದರೆ ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್ ಬೇರೆ ಏನನ್ನೋ ಹಿಂತಿರುಗಿಸುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮರುನಿರ್ದೇಶಿಸುವ ಹಾಟ್‌ಸ್ಪಾಟ್ ಹಾಗೆಯೇ ಮಾಡುತ್ತದೆ. ಮೂರನೆಯ ವೈಫಲ್ಯ ಮೊದಲನೆಯ ಯಶಸ್ಸಿನೊಂದಿಗೆ ಪೋರ್ಟಲ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ: ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್ ಸೈನ್-ಇನ್ ವಿಳಾಸವನ್ನು ನೀಡಿತು, ಆದರೆ ಹೊರಹೋಗುವ ಪೋರ್ಟ್ 53 ಬಿಟ್ಟುಬಿಡಲಾಗಿತ್ತು. ಎರಡರಲ್ಲೂ ಸಮಯ ಮೀರುವಿಕೆ ಎಂದರೆ ದೃಢೀಕರಣ ಮುಗಿಯುವವರೆಗೆ ನೆಟ್‌ವರ್ಕ್ DNS ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ.
ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಹೋಲಿಸಿ. ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರ ಪರಿವರ್ತನೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡಿ ಅಥವಾ ಎರಡನೇ ಅವಲೋಕನಕ್ಕಾಗಿ ಹೊಸ ಹೆಸರನ್ನು ಕೇಳಿ.
ನಂತರದ ಲುಕಪ್‌ಗಳನ್ನು ನೀವು ಉದ್ದೇಶಿಸಿದ ಮಾರ್ಗದಲ್ಲೇ ಇರಿಸಿ
DNS ಅನ್ನು ಸಹ ಸೆರೆಹಿಡಿಯುವ ಪೂರ್ಣ ಸುರಂಗ ಪ್ರೊಫೈಲ್ ಸರಳವಾದ ವ್ಯವಸ್ಥೆ: ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರತಿ ಪ್ರಶ್ನೆ ಸುರಂಗ ತಳ್ಳುವ ರಿಜಾಲ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಸಂಚಾರವನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಆಂತರಿಕ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ, ನಂತರ ಎರಡೂ ಉತ್ತರಗಳನ್ನು ಸುರಂಗ ರಿಜಾಲ್ವರ್ ಒಂಟಿಯಾಗಿ ಹಿಂತಿರುಗಿಸುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ.
Split-DNS ಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬರೆದ ಡೊಮೇನ್ ಪಟ್ಟಿ ಬೇಕು: ಕಾರ್ಪೊರೇಟ್ ಪ್ರತ್ಯಯಗಳು ಸುರಂಗದ ಮೂಲಕ, ಉಳಿದೆಲ್ಲವೂ ಸ್ಥಳೀಯವಾಗಿ, ಮತ್ತು ಎರಡರ ನಡುವೆ ಯಾವುದೇ ಓವರ್‌ಲ್ಯಾಪ್ ಇಲ್ಲ.
ಬ್ರೌಸರ್‌ನ ಸುರಕ್ಷಿತ DNS ಆ ನೀತಿಯ ಹೊರಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಊಹಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ವರ್ತಿಸಲು ಅದು ಆಫ್ ಆಗಬೇಕಿದ್ದರೆ, ಯಂತ್ರಕ್ಕಲ್ಲ, ಆ ಪ್ರೊಫೈಲ್‌ಗೆ ಆಫ್ ಮಾಡಿ. ಅದನ್ನು ಸಿಸ್ಟಮ್ ರಿಜಾಲ್ವರ್ ಸಂಪಾದಿಸುವ ಮೂಲಕವಲ್ಲ, ಬ್ರೌಸರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಮಾಡಿ, ಇದರಿಂದ ಬದಲಾವಣೆ ಮುಂದಿನ ಬಾರಿ ಕಾಣುತ್ತದೆ. ಪ್ರತಿ ಪರೀಕ್ಷೆಗೆ ಒಂದು ಸಾಲಿನಲ್ಲಿ ಉತ್ತರ, ರಿಜಾಲ್ವರ್ ಮತ್ತು ಸಂಪರ್ಕ ಹಂತವನ್ನು ದಾಖಲಿಸಿ. ಹೋಟೆಲ್ Wi-Fi ನಲ್ಲಿ DNS ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುವ ವರದಿ ಕನಿಷ್ಠ ಮೂರು ವಿಭಿನ್ನ ಕಾರಣಗಳಿರುವ ಲಕ್ಷಣವನ್ನು ವಿವರಿಸುತ್ತದೆ.