resolv.conf ನಿಮ್ಮ VPN DNS ಅನ್ನು ಏಕೆ ತೋರಿಸುತ್ತದೆ ಆದರೆ ಹುಡುಕಾಟಗಳು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ

ಲಾಗ್ಗಳಲ್ಲಿ ಏನೂ ತಪ್ಪು ಕಾಣುತ್ತಿಲ್ಲ: ಇಂಟರ್ಫೇಸ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ರಿಜಾಲ್ವರ್ VPN ನ DNS ಸರ್ವರ್ ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಡಿಸ್ಕ್ನಲ್ಲಿರುವ ಫೈಲ್ ಅದನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಆದರೂ ಆಂತರಿಕ ಹೋಸ್ಟ್ಹೆಸರು ಇನ್ನೂ ಸ್ಥಳೀಯ ರೌಟರ್ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ಈ ಮೂರು ಹೇಳಿಕೆಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಲ್ಲ, ಏಕೆಂದರೆ ಫೈಲ್, ಪ್ರತಿ ಲಿಂಕ್ನ ಸ್ಥಿತಿ ಮತ್ತು ಹುಡುಕಾಟದ ಮಾರ್ಗ ಸಂಯೋಗದಿಂದ ಒಂದೇ ಹೆಸರನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು. ಕೆಳಗೆ systemd-resolved ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಕ್ವೆರಿ ನಿಜವಾಗಿ ಹಾದುಹೋಗುವ ಮಾರ್ಗವಿದೆ.

resolv.conf ಎಂಬ ಮೂರು ವಸ್ತುಗಳು

resolved ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ /etc/resolv.conf ಸಾಮಾನ್ಯವಾಗಿ /run/systemd/resolve/stub-resolv.conf ಗೆ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಆಗಿರುತ್ತದೆ. ಆ ಗುರಿಯಲ್ಲಿ ಸ್ಥಳೀಯ stub ಶ್ರೋತೃದ ವಿಳಾಸ, 127.0.0.53, ಜೊತೆಗೆ resolved ಲೆಕ್ಕಹಾಕಿದ ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳಿವೆ. ಇದು ಸ್ಥಿತಿಯ ನೋಟ, ಸ್ಥಿತಿಯೇ ಅಲ್ಲ.

ಸ್ಥಿತಿ resolved ನ ಪ್ರತಿ ಲಿಂಕ್ ಸಂರಚನೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ resolvectl status ಫೈಲ್ಗೆ ಭಿನ್ನವಾಗಿದ್ದರೂ ಸರಿಯಾಗಿರಬಹುದು. ಪ್ರತಿ ಲಿಂಕ್ ತನ್ನದೇ ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ತನ್ನದೇ ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಕ್ವೆರಿ ಬಂದಾಗ stub ಆ ಡೇಟಾವನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ. systemd-resolved ಕೈಪಿಡಿ ರಚಿಸಲಾದ ಫೈಲ್ಗಳು ಮತ್ತು ಪ್ರತಿ ಲಿಂಕ್ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ; ನೋಟ ಮತ್ತು ಸ್ಥಿತಿಯ ನಡುವಿನ ವಿಭಜನೆಯೇ ನೆನಪಿಡಲು ಯೋಗ್ಯವಾದ ಭಾಗ. ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ನ ಗುರಿಯನ್ನು ಬದಲಿಸುವುದು ಸಾಂಪ್ರದಾಯಿಕ ಕ್ಲೈಂಟ್ಗಳು ಓದುವುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ರಿಜಾಲ್ವರ್ ತಿಳಿದಿರುವುದನ್ನು ಅಲ್ಲ.

ಮೂರನೇ ವಸ್ತು, /run/systemd/resolve/resolv.conf, ಪ್ರತಿ ಲಿಂಕ್ ಅನ್ನು ಒಂದೇ ಸರ್ವರ್ ಪಟ್ಟಿಗೆ ಚಪ್ಪಟೆ ಮಾಡುತ್ತದೆ. ಆ ಫೈಲ್ಗೆ ತೋರಿಸುವ ಪ್ರೋಗ್ರಾಂ ಕ್ವೆರಿಗಳನ್ನು ನೇರವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿದ ಸರ್ವರ್ಗಳಿಗೆ ಕಳುಹಿಸಿ stub ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಲಿಂಕ್ ನೀತಿ ಅದಕ್ಕೆ ಇನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಹೀಗಾಗಿ ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ಎರಡು ಪ್ರೋಗ್ರಾಂಗಳು ಒಂದೇ ಹೆಸರಿಗೆ ಬೇರೆ ಬೇರೆ ಉತ್ತರ ನೀಡಬಹುದು, ಮತ್ತು ಯಾವುದೂ ಮುರಿದಿಲ್ಲ.

