DNS ರಿಸಾಲ್ವರ್ ಲಾಗ್‌ಗಳು ಮತ್ತು VPN ಸಂಪರ್ಕ ಲಾಗ್‌ಗಳು: ಪ್ರತಿಯೊಂದರಲ್ಲಿ ಏನಿರುತ್ತದೆ
ರಿಸಾಲ್ವರ್ ತನಗೆ ಉತ್ತರಿಸಲು ಕೇಳಿದ ಹೆಸರುಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ; VPN ತನ್ನದೇ ಅನುಷ್ಠಾನದಿಂದ ಸುರಂಗದ ಘಟನೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಒಂದು ಧಾರಣಾ ನೀತಿ ಇನ್ನೊಂದನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.
DNS ರಿಸಾಲ್ವರ್ ಲಾಗ್ ಮತ್ತು VPN ಸಂಪರ್ಕ ಲಾಗ್ ಎರಡೂ ಜಾಲ ದಾಖಲೆಗಳು, ಎರಡೂ ಉಪಯುಕ್ತ ಮತ್ತು ಒಂದಕ್ಕೊಂದು ಬದಲಿಯಲ್ಲ. ರಿಸಾಲ್ವರ್ ತನಗೆ ಉತ್ತರಿಸಲು ಕೇಳಿದ ಹೆಸರುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. VPN ಅಂತ್ಯಬಿಂದು ಸುರಂಗ ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಅನುಷ್ಠಾನವು ಅವುಗಳ ಬಗ್ಗೆ ದಾಖಲಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದ್ದನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅವು ಒಂದೇ ಕಟ್ಟಡದಲ್ಲಿರಬಹುದು, ಒಂದೇ ತಂಡ ನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ಒಂದೇ ಗೋಪ್ಯತಾ ಸೂಚನೆಯ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರಬಹುದು, ಆದರೂ ವಿಭಿನ್ನ ಗುರುತಿಸುವಿಕೆಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಧಾರಣೆಯೊಂದಿಗೆ ವಿಭಿನ್ನ ಘಟನೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಒಂದನ್ನು ಇನ್ನೊಂದು ಎಂಬಂತೆ ಓದುವುದೇ ತನಿಖೆಗಳು ದಾರಿತಪ್ಪುವ ರೀತಿ.
ಎರಡು ಲಾಗ್‌ಗಳು, ಎರಡು ಘಟನೆಗಳು
ರಿಸಾಲ್ವರ್‌ನ ಒಂದು ನಮೂದು ಹೆಸರಿಸುವಿಕೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಕ್ಲೈಂಟ್ ಈ ಸಮಯದಲ್ಲಿ ಈ ಹೆಸರನ್ನು ಕೇಳಿತು, ಮತ್ತು ಉತ್ತರ ಇದಾಗಿತ್ತು. VPNನ ಒಂದು ನಮೂದು ಸಂಪರ್ಕತೆಯ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಪೀರ್ ಸುರಂಗವನ್ನು ಸ್ಥಾಪಿಸಿತು ಅಥವಾ ಕಳೆದುಕೊಂಡಿತು, ಅದಕ್ಕೆ ಈ ವಿಳಾಸ ನೀಡಲಾಯಿತು, ಮತ್ತು ಹೋಗುವ ಮೊದಲು ಸುಮಾರು ಇಷ್ಟು ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಿತು. ಎರಡೂ HTTPS ಅವಧಿಯ ಒಳಗೆ ಬಳಕೆದಾರರು ಏನು ಮಾಡಿದರು ಎಂಬ ದಾಖಲೆ ಅಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ಇನ್ನೊಂದರ ಜಾಗ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.
ಈ ವ್ಯತ್ಯಾಸವು ಭರವಸೆಗಳಿಗೆ ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವನ್ನು ಹೊಂದಿದೆ. VPN ಪೂರೈಕೆದಾರರು ಸುರಂಗ ಚಟುವಟಿಕೆಯನ್ನು ದಾಖಲಿಸುವುದಿಲ್ಲ ಎಂಬ ಹೇಳಿಕೆ ಅದು ನೀಡುವ ರಿಸಾಲ್ವರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ರಿಸಾಲ್ವರ್‌ನ ಧಾರಣಾ ನೀತಿ ಸುರಂಗಕ್ಕೆ ಯಾರು ಸಂಪರ್ಕಿಸಿದರು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪ್ರತಿ ಹೇಳಿಕೆಯೂ ತನ್ನದೇ ನಿರ್ವಾಹಕ ಮತ್ತು ತನ್ನದೇ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿದೆ.
ಯಾವುದೇ ಲಾಗ್ ಓದುವ ಮೊದಲು ಪ್ರಶ್ನೆಯನ್ನು ಅನುಸರಿಸಿ
ಪ್ರಶ್ನೆಯು ರಿಸಾಲ್ವರ್‌ಗೆ ತಲುಪುವುದು ಮಾರ್ಗವು ನಿಜವಾಗಿ ಅದನ್ನು ಕೇಳಿದರೆ ಮಾತ್ರ. ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯ ರಿಸಾಲ್ವರ್ ಬಳಸಬಹುದು, ತನ್ನದೇ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ DNS ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸಬಹುದು, ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರವನ್ನು ಓದಿ ಏನನ್ನೂ ಕಳುಹಿಸದಿರಬಹುದು. ಆದ್ದರಿಂದ ಏನನ್ನೂ ತೋರಿಸದ ರಿಸಾಲ್ವರ್ ಲಾಗ್ ಹೆಸರನ್ನು ಎಂದೂ ಬಳಸಲಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ; ಅದು ಈ ರಿಸಾಲ್ವರ್‌ಗೆ ಕೇಳಲಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯ.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerಕೊನೆಯ ಆಜ್ಞೆ ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್‌ನ ಸ್ವಂತ ಜರ್ನಲ್ ಓದುತ್ತದೆ, ಅದು ಮೇಲ್ಮುಖ ಸರ್ವರ್‌ನ ಲಾಗ್‌ನಂತೆಯೇ ಅಲ್ಲ. ನಿಮ್ಮ ಪ್ರಶ್ನೆಗಳು DNS over HTTPS ಮೂಲಕ ಪೂರೈಕೆದಾರರಿಗೆ ಹೋದರೆ, ಸ್ಥಳೀಯ ಸ್ಟಬ್ ಏನನ್ನೂ ತೋರಿಸದಿರಬಹುದು ಆದರೆ ಪೂರೈಕೆದಾರರ ಬಳಿ ಪೂರ್ಣ ದಾಖಲೆ ಇರುತ್ತದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಬೇರೆ ನೀತಿ ಹೊಂದಿರುವ ಬೇರೆ ನಿರ್ವಾಹಕರು.
ಪ್ರತಿ ದಾಖಲೆ ಏನನ್ನು ತೋರಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ತೋರಿಸಲಾರದು
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
ಅವುಗಳನ್ನು ಜೋಡಿಸುವುದೇ ನಿಜವಾದ ಕೆಲಸ, ಮತ್ತು ಜೋಡಿಸುವುದು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಿಲ್ಲ. ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ದಾಖಲಿಸುವ ರಿಸಾಲ್ವರ್ ಅನ್ನು ತಿಳಿದಿರುವ ಪೂಲ್‌ನಿಂದ ವಿಳಾಸ ನೀಡುವ VPN ಜೊತೆ ಹೋಲಿಸಬಹುದು, ಮತ್ತು ಆ ಹೋಲಿಕೆ ಪ್ರಶ್ನಿಸಿದ ಹೆಸರು ಮತ್ತು ಸುರಂಗದ ನಡುವೆ ನಂಬಲರ್ಹ ಕೊಂಡಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಅದು ಎರಡು ದಾಖಲೆಗಳ ನಡುವಿನ ಕೊಂಡಿಯಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ, ವ್ಯಕ್ತಿಯ ದಾಖಲೆಯಲ್ಲ.
ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ DNS ಸಾಗಣೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ, ಅಂತ್ಯಬಿಂದುವಿನಲ್ಲಿ ಗೋಚರತೆಯನ್ನು ಅಲ್ಲ. ರಿಸಾಲ್ವರ್ ತಾನು ಉತ್ತರಿಸುವ ಪ್ರಶ್ನೆಯನ್ನು ಇನ್ನೂ ಸ್ವೀಕರಿಸುತ್ತದೆ, RFC 8484 ಸ್ಪಷ್ಟಪಡಿಸಿದಂತೆ, ಮತ್ತು ಆ ರಿಸಾಲ್ವರ್‌ನಲ್ಲಿ ಧಾರಣೆ ಪ್ರೋಟೋಕಾಲ್‌ನ ಗುಣವಲ್ಲ, ನೀತಿಯ ನಿರ್ಣಯ.
ವಿಭಜಿತ DNS ಮತ್ತು ಕ್ಯಾಶ್‌ಗಳು ಕಥೆಯನ್ನು ಎಲ್ಲಿ ಗೊಂದಲಗೊಳಿಸುತ್ತವೆ
ಹಲವು ರಿಸಾಲ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯ. ವಿಭಜಿತ DNS ವಿನ್ಯಾಸವು ಆಂತರಿಕ ಹೆಸರುಗಳನ್ನು ಆಂತರಿಕ ಸರ್ವರ್‌ಗೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವನ್ನು ಸಾರ್ವಜನಿಕ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದೇ ತನಿಖೆಯು ಎಂದೂ ಸಂಯೋಜಿಸಲು ಉದ್ದೇಶಿಸದ ಎರಡು ಲಾಗ್‌ಗಳನ್ನು ಮತ್ತು ಎಂದೂ ಹೋಲಿಸಲು ಉದ್ದೇಶಿಸದ ಎರಡು ಧಾರಣಾ ಸಂಯೋಜನೆಗಳನ್ನು ಒಳಗೊಳ್ಳಬಹುದು. ಎರಡರಲ್ಲೂ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾಣುವುದು ವಿನ್ಯಾಸ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯ, ಸೋರಿಕೆಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಕ್ಯಾಶ್‌ಗಳು ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಕತ್ತರಿಸುತ್ತವೆ. ಜನಪ್ರಿಯ ಹೆಸರಿಗೆ ಗಂಟೆಗಟ್ಟಲೆ ಕ್ಯಾಶ್‌ನಿಂದ ಉತ್ತರ ನೀಡಬಹುದು, ಆದ್ದರಿಂದ ರಿಸಾಲ್ವರ್‌ನ ದಾಖಲೆ ಮೊದಲ ಪ್ರಶ್ನೆಯನ್ನು ತೋರಿಸಿ ನಂತರ ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಬಳಕೆದಾರರ ಅಪ್ಲಿಕೇಶನ್ ಅದೇ ಹೆಸರನ್ನು ಸಂತೋಷದಿಂದ ಪರಿಹರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಸಮಯದ ನಂತರ ನಮೂದುಗಳಿಲ್ಲದಿರುವುದು ಆ ಸಮಯದ ನಂತರ ಯಾರೂ ಹೆಸರನ್ನು ಬಳಸಲಿಲ್ಲ ಎಂದರ್ಥವಲ್ಲ.
ಹಿನ್ನೆಲೆ ಸಂಚಾರವು ಮೂರನೇ ವಿಕೃತಿ. ಬೂಟ್‌ನಲ್ಲಿ ಟೆಲಿಮೆಟ್ರಿ ಹೆಸರನ್ನು ಪರಿಹರಿಸುವ ಫೋನ್, ಹುಡುಕಾಟ ಸೂಚನೆ ಡೊಮೇನ್ ಪರಿಹರಿಸುವ ಬ್ರೌಸರ್, ಮತ್ತು ಪ್ರತಿ ಗಂಟೆಗೆ ಸಂಪರ್ಕಿಸುವ ನವೀಕರಣಕಾರ—ಎಲ್ಲವೂ ರಿಸಾಲ್ವರ್ ಲಾಗ್‌ನಲ್ಲಿ ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಹೆಸರಿನ ಪಕ್ಕದಲ್ಲಿ ಕಾಣಿಸುತ್ತವೆ. ಆ ಲಾಗ್‌ನಲ್ಲಿನ ಪ್ರಮಾಣ ಗಮನವಲ್ಲ, ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಎಣಿಸುವುದು ಭೇಟಿಗಳನ್ನು ಎಣಿಸುವುದಲ್ಲ. ರಿಸಾಲ್ವರ್ ಲಾಗ್ ಪ್ರಶ್ನೆಗಳ ದಾಖಲೆ, ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ಸೃಷ್ಟಿಸುವುದು ಅಗ್ಗ.
ಧಾರಣೆಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಕೇಳಿ
ಪ್ರತಿ ವ್ಯವಸ್ಥೆಗೆ ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ: ಯಾರು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ, ಏನು ಸಂಗ್ರಹವಾಗುತ್ತದೆ, ಮತ್ತು ಎಷ್ಟು ಕಾಲ ಅದನ್ನು ಇಡಲಾಗುತ್ತದೆ. ನಂತರ ಅದನ್ನು ಯಾರು ಓದಬಹುದು ಮತ್ತು ಯಾವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಎಂದು ಕೇಳಿ. DNS over HTTPS ಬಗ್ಗೆ RFC 8484ನ ಚರ್ಚೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸಾಗಣೆ ಅಂತ್ಯಬಿಂದುವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ನೆನಪಿಸುತ್ತದೆ, ಮತ್ತು ನಿರ್ವಾಹಕರ ಸ್ವಂತ ದಾಖಲೆಗಳೇ ಆ ಅಂತ್ಯಬಿಂದು ಏನನ್ನು ಇಡುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏಕೈಕ ನಂಬಲರ್ಹ ಹೇಳಿಕೆ.
ಗೋಪ್ಯತೆಯ ಬಗ್ಗೆ “VPN” ಕುರಿತು ಹೇಳಿಕೆ ನೀಡಿದಾಗ, ಅದನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಘಟಕಗಳಾಗಿ ವಿಭಜಿಸಿ: ಸುರಂಗದ ನಿರ್ವಾಹಕ, ಸುರಂಗ ನೀಡುವ ರಿಸಾಲ್ವರ್, ಆ ಪ್ರಶ್ನೆಗಳು ತಲುಪುವ ಯಾವುದೇ ಮೇಲ್ಮುಖ ರಿಸಾಲ್ವರ್, ಮತ್ತು ಸಾಧನದಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಉತ್ತರವಿದೆ, ಮತ್ತು ಒಂದಕ್ಕೆ ಸರಿಯಾದ ಹೇಳಿಕೆಯನ್ನು ನಾಲ್ಕನ್ನೂ ಆವರಿಸುವಂತೆ ನಿಯಮಿತವಾಗಿ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ.
ಸಮಸ್ಯೆ ನಿವಾರಣೆಗೆ ಅದೇ ವಿಭಜನೆ ಬಳಸಿ. ಯಾವ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಶ್ನೆ ಮಾಡಿತು ಮತ್ತು ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಕೇಳಿ, ನಂತರ ಆ ಘಟನೆಯನ್ನು ನಿಜವಾಗಿ ಹೊಂದಿರುವ ಲಾಗ್ ಅನ್ನು ನೋಡಿ. ಇನ್ನೊಂದು ಲಾಗ್‌ನಿಂದ ಊಹಿಸುವುದು ಒಂದು ನಿಮಿಷ ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ಮಧ್ಯಾಹ್ನ ವೆಚ್ಚ ಮಾಡುತ್ತದೆ.