Split-DNS ಕ್ಯಾಪ್ಚರ್: ಪ್ರತಿ ವೀಕ್ಷಣೆ ಎಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಎಂದು ಹೇಳಿ

ಇಬ್ಬರು ಜನರು ಒಂದೇ Split-DNS ಸಮಸ್ಯೆಯನ್ನು ಪರಿಶೀಲಿಸಿ ಬೇರೆ ಬೇರೆ resolver ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ. ಒಬ್ಬರು ಹುಡುಕಾಟ ಉಪಕರಣ ಬಳಸಿದರು, ಇನ್ನೊಬ್ಬರು ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸೆರೆಹಿಡಿದರು, ಮೂರನೆಯವರು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ರೋಗನಿರ್ಣಯವನ್ನು ಓದಿದರು. ಅವರಲ್ಲಿ ಯಾರೂ ಸುಳ್ಳು ಹೇಳುತ್ತಿಲ್ಲ, ಮತ್ತು ಯಾರೂ ಒಂದೇ ಹಂತವನ್ನು ವಿವರಿಸುತ್ತಿಲ್ಲ. ವೀಕ್ಷಣಾ ಬಿಂದುವನ್ನು ಹೆಸರಿಸುವುದು ವಿರೋಧಾಭಾಸವನ್ನು ನಕ್ಷೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.

ಒಂದು ಹುಡುಕಾಟ, ಹಲವು ವೀಕ್ಷಣಾ ಬಿಂದುಗಳು

ಒಂದು ಆಂತರಿಕ ಹೆಸರಿಗೆ ನೋಡಲು ಕನಿಷ್ಠ ಐದು ಸ್ಥಳಗಳಿವೆ: ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದು ಕರೆಯುವ resolver API, ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಜಾರಿಯಲ್ಲಿರುವ ಡೊಮೇನ್ ನೀತಿ, ಅಡಾಪ್ಟರ್ ಅಥವಾ ಫಿಲ್ಟರ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ, ನಿಯಂತ್ರಿತ ಗೇಟ್‌ವೇ ಗಡಿ, ಮತ್ತು ಕ್ವೆರಿಯನ್ನು ನಿಜವಾಗಿ ಸ್ವೀಕರಿಸುವ resolver.

ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೂ ಒಂಟಿಯಾಗಿ ಕ್ವೆರಿ ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

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

ಕ್ಲೈಂಟ್‌ನ ಫಿಲ್ಟರ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ತಂತಿಯ ನಡುವೆ ಇರುತ್ತದೆ

Split-DNS ಇರುವ VPN ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್ ಯಂತ್ರದಿಂದ ಹೊರಡುವ ಮೊದಲು ಡೊಮೇನ್ ಹೊಂದಾಣಿಕೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಟನೆಲ್ ಸಫಿಕ್ಸ್‌ನಲ್ಲಿರುವ ಹೆಸರುಗಳು ಆಂತರಿಕ resolver ಗೆ ಹೋಗುತ್ತವೆ; ಉಳಿದ ಎಲ್ಲವೂ ಸ್ಥಳೀಯ resolver ಗೆ ಹೋಗುತ್ತದೆ. ಫಿಲ್ಟರ್ ನೀತಿ, ಮತ್ತು ನೀತಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಯಿಂದ ಬದಲಾಗಬಹುದು.

Cisco ನ Secure Client Split-DNS ಮಾರ್ಗದರ್ಶನ ಡೊಮೇನ್ ಹೊಂದಾಣಿಕೆ ಮತ್ತು Windows ಫಿಲ್ಟರ್ ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳೀಯ resolver API ಬಳಸುವಾಗ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು nslookup ನಂತಹ ಉಪಕರಣ ನೋಡುವುದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸಗಳೇ ಮುಖ್ಯ ವಿಷಯ.

ಜಾರಿಯಲ್ಲಿರುವ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಒಂದು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಹುಡುಕಾಟದಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಸ್ಪಷ್ಟ ಸರ್ವರ್ ಅನ್ನು ಹೆಸರಿಸುವ ಯಾವುದೇ ಪರೀಕ್ಷೆ ಉದ್ದೇಶಪೂರ್ವಕವಾದ ಬಳಸುದಾರಿ; ಅದನ್ನು ವಿವರಿಸಲು ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ರೋಗನಿರ್ಣಯವನ್ನು ಬಳಸಿ, ಮತ್ತು ಅದು ಸ್ವೀಕಾರ ಮಾನದಂಡವಾಗಲು ಬಿಡಬೇಡಿ.

nslookup ಅಪ್ಲಿಕೇಶನ್‌ಗಿಂತ ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ

nslookup ತನ್ನದೇ DNS ಕ್ವೆರಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ resolver ನೀತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ಇದು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ಗೆ ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆ ಕೇಳಲು ಉಪಯುಕ್ತ ಉಪಕರಣವಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಏನನ್ನು ಅನುಭವಿಸುತ್ತದೆ ಎಂದು ಪರೀಕ್ಷಿಸಲು ದಾರಿತಪ್ಪಿಸುವ ಉಪಕರಣವಾಗಿಸುತ್ತದೆ.

