ನಿಮ್ಮ /etc/hosts ನಮೂದು VPN ನ DNS ತಲುಪದೇ ಇರುವುದೇಕೆ

ನೀವು /etc/hosts ಗೆ ಒಂದು ಹೆಸರು ಸೇರಿಸಿ, VPN ಗೆ ಸಂಪರ್ಕಿಸಿ, ದಾಖಲೆ ಎಲ್ಲರಿಗೂ ಕಾಣುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದ್ದೀರಿ. ಹಾಗೆ ಆಗುವುದಿಲ್ಲ, ಮತ್ತು ಆಶ್ಚರ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೇ ಲಕ್ಷಣದೊಂದಿಗೆ ಬರುತ್ತದೆ: ಹೆಸರು ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಪರಿಹರಿಸಾಗುತ್ತದೆ ಮತ್ತು ಸಹೋದ್ಯೋಗಿಯ ಯಂತ್ರದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ಕೆಟ್ಟ VPN DNS ಸೇವೆಯಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ hosts ಫೈಲ್ ಅದಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತಿದೆ. hosts ಫೈಲ್ ಸ್ಥಳೀಯ ಹೆಸರು-ಪರಿಹಾರ ಸಂರಚನೆ, ವಲಯ ನವೀಕರಣವಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯ VPN ಸಂಪರ್ಕದಲ್ಲಿ ಯಾವುದೂ ಅದನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ.

Hosts ಸ್ಥಳೀಯ ಬದಲಿ, ವಲಯ ನವೀಕರಣವಲ್ಲ

ಫೈಲ್ ಎಂಬುದು ಹೆಸರು-ಸೇವಾ ಗ್ರಂಥಾಲಯಗಳು DNS ಸರ್ವರ್ ಅನ್ನು ಕೇಳುವ ಮೊದಲು ಅಥವಾ ಅದರ ಬದಲಿಗೆ ನೋಡುವ ಮ್ಯಾಪಿಂಗ್‌ಗಳ ಪಟ್ಟಿ. 10.40.0.20 build.corp.example ನಂತಹ ಸಾಲು ಆ ಒಂದು ಯಂತ್ರದಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಏನು ತೀರ್ಮಾನಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅದು ದಾಖಲೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಸುರಂಗದ ಮೂಲಕ ಹೋಗುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗವು ಸೂಚಿಸುವ DNS ಸರ್ವರ್‌ಗೆ ಅದರ ಅಸ್ತಿತ್ವದ ಪರಿಚಯವೇ ಇಲ್ಲ.

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

ಎರಡು ಆದೇಶಗಳು, ಎರಡು ವಿಭಿನ್ನ ಘಟಕಗಳು

ಈ ಚರ್ಚೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ ಎಂದರೆ ವ್ಯತ್ಯಾಸವನ್ನು ಎರಡು ಆದೇಶಗಳಲ್ಲಿ ಗೋಚರಿಸುವಂತೆ ಮಾಡುವುದು, ಎರಡೂ hosts ನಮೂದು ಇರುವ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಲಾಗುತ್ತವೆ:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

ಕ್ರಮವು ಸಂರಚನೀಯ, ಮತ್ತು ನಿರ್ದಿಷ್ಟ ವಿತರಣೆಯ ಬಗ್ಗೆ ಏನನ್ನಾದರೂ ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯ. /etc/nsswitch.conf ನಲ್ಲಿ hosts: ಸಾಲನ್ನು ನೋಡಿ; hosts: files dns ಮೊದಲು ಫೈಲ್‌ಗಳನ್ನು ನೋಡುತ್ತದೆ. ಕ್ರಮವನ್ನು ಬದಲಿಸಲು ಮಾತ್ರ ಆ ಉದಾಹರಣೆಯನ್ನು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸಂರಚನೆಯ ಮೇಲೆ ನಕಲಿಸಬೇಡಿ, ಏಕೆಂದರೆ ನಿಜವಾದ ಸಿಸ್ಟಂಗಳು ಉದಾಹರಣೆಯಲ್ಲಿ ಇಲ್ಲದ ಹೆಚ್ಚುವರಿ ಮೂಲಗಳು ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಸೇವಾ ನಮೂದುಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಪಟ್ಟಿ ಮಾಡುತ್ತವೆ.

systemd-resolved ಪರೀಕ್ಷೆಯನ್ನು ಮಂಜುಗೊಳಿಸುತ್ತದೆ

systemd-resolved ಬಳಸುವ ಸಿಸ್ಟಂನಲ್ಲಿ ಸ್ಥಳೀಯ ಸ್ಟಬ್ hosts ಡೇಟಾಬೇಸ್‌ನಿಂದಲೂ ಹೆಸರುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ 127.0.0.53 ಗೆ ಪ್ರಶ್ನೆ ಮಾಡುವುದು ದೂರದ ಸರ್ವರ್‌ನ ಸ್ವತಂತ್ರ ಪರೀಕ್ಷೆ ಅಲ್ಲ, ಅದು DNS ಪ್ರಶ್ನೆಯಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಹಾಗೆಯೇ ವರ್ತಿಸುತ್ತದೆ. ರಿಜಾಲ್ವರ್ ಏನು ತಿಳಿದಿದೆ ಮತ್ತು ಯಾವ ಸರ್ವರ್‌ಗಳನ್ನು ಕೇಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಇದರಿಂದ ಖಚಿತಪಡಿಸಬಹುದು:

resolvectl query build.corp.example
resolvectl status

status ಔಟ್‌ಪುಟ್ ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಹಾಗೆಯೇ VPN ಲಿಂಕ್‌ಗೆ ರಿಜಾಲ್ವರ್ ಸಿಕ್ಕಿದೆಯೇ ಎಂದು ತಿಳಿಯುತ್ತೀರಿ. ಆ ಪ್ರಶ್ನೆ hosts ನಮೂದಿನಿಂದ ಬೇರೆಯದು ಮತ್ತು ಖಾಸಗಿ ಹೆಸರು ಒಬ್ಬರಿಗೆ ಅಲ್ಲದೆ ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರಿಗೂ ವಿಫಲವಾದಾಗ ಕೇಳಲು ಯೋಗ್ಯವಾದ ಪ್ರಶ್ನೆ ಅದೇ.

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

VPN ಉದ್ದಕ್ಕೂ ಹೆಸರನ್ನು ವಾಸ್ತವವಾಗಿ ಯಾವುದು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ

ಖಾಸಗಿ ಹೆಸರು ಎಲ್ಲರಿಗೂ ಕೆಲಸ ಮಾಡಬೇಕಾದರೆ, ಎಲ್ಲರ ರಿಜಾಲ್ವರ್ ತಲುಪಬಲ್ಲ ಮಾಲೀಕರು ಬೇಕು. ಸ್ವಚ್ಛ ಉತ್ತರ ಎಂದರೆ ದಾಖಲೆಯನ್ನು ನಿರ್ವಹಿತ ವಲಯದಲ್ಲಿ ಪ್ರಕಟಿಸುವುದು ಮತ್ತು ಆ ವಲಯವನ್ನು ಉದ್ದೇಶಿತ VPN DNS ಮಾರ್ಗದ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದಾದಂತೆ ಮಾಡುವುದು. ಆಗ ದಾಖಲೆಗೆ ಒಂದೇ ಸತ್ಯದ ಮೂಲ, ಆಡಿಟ್ ಜಾಡು ಮತ್ತು ಜೀವನಚಕ್ರ ಇರುತ್ತದೆ, ಮತ್ತು ಯಾವ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಬದಲಿ ಇದೆ ಎಂದು ಯಾರೂ ನೆನಪಿಡಬೇಕಿಲ್ಲ.

hosts ಫೈಲ್‌ಗಳನ್ನು ವಿತರಿಸುವುದು ಕಾನೂನುಬದ್ಧ ಪರ್ಯಾಯ, ಮತ್ತು ಅದು ಹೆಸರು-ಸೇವೆ ಅಲ್ಲ, ಎಂಡ್‌ಪಾಯಿಂಟ್ ನಿರ್ವಹಣೆ. ನೀವು ಅದನ್ನು ಆರಿಸಿದರೆ, ಫ್ಲೀಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಫೈಲ್ ಅನ್ನು ನಿಯೋಜಿಸಿ, ಆವೃತ್ತಿ ಮಾಡಿ ಮತ್ತು ತೆಗೆದುಹಾಕಬೇಕು, ಮತ್ತು ವಿನ್ಯಾಸದಲ್ಲಿ ಅದನ್ನು ಹಾಗೆಯೇ ವಿವರಿಸಬೇಕು. “VPN ಅದನ್ನು ನೋಡಿಕೊಳ್ಳುತ್ತದೆ” ಆ ಪ್ರಕ್ರಿಯೆಯ ವಿವರಣೆ ಅಲ್ಲ.

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

ಪರಿಹರಿಸಿದ ಹೆಸರು ಮಾರ್ಗವಲ್ಲ

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

ಆದ್ದರಿಂದ ವರದಿ “ಹೆಸರು ಪರಿಹರಿಸಾಗುತ್ತದೆ ಆದರೆ ಸೇವೆ ತಲುಪಲಾಗದು” ಎಂದಾಗ, ಸಿಸ್ಟಂ ಲುಕಪ್ ಅನ್ನು VPN DNS ಸರ್ವರ್‌ಗೆ ಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ನಂತರ ನೀವು ಪಡೆದ ವಿಳಾಸವನ್ನು ಸೇವೆ ವಾಸ್ತವವಾಗಿ ಬಳಸುವ ವಿಳಾಸದೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ. systemd-resolved ಉಲ್ಲೇಖ ಅದು ನೋಡುವ ಸ್ಥಳೀಯ ಮೂಲಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಹೋಲಿಕೆಗೆ ಬೇಕಾದ ನಕ್ಷೆ ಅದೇ.

ನಂತರ ಬದಲಿಯನ್ನು ಅದರ ಮಾಲೀಕರ ಮೂಲಕ ಸರಿಪಡಿಸಿ. ನಿಮ್ಮದೇ hosts ಫೈಲ್‌ನಿಂದ ಒಂದು ಸಾಲನ್ನು ತೆಗೆದರೆ ನಿಯೋಜನಾ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ಅದೇ ಸಾಲನ್ನು ಪಡೆದ ಆ ಹನ್ನೆರಡು ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳಿಗೆ ಏನೂ ಆಗುವುದಿಲ್ಲ, ಮತ್ತು ಜನರಿಗೆ ವಾಸ್ತವವಾಗಿ ಇರುವ ಈ ಸಮಸ್ಯೆಯ ಆವೃತ್ತಿ ಅದೇ.