NSS ಮೂಲಕ ಒಂದು ಹುಡುಕಾಟವನ್ನು ಅನುಸರಿಸಿ

glibc ಹೆಸರಿಗೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂದು ನಿರ್ಧರಿಸಲು /etc/nsswitch.conf ಓದುತ್ತದೆ. resolve ಹೊಂದಿರುವ hosts ಸಾಲು ಪ್ರಶ್ನೆಯನ್ನು nss-resolve ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು D-Bus ಮೂಲಕ resolved ಅನ್ನು ಕೇಳಿ ಪ್ರತಿ ಲಿಂಕ್ನ ಉತ್ತರ ಪಡೆಯುತ್ತದೆ. ಕೇವಲ files dns ಇರುವ ಸಾಲು ಕ್ವೆರಿಯನ್ನು /etc/resolv.conf ಹೊಂದಿರುವ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ಆ ಒಂದೇ ಸಾಲು ಬ್ರೌಸರ್ ಮತ್ತು dig ನಡುವಿನ ಬಹುಪಾಲು ಭಿನ್ನಾಭಿಪ್ರಾಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. dig ನೇರವಾಗಿ resolv.conf ಓದುತ್ತದೆ ಮತ್ತು NSS ಅನ್ನು ಎಂದಿಗೂ ಮುಟ್ಟುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಮಾರ್ಗದ ಬದಲು stub ಅಥವಾ ಮೇಲಿನ ಸರ್ವರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ. getent hosts internal.example NSS ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಮತ್ತು ಅದರ ಉತ್ತರವನ್ನು dig ನ ಉತ್ತರದೊಂದಿಗೆ ಹೋಲಿಸುವುದೇ ಮೊದಲ ಉಪಯುಕ್ತ ಅಳತೆ.

ತಮ್ಮದೇ ರಿಜಾಲ್ವರ್ ಒಯ್ಯುವ ಅಥವಾ ಸ್ಥಿರ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ HTTPS ಮೇಲೆ DNS ಮಾತನಾಡುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ. resolv.conf ನಲ್ಲಿ ಅಥವಾ resolved ನ ಸ್ಥಿತಿಯಲ್ಲಿ ಯಾವುದೂ ಅವನ್ನು ಮಿತಿಗೊಳಿಸುವುದಿಲ್ಲ.

ಫೈಲ್ ಯಾರ ಒಡೆತನದಲ್ಲಿದೆ ಮತ್ತು ಎಲ್ಲಿಗೆ ತೋರಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಲಿಂಕ್ ಸರಪಳಿಯನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಒಡೆತನ ಯಾವ ಫೈಲ್ ಪ್ರಾಮಾಣಿಕ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರತಿ ಆಜ್ಞೆಯೂ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಓದುತ್ತದೆ.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

ಮೊದಲ ಸಾಲು ಲಿಂಕ್ ಮತ್ತು ಅದರ ಗುರಿಯನ್ನು ಒಟ್ಟಿಗೆ ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು VPN ಸ್ಕ್ರಿಪ್ಟ್ನ ಒಡೆತನದ ಸಾಮಾನ್ಯ ಫೈಲ್ ಎಂದರೆ ರಿಜಾಲ್ವರ್ ಆ ಬರವಣಿಗೆಯನ್ನು ಎಂದಿಗೂ ಇನ್ಪುಟ್ ಎಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಸ್ಥಿತಿಯ ಔಟ್ಪುಟ್ ಪ್ರತಿ ಲಿಂಕ್ನ ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ ಕ್ವೆರಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುವ ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. nsswitch ಸಾಲು stub ಅನ್ನು ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೈಲ್ನಲ್ಲಿ stub ವಿಳಾಸ ಇದ್ದರೂ ಅಲ್ಲಿ resolve ಇಲ್ಲದಿದ್ದರೆ ಕ್ವೆರಿಗಳು ಸ್ಥಳೀಯ ಶ್ರೋತೃವನ್ನು ತಲುಪುತ್ತವೆ ಆದರೆ ವಿಭಜನೆಯನ್ನು ಯಾವುದೂ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಆ ಕೊನೆಯ ಪಟ್ಟಿಯೂ ಮುಖ್ಯ, ಏಕೆಂದರೆ stub-resolv.conf ಇಲ್ಲದ ಹೋಸ್ಟ್ ಇಲ್ಲಿ ವಿವರಿಸಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ನಡೆಸುವುದಿಲ್ಲ.

ಸರಪಳಿ ಇನ್ನೊಂದು ಪ್ಯಾಕೇಜ್ ನಿರ್ವಹಿಸುವ ಫೈಲ್ನಲ್ಲಿ ಕೊನೆಗೊಂಡರೆ, VPN ಕ್ಲೈಂಟ್ ಮತ್ತು ಆ ಪ್ಯಾಕೇಜ್ ಸರಿಪಡಿಸಬೇಕಾದ ಇಬ್ಬರು ಒಡೆಯರು. ಲಿಂಕ್ ಬದಲಿಸುವುದು ಒಬ್ಬ ಒಡೆಯನ ಕೆಲಸವನ್ನು ಎಸೆದು ಇನ್ನೊಬ್ಬರದನ್ನು ಅದರ ಜಾಗದಲ್ಲಿ ಬಿಡುತ್ತದೆ.

ಲಿಂಕ್ನ ಒಡೆಯನ ಬಳಿ ಸರಿಪಡಿಸಿ

VPN ಸಂಪರ್ಕವು ತನ್ನ ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ಡೊಮೇನ್ಗಳನ್ನು ತನ್ನದೇ ಲಿಂಕ್ನಲ್ಲಿ ನೋಂದಾಯಿಸಿ, ನಂತರ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ಅವನ್ನು ಹಿಂಪಡೆಯಬೇಕು. NetworkManager ನ resolved ಏಕೀಕರಣ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸಹಾಯಕ ಎರಡೂ ಹಾಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ; ಕೇವಲ resolv.conf ಅನ್ನು ಮರುಬರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ.

ಈಗಾಗಲೇ ಇರುವ ಲಿಂಕ್ನಲ್ಲಿ ಚಾಲನಾ ಸಮಯದ ಸೆಟ್ಟಿಂಗ್ಗಳು ಕಾರ್ಯವಿಧಾನವನ್ನು ತೋರಿಸುತ್ತವೆ. resolvectl dns tun0 10.40.0.53 ಒಂದು ಸರ್ವರ್ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು resolvectl domain tun0 '~corp.example' ಒಂದು ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಸೇರಿಸುತ್ತದೆ. ಟಿಲ್ಡಾ (~) ಭಾರ ಹೊರುವ ಅಕ್ಷರ: ಅದು ಆ ಪ್ರತ್ಯಯದ ಕ್ವೆರಿಗಳನ್ನು ಈ ಲಿಂಕ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ ಉಳಿದದ್ದನ್ನು ಬಿಡುತ್ತದೆ, ಆದರೆ ಅದಿಲ್ಲದ ಅದೇ ಮೌಲ್ಯ ಹುಡುಕಾಟ ಡೊಮೇನ್ ಆಗಿ ವಿಭಜನೆ ಆವಿಯಾಗುತ್ತದೆ. ಆ ವಿಳಾಸಗಳು ಪ್ರಯೋಗಾಲಯದ ಉದಾಹರಣೆಗಳು, ಶಾಶ್ವತ ಸಂರಚನೆ ಅಲ್ಲ. resolvectl query host.corp.example ನಿಂದ ದೃಢೀಕರಿಸಿ ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸಿತು ಎಂದು ಓದಿ.

ನೋಂದಾಯಿತ ಸರ್ವರ್ಗೆ ಇನ್ನೂ ಮಾರ್ಗ ಬೇಕು. ಕ್ವೆರಿ ಸರಿಯಾದ ಲಿಂಕ್ ತಲುಪಿ ಸಮಯ ಮೀರಿದರೆ, ದೋಷ ರಿಜಾಲ್ವರ್ ಒಡೆತನದಲ್ಲಲ್ಲ, ಸುರಂಗದ ಮೂಲಕ ತಲುಪುವ ಸಾಮರ್ಥ್ಯದಲ್ಲಿದೆ.

ಕೆಲಸ ಮಾಡುವ ಸ್ಥಿತಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ

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

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