VPN DNS ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ .local ಹೆಸರುಗಳು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತವೆ: ಅವನ್ನು ಯಾರು ಪರಿಹರಿಸುತ್ತಾರೆ?

ಒಂದೇ VPN ನಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು, ಒಂದೇ ಹೋಸ್ಟ್‌ನೇಮ್, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಅದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಟನಲ್ ಅಲ್ಲ, ಬದಲಿಗೆ ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂಬುದು. Linux ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ ಆ ಹೆಸರು ಹೆಸರು ಸೇವಾ ಸ್ವಿಚ್ ಮೂಲಕ, systemd-resolved ನ ಸ್ಟಬ್ ಮೂಲಕ, ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನೊಂದಿಗೆ ತಂದ ರಿಸಾಲ್ವರ್ ಮೂಲಕ ಹೋಗಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಅದೇ ಸಫಿಕ್ಸ್‌ಗೆ ತನ್ನದೇ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ನಿಯಮಗಳು ಭಿನ್ನವಾಗುವುದು ಸಫಿಕ್ಸ್‌ನಲ್ಲೇ, ಏಕೆಂದರೆ .local ತಟಸ್ಥ ಲೇಬಲ್ ಅಲ್ಲ. ಏನಾದರೂ ಯಾವ ಕ್ರಮದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವ ಮೊದಲು ವಿಫಲವಾಗುವ ಪ್ರೋಗ್ರಾಂ ನಿಜವಾಗಿ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ.

ಎರಡು ರಿಸಾಲ್ವರ್‌ಗಳು, ಎರಡು ವಿಭಿನ್ನ ಉತ್ತರಗಳು

ಸಾಂಪ್ರದಾಯಿಕ glibc ಹುಡುಕಾಟ nsswitch.conf ನ hosts: ಸಾಲಿನ ಮೂಲಕ ಸಾಗಿ ಒಂದು ಉತ್ತರಿಸುವವರೆಗೆ ಪ್ರತಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಸರದಿಯಲ್ಲಿ ಕೇಳುತ್ತದೆ. ಸ್ಟಬ್ ಶ್ರೋತೃದ ಮೂಲಕ systemd-resolved ಜೊತೆ ಮಾತನಾಡುವ ಕ್ಲೈಂಟ್ ಬದಲಿಗೆ ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ರಕ್ರಿಯೆ ಪ್ರತಿ ಲಿಂಕ್‌ಗೂ ನೀತಿಯನ್ನು ಜೊತೆಗೆ ತನ್ನದೇ ವಿಶೇಷ ಪ್ರಕರಣಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ತನ್ನದೇ ರಿಸಾಲ್ವರ್ ತರುವ ಅಥವಾ ಹಾಗೆ ಮಾಡುವ ಗ್ರಂಥಾಲಯವನ್ನು ಲಿಂಕ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ಎರಡನ್ನೂ ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ಹಾಗಾಗಿ ಒಂದು ಹೋಸ್ಟ್‌ನೇಮ್‌ಗೆ ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಮೂರು ಮಾಲೀಕರಿರಬಹುದು, ಮತ್ತು ಅವರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಮಾತ್ರ VPN ಏನು ಉದ್ದೇಶಿಸಿತ್ತು ಎಂದು ತಿಳಿದಿದೆ.

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

ಯಾವ ಆಜ್ಞೆ ನಿಜವಾಗಿ ನಿಮ್ಮ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಕೇಳಿತು

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

ಮೊದಲನೆಯದು ಸಂರಚಿತ ಮಾಡ್ಯೂಲ್‌ಗಳ ಮೂಲಕ ಕೇಳುತ್ತದೆ, ಸಾಮಾನ್ಯ ಪ್ರೋಗ್ರಾಂ ಅನುಭವಿಸುವುದು ಇದನ್ನೇ. ಎರಡನೆಯದು ನೇರವಾಗಿ systemd-resolved ಅನ್ನು ಕೇಳುತ್ತದೆ ಮತ್ತು ಉತ್ತರಿಸಿದ ಲಿಂಕ್, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಸರ್ವರ್ ಅನ್ನು ವಿಳಾಸದ ಮೂಲಕ ಕೇಳುವುದು ಸರ್ವರ್ ದಾಖಲೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಎಂದಾದರೂ ಅದನ್ನು ಕೇಳಿತೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. VPN ಒಯ್ಯುವ ಲಿಂಕ್ ಮತ್ತು ಅದು ಪ್ರತಿಪಾದಿಸುವ ಡೊಮೇನ್‌ಗಳನ್ನು ಓದಿ, ನಂತರ ಆ ಪಟ್ಟಿಯನ್ನು ವಿಫಲವಾಗುವ ಹೆಸರಿನ ಸಫಿಕ್ಸ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಏಕೆ .local ನಿಮ್ಮ unicast ವಲಯವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ

systemd-resolved ನ ಉಲ್ಲೇಖ ಹೇಳುವ ಪ್ರಕಾರ .local ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಬಹು-ಲೇಬಲ್ ಹೆಸರುಗಳು mDNS ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ಸಾಮಾನ್ಯ unicast DNS ಗಿಂತ ಬದಲಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ multicast DNS ಗೆ ಹೋಗುತ್ತವೆ. RFC 6762 ಆ ಹೆಸರಿನ ಜಾಗವನ್ನು link-local multicast ಗಾಗಿ ಕಾದಿರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಾರ್ಪೊರೇಟ್ ವಲಯವು ಆ ಸಫಿಕ್ಸ್‌ಗೆ ಎಂದಿಗೂ ಕೇಳದ ಸರಿಯಾದ ದಾಖಲೆಯನ್ನು ಹೊಂದಿರಬಹುದು. ಟನಲ್ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ರೌಟ್ ಮಾಡಿ ಸಹ ಸ್ಪರ್ಧೆಯಲ್ಲಿ ಸೋಲಬಹುದು. ಕ್ಯಾಶ್‌ನಿಂದ ಯಶಸ್ವಿಯಾದ ping ಈಗಷ್ಟೇ ನಡೆದ ಹುಡುಕಾಟದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

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

ಸಣ್ಣ ವಿನಾಯಿತಿ ಜಾಗತಿಕ ಮರುಕ್ರಮವನ್ನು ಸೋಲಿಸುತ್ತದೆ

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

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

ಬದಲಾವಣೆಯ ನಂತರ ಏನು ಸಾಬೀತುಪಡಿಸಬೇಕು

ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಸ್ಥಾಪಿಸಿದ ಉಪಕರಣದಿಂದ ಅಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಹುಡುಕಾಟದಿಂದ ಸಾಬೀತುಪಡಿಸಿ, ಮತ್ತು ಅದರ ಪರವಾಗಿ ಉತ್ತರಿಸಬಹುದಾದ ಯಾವುದೇ ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡಿ. ನಂತರ ರಿಸಾಲ್ವರ್ ಮಾರ್ಗ ಮತ್ತು ಉತ್ತರ ನೀಡಿದ ಲಿಂಕ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ. ಕೊನೆಯದಾಗಿ ಸ್ಥಳೀಯ ಅನ್ವೇಷಣೆ ಬದಲಾವಣೆಯ ಮೊದಲಿನಂತೆಯೇ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಕಾಣದಂತಾಗುವ ಪ್ರಿಂಟರ್ ಜನರು ಕೊನೆಯಲ್ಲಿ ಗಮನಿಸುವ ಭಾಗ. ಈ ಮೂರು ಆಜ್ಞೆಗಳು ಹೆಸರು, ಮಾರ್ಗ ಮತ್ತು TLS ಗುರುತನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತವೆ:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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