Windows ನಲ್ಲಿ ಹೆಸರು ಪರಿಹಾರ ನೀತಿ ಕೋಷ್ಟಕ ಯಾವ ಸಫಿಕ್ಸ್ ಯಾವ ಸರ್ವರ್ ಬಳಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದನ್ನು ಓದುವುದು ಅಪ್ಲಿಕೇಶನ್ ಅನುಸರಿಸುವ ನೀತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಅದೇ ಕಾಣೆಯಾದ ತುಣುಕು.

ನೀತಿಯನ್ನು ಓದಿ ನಂತರ ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಸಾಮಾನ್ಯ resolver ಮೂಲಕ ಕೇಳಿ:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ resolver ಕ್ವೆರಿಯನ್ನು ಮರೆಮಾಡುತ್ತವೆ, ಸಂಪರ್ಕವನ್ನಲ್ಲ

ತನ್ನದೇ DNS-over-HTTPS resolver ಇರುವ ಬ್ರೌಸರ್ ಸಂಪೂರ್ಣ ಬೇರೆ ಪ್ರಕರಣ. ಕ್ವೆರಿ TLS ಒಳಗೆ ಹೊರಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ resolver ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕ ತೋರಿಸುತ್ತದೆ ಆದರೆ ಕೇಳಿದ ಹೆಸರನ್ನು ತೋರಿಸುವುದಿಲ್ಲ.

ಮೊದಲು ಬ್ರೌಸರ್‌ನ ನಿರ್ವಹಿತ ನೀತಿಯನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ, ನಂತರ ಅದನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಹುಡುಕಾಟದೊಂದಿಗೆ ಹೋಲಿಸಿ. ತನ್ನದೇ resolver ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿ ಇರುವ ಬ್ರೌಸರ್ Split-DNS ನೀತಿಯನ್ನು ಎಂದಿಗೂ ನೋಡದೇ ಇರಬಹುದು.

ಅದೇ ಎಚ್ಚರಿಕೆ ತನ್ನದೇ resolver ತರುವ ಯಾವುದೇ ಕ್ಲೈಂಟ್‌ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ದೂರದ ಸಂಪರ್ಕವನ್ನು ಗುರುತಿಸುವ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಕ್ವೆರಿ ಹೆಸರಿನ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಹೆಸರು ಬೇಕಾದರೆ, ಅದನ್ನು resolver ನ ಸ್ವಂತ ಲಾಗ್‌ಗಳಿಂದ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ರೋಗನಿರ್ಣಯದಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ, ಅನ್ವಯವಾಗುವ ಗೋಪ್ಯತಾ ನಿಯಮಗಳೊಂದಿಗೆ.

ಲೇಬಲ್ ಮಾಡಿದ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ

ಪರೀಕ್ಷೆಗಾಗಿ ಅನುಮೋದಿತ ಆಂತರಿಕ ಹೆಸರು, ಜೊತೆಗೆ ಸೂಕ್ಷ್ಮ ಅರ್ಥವಿಲ್ಲದ ಸಾರ್ವಜನಿಕ ಹೆಸರು ಆಯ್ಕೆ ಮಾಡಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಮಯ, ದಾಖಲೆ ಪ್ರಕಾರ, ಉತ್ತರ ಮತ್ತು ನಿರೀಕ್ಷಿತ ನೀತಿಯನ್ನು ದಾಖಲಿಸಿ.

ಅನುಮತಿ ಇರುವಲ್ಲಿ, resolver ನ ಸ್ವೀಕೃತಿಯನ್ನು ಒಂದು ಸಂಕುಚಿತ ಕ್ಲೈಂಟ್ ಅಥವಾ ಗೇಟ್‌ವೇ ವೀಕ್ಷಣೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

ಕೇವಲ ಹೋಲಿಕೆ ಮಾಡಲು ಖಾಸಗಿ ಹೆಸರುಗಳನ್ನು ಸಂಬಂಧವಿಲ್ಲದ ಸಾರ್ವಜನಿಕ resolver ಗೆ ಎಂದಿಗೂ ಕಳುಹಿಸಬೇಡಿ, ಮತ್ತು ನೀವು ಹಂಚಿಕೊಳ್ಳುವ ಎಲ್ಲವನ್ನೂ ಸಂಪಾದಿಸಿ. ಕೊನೆಯದಾಗಿ, ಸರಿಯಾದ DNS ಉತ್ತರವನ್ನು ಅದರ ನಂತರ ಬರುವ ಸೇವಾ ಸಂಪರ್ಕದಿಂದ ಬೇರ್ಪಡಿಸಿ: ಪರಿಹರಿಸಲಾದ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಇನ್ನೂ ಮಾರ್ಗ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿ ಬೇಕು.