ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪುಟ ತೆರೆಯಿರಿ ಮತ್ತು ಮೂರು DNS ವಿಳಾಸಗಳು ಪಟ್ಟಿಯಾಗಿರುತ್ತವೆ; ಆಡಿಟ್ ಪ್ರಶ್ನೆ ಎಂದರೆ ನಿಮ್ಮ ಕೊನೆಯ ಪ್ರಶ್ನೆಯನ್ನು ಯಾವುದು ನಿರ್ವಹಿಸಿತು. ಕೇವಲ ಸಂಖ್ಯೆ ಯಾವುದಕ್ಕೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಪುಶ್, ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಪ್ರತಿ-ಡೊಮೇನ್ ನೀತಿ ಎಲ್ಲವೂ ಒಂದೇ ನೋಟದಲ್ಲಿ ಬರೆಯುತ್ತವೆ. ಈ ನಮೂದುಗಳು ಬೇರೆ ಬೇರೆ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಸ್ಥಾನವಲ್ಲ, ವ್ಯಾಪ್ತಿಯೇ ನಿರ್ಧರಿಸುತ್ತದೆ. ಮೂಲಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ನಿಮಗೆ ಮುಖ್ಯವಾದ ಹೆಸರನ್ನು ಹೊಂದಿರುವ ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಪಟ್ಟಿ ನಿಮ್ಮ ಪ್ರೊಫೈಲ್‌ಗಿಂತ ಉದ್ದವಾಗಿರುವುದೇಕೆ

VPN ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಲಿಂಕ್‌ಗಾಗಿ ರಿಜಾಲ್ವರ್ ವಿಳಾಸಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅವುಗಳನ್ನು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಈಗಾಗಲೇ ಹೊಂದಿದ್ದುದರ ಪಕ್ಕದಲ್ಲಿ ಇಡುತ್ತದೆ. ರೌಟರ್, ಕಾರ್ಪೊರೇಟ್ DHCP ಲೀಸ್, ಎರಡನೇ VPN ಮತ್ತು ಪ್ರತಿ-ಡೊಮೇನ್ ನೀತಿ ಪ್ರತಿಯೊಂದೂ ತಮ್ಮದೇ ನಮೂದನ್ನು ಸೇರಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ ಪುಟದಲ್ಲಿನ ಮೂರು ವಿಳಾಸಗಳು ಒಂದು ಕೆಲಸಕ್ಕೆ ಮೂರು ಅಭ್ಯರ್ಥಿಗಳಲ್ಲ, ಮೂರು ವ್ಯಾಪ್ತಿಗಳನ್ನು ಅರ್ಥೈಸಬಹುದು. ಸಂಖ್ಯೆಯನ್ನು ಸೋರಿಕೆಯ ಸಾಕ್ಷ್ಯವಾಗಿ ಓದುವುದು ಈ ಆಡಿಟ್‌ನ ಮೊದಲ ತಪ್ಪು.

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

ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ DNS ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಳಗಿನಿಂದ ಚಿತ್ರವನ್ನು ಮುರಿಯುತ್ತದೆ. ತನ್ನದೇ DNS-over-HTTPS ರಿಜಾಲ್ವರ್ ಹೊಂದಿರುವ ಬ್ರೌಸರ್ ಅಥವಾ ಚಾಟ್ ಕ್ಲೈಂಟ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಪಟ್ಟಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸದೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪುಟದ ವಿಳಾಸಗಳು ಅಪ್ಲಿಕೇಶನ್ ಎಂದೂ ಉತ್ಪಾದಿಸದ ಸಂಚಾರವನ್ನು ವಿವರಿಸುತ್ತವೆ. ಹೆಸರು ತಪ್ಪಾಗಿ ಬಂದಿದ್ದಕ್ಕೆ ಪ್ರೊಫೈಲ್‌ಗೆ ದೂಷಿಸುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ರಿಜಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ.

ಮೂರು ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಏನು ಹೇಳುತ್ತದೆ

ಪ್ರತಿ ಮೂಲ ತನ್ನ ಗುರುತನ್ನು ಬೇರೆ ಸ್ಥಳದಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಒಂದು ಆಜ್ಞೆ ಎಲ್ಲವನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪುಟದ ಪಕ್ಕದಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಲು ಯೋಗ್ಯವಾದ ಮ್ಯಾಪಿಂಗ್ ಇದು:

Entry sourceWhere it is visibleWhat it proves
Tunnel profileLink-scoped DNS on the tunnel deviceWhich servers the VPN asked you to use, not which one answered
Per-domain policySuffix list or routing domainsWhich names are steered to a particular resolver
Physical linkDNS on the LAN interfaceWhether a second scope still exists outside the tunnel
Application resolverApp settings, absent from the OS listWhether the system list was consulted at all

systemd-resolved ಬಳಸುವ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ resolvectl status ಅಧಿಕೃತವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ರೌಟಿಂಗ್ ಡೊಮೇನ್‌ಗಳೊಂದಿಗೆ ಪ್ರತಿ-ಲಿಂಕ್ DNS ವರದಿ ಮಾಡುತ್ತದೆ. macOS scutil --dns ಮೂಲಕ ಉತ್ತರಿಸುತ್ತದೆ, ಅದು ವ್ಯಾಪ್ತಿಯ ರಿಜಾಲ್ವರ್‌ಗಳನ್ನು ಪ್ರಯತ್ನದ ಕ್ರಮದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. Windows ಎರಡು ಅರ್ಧಗಳಾಗಿ ಒಡೆಯುತ್ತದೆ: ಪ್ರತಿ-ಇಂಟರ್ಫೇಸ್ ಸರ್ವರ್‌ಗಳಿಗೆ Get-DnsClientServerAddress ಮತ್ತು ಸಫಿಕ್ಸ್ ನಿಯಮಗಳಿಗೆ Get-DnsClientNrptPolicy. ನಿಜವಾಗಿ ಬಳಕೆಯಲ್ಲಿರುವ ರಿಜಾಲ್ವರ್‌ಗೆ ಸೇರಿದ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್ ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್ ರಿಜಾಲ್ವರ್ ಇರುವ ಯಂತ್ರದಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸ್ಥಾಪಿತವಾಗಿರಬಹುದು.

ನಿಮ್ಮ ವಲಯಕ್ಕೆ ಉತ್ತರಿಸಲಾಗದ ಬ್ಯಾಕಪ್ ರಿಜಾಲ್ವರ್

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

Split DNS ಅದನ್ನು ತಡೆಯಲು ಇದೆ: ಕಂಪನಿ ಸಫಿಕ್ಸ್‌ಗಳು ವಲಯವನ್ನು ಹೊಂದಿರುವ ರಿಜಾಲ್ವರ್‌ಗೆ ಹೋಗುತ್ತವೆ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ಉಳಿಯುತ್ತವೆ. ವಿನ್ಯಾಸವು ಗಟ್ಟಿಯಾಗಿದೆ, ಮತ್ತು ಅದು ಸಫಿಕ್ಸ್ ಪಟ್ಟಿ ಪೂರ್ಣವಾಗಿರುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ. Microsoft ಪ್ರತಿ-ಸಫಿಕ್ಸ್ ರಿಜಾಲ್ವರ್ ನೀತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಅದು Windows ನಲ್ಲಿ ಇದನ್ನು ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಕಲ್ಪನೆ systemd-resolved ನಲ್ಲಿ ರೌಟಿಂಗ್ ಡೊಮೇನ್‌ಗಳಾಗಿ ಮತ್ತು macOS ನಲ್ಲಿ ವ್ಯಾಪ್ತಿಯ ರಿಜಾಲ್ವರ್‌ಗಳಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಬ್ಯಾಕಪ್ ಉತ್ತರಿಸಬಹುದಾದ ವಲಯಗಳನ್ನು ನೀತಿಯಲ್ಲಿರುವ ಸಫಿಕ್ಸ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಆ ಹೋಲಿಕೆ ಬಳಕೆದಾರರು ಟನೆಲ್ ಬದಲಾವಣೆಯ ನಂತರ ಒಂದು ಆಂತರಿಕ ಸೈಟ್ ಪರಿಹರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು ಎಂದು ವರದಿ ಮಾಡುವ ಮೊದಲೇ ಅಂತರವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.

ನೀತಿಯ ಮೂಲಕ ಕೇಳಿ, ಅದನ್ನು ಬಳಸದೆ ಅಲ್ಲ

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

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

ಸಿಸ್ಟಮ್ ಪ್ರಶ್ನೆ ಖಾಸಗಿ ವಿಳಾಸ ಹಿಂತಿರುಗಿಸಿದರೆ ಮತ್ತು ನೇರ ಪ್ರಶ್ನೆ NXDOMAIN ಹಿಂತಿರುಗಿಸಿದರೆ, ನೀತಿ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಬ್ಯಾಕಪ್ ದುರ್ಬಲ ಸ್ಥಾನ. ಎರಡೂ ಒಂದೇ ಸಾರ್ವಜನಿಕ ಉತ್ತರ ಹಿಂತಿರುಗಿಸಿದರೆ, ಹೆಸರು ನೀವು ಉದ್ದೇಶಿಸಿದ ವ್ಯಾಪ್ತಿಯ ಹೊರಗೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತಿದೆ, ಮತ್ತು ಸಫಿಕ್ಸ್ ಪಟ್ಟಿ ನೋಡಬೇಕಾದ ಸ್ಥಳ. ಎರಡೂ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಇರಿಸಿ, ಏಕೆಂದರೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪುಟದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಿಂತ ಎರಡು ಸಾಲುಗಳಿಂದ ರಿಜಾಲ್ವರ್ ಚರ್ಚೆ ಬೇಗ ಮುಗಿಯುತ್ತದೆ.

ನಂತರ ವಿಫಲತೆಯ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ, ಏಕೆಂದರೆ ಯಾರೂ ಪರೀಕ್ಷಿಸದ ಫಾಲ್‌ಬ್ಯಾಕ್ ಒಂದು ಊಹೆ. ಒಂದು ಪ್ರಶ್ನೆಗೆ ಆದ್ಯತೆಯ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಕಪ್ಪು ಕುಳಿಯಾಗಿ ಮಾಡಿ ಮತ್ತು ಯಾವ ವಿಳಾಸ ಹಿಂತಿರುಗುತ್ತದೆ ಎಂದು ನೋಡಿ:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

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

ನಿರ್ಧರಿಸಿ: ಇರಿಸಿಕೊಳ್ಳಿ, ಮಿತಿಗೊಳಿಸಿ ಅಥವಾ ತೆಗೆದುಹಾಕಿ

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

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು