resolvectl ಔಟ್ಪುಟ್ನಿಂದ ಪ್ರತಿ ಲಿಂಕ್ನ VPN DNS ರೂಟಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಓದುವುದು

resolvectl status ಪ್ರತಿ ಲಿಂಕ್ನ ಸರ್ವರ್, ಡೊಮೇನ್ಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ। ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ, ನಂತರ ಹೆಸರನ್ನು ಕೇಳಿ ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸಿತು ಎಂದು ಗಮನಿಸಿ।

resolvectl status ಚಲಾಯಿಸಿದಾಗ ಪ್ರತಿ ಲಿಂಕ್ನ ಬ್ಲಾಕ್ಗಳ ಗೋಡೆ ಸಿಗುತ್ತದೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಸರ್ವರ್ಗಳು ಮತ್ತು ತನ್ನದೇ ಡೊಮೇನ್ ಸಾಲು ಇರುತ್ತದೆ। ರೂಟಿಂಗ್ ಅನ್ನು ನಿರ್ಧರಿಸುವ ಸಾಲು ಡೊಮೇನ್ ಪಟ್ಟಿ, ನೇಮ್ಸರ್ವರ್ ವಿಳಾಸವಲ್ಲ, ಏಕೆಂದರೆ ಸ್ಥಳೀಯ ಸ್ಟಬ್ ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಹೆಸರನ್ನು ಕ್ಲೈಮ್ ಮಾಡುವ ಲಿಂಕ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ। ಉತ್ತರವನ್ನು ಓದುವ ಮೊದಲು ಆ ಕ್ಲೈಮ್ಗಳನ್ನು ಓದಿ, ನಂತರ ಹೆಸರನ್ನು ಕೇಳಿ ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಅದನ್ನು ರಚಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ। ಸರಿಯಾದ ಲಿಂಕ್ನಿಂದ ತಪ್ಪು ಉತ್ತರವು ತಪ್ಪು ಲಿಂಕ್ನಿಂದ ಸರಿಯಾದ ಉತ್ತರಕ್ಕಿಂತ ಬೇರೆ ಸಮಸ್ಯೆ।

ಪ್ರತಿ ಲಿಂಕ್ ಬ್ಲಾಕ್ ನಿಮಗೆ ಏನು ಹೇಳುತ್ತದೆ

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

/etc/resolv.conf ನಲ್ಲಿ 127.0.0.53 ನಂತಹ ಸ್ಟಬ್ ವಿಳಾಸವು ಸ್ಟಬ್ ಮುಂಭಾಗದಲ್ಲಿದೆ ಎಂದು ಮಾತ್ರ ಹೇಳುತ್ತದೆ। ಅದು ಉತ್ತರಿಸಿದ ಮೇಲ್ಭಾಗದ ಮೂಲವನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೇವಲ resolv.conf ಆಧಾರಿತ ರೋಗನಿರ್ಣಯ ನಿಂತುಹೋಗುತ್ತದೆ।

ಮೂರು ವಿಧದ ಡೊಮೇನ್ ನಮೂದುಗಳನ್ನು ಸರಿಯಾಗಿ ಓದಿ

ನಮೂದುಏನನ್ನು ಕ್ಲೈಮ್ ಮಾಡುತ್ತದೆಸಾಮಾನ್ಯ ತಪ್ಪು
corp.exampleರೂಟಿಂಗ್ ಡೊಮೇನ್ ಮತ್ತು ಹುಡುಕಾಟ ಪ್ರತ್ಯಯ: ಅದರ ಕೆಳಗಿನ ಹೆಸರುಗಳು ಈ ಲಿಂಕ್ಗೆ ಹೋಗುತ್ತವೆ, ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ ಬರಿಯ ಹೆಸರುಗಳಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆರೂಟಿಂಗ್ ಹೇಗಾದರೂ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಕಾಣುವುದರಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ
~corp.exampleಕೇವಲ ರೂಟ್: ಅದರ ಕೆಳಗಿನ ಹೆಸರುಗಳು ಈ ಲಿಂಕ್ಗೆ ಹೋಗುತ್ತವೆ, ಆದರೆ ಪ್ರತ್ಯಯ ಸೇರಿಸುವುದಿಲ್ಲರೂಟಿಂಗ್ಗೆ ಅಗತ್ಯ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ
~.ಡೀಫಾಲ್ಟ್ ರೂಟ್: ಬೇರೆ ಯಾವುದೇ ಲಿಂಕ್ ಹೊಂದಿಕೆಯಾಗದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ಲೈಮ್ ಮಾಡುತ್ತದೆವಿಭಜಿತ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಬಿಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಸುರಂಗವನ್ನು ಅನುಸರಿಸುತ್ತವೆ

ಟಿಲ್ಡಾ ಹುಡುಕಾಟದ ವರ್ತನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ರೂಟಿಂಗ್ ಅನ್ನಲ್ಲ। ಟಿಲ್ಡಾ ಇಲ್ಲದ ನಮೂದು ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಎರಡೂ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಅದರ ಕೆಳಗಿನ ಹೆಸರುಗಳನ್ನು ಆ ಲಿಂಕ್ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಏಕ-ಲೇಬಲ್ ಹೆಸರುಗಳಿಗೆ ಪ್ರತ್ಯಯ ಸೇರಿಸಲಾಗುತ್ತದೆ। ಟಿಲ್ಡಾ ನಮೂದು ಅದೇ ಪ್ರತ್ಯಯವನ್ನು ರೂಟ್ ಮಾಡುತ್ತದೆ ಆದರೆ ಅದನ್ನು ಹುಡುಕಾಟ ಪಟ್ಟಿಯಿಂದ ಹೊರಗಿಡುತ್ತದೆ। ಆದ್ದರಿಂದ ಟಿಲ್ಡಾ ತೆಗೆದರೆ ಯಾವ ಬರಿಯ ಹೆಸರುಗಳು ಪರಿಹಾರವಾಗುತ್ತವೆ ಎಂಬುದು ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಟಿಲ್ಡಾ ಇಲ್ಲದಿರುವುದು ಹುಡುಕಾಟದ ಸಮಸ್ಯೆ, ವಿಭಜಿತ DNS ವೈಫಲ್ಯವಲ್ಲ।

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

ಹೆಸರನ್ನು ಕೇಳಿ ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸಿತು ಎಂದು ನೋಡಿ

query ಉಪ-ಆಜ್ಞೆ ವಿಳಾಸ, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಉತ್ತರವನ್ನು ರಚಿಸಿದ ಲಿಂಕ್ ಅಥವಾ ವ್ಯಾಪ್ತಿಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ। ಖಾಸಗಿ ಪ್ರತ್ಯಯವು ಕ್ಲೈಮ್ ಮಾಡಬೇಕಾದ ಒಂದು ಹೆಸರು ಮತ್ತು ಒಂದು ಸಾಮಾನ್ಯ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ವರದಿಯಾದ ಮೂಲಗಳನ್ನು ಹೋಲಿಸಿ। ಖಾಸಗಿ ಹೆಸರು ವೈರ್ಲೆಸ್ ಲಿಂಕ್ನಿಂದ ಉತ್ತರಿಸಿದರೆ, ಕ್ಲೈಮ್ ಇಲ್ಲ ಅಥವಾ ಸುರಂಗ ಕೆಳಗಿದೆ; ವಿಭಜಿತ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಹೆಸರು ಸುರಂಗದಿಂದ ಉತ್ತರಿಸಿದರೆ, ಡೀಫಾಲ್ಟ್ ರೂಟ್ ತುಂಬಾ ಅಗಲವಾಗಿದೆ। ಆ ಎರಡು ವೈಫಲ್ಯಗಳು ಬ್ರೌಸರ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಮತ್ತು ಈ ಔಟ್ಪುಟ್ನಲ್ಲಿ ವಿರುದ್ಧವಾಗಿ ಕಾಣುತ್ತವೆ।

resolvectl status
resolvectl query host.corp.example

ವರದಿಯಾದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನೂ ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಅಥವಾ ಹೋಸ್ಟ್ ಫೈಲ್ನಿಂದ ಉತ್ತರ ಯಾವುದೇ ಮೇಲ್ಭಾಗದ ಮೂಲವನ್ನು ಕೇಳದೆ ಬರಬಹುದು। ಕ್ಯಾಶ್ನಿಂದ ಬಂದ ಉತ್ತರ ಹೆಸರು ಯಾವುದೋ ಸಮಯದಲ್ಲಿ ಪರಿಹಾರವಾಯಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಪ್ರಸ್ತುತ ನೀತಿ ಅದನ್ನು ಸರಿಯಾಗಿ ರೂಟ್ ಮಾಡುತ್ತದೆ ಎಂದಲ್ಲ।

ಹೆಸರಿನ ರೂಟಿಂಗ್ ಅನ್ನು ಪ್ಯಾಕೆಟ್ ರೂಟಿಂಗ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ರಿಜಾಲ್ವರ್ನ ನಿರ್ಧಾರ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ। ಆಯ್ಕೆಯಾದ ಸರ್ವರ್ಗೆ ಇನ್ನೂ ತನ್ನ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ಬೇಕು, ಮತ್ತು ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಇನ್ನೂ ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ಗೆ ರೂಟ್ ಬೇಕು, ಆದ್ದರಿಂದ ಸರಿಯಾದ DNS ನೀತಿ ಎಂದಿಗೂ ತೆರೆಯದ ಸಂಪರ್ಕದೊಂದಿಗೆ ಸಹಬಾಳ್ವೆ ನಡೆಸಬಹುದು। ಹೆಸರು ಪರಿಹಾರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾದಾಗ, ಮತ್ತೆ DNS ಬದಲಾಯಿಸುವ ಬದಲು ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ। ಹೆಸರು ಪರಿಹಾರ ಮತ್ತು ತಲುಪುವಿಕೆ ಎರಡು ವಿಭಿನ್ನ ಮಾಲೀಕರ ಎರಡು ಪ್ರಶ್ನೆಗಳು।

ಅಪ್ಲಿಕೇಶನ್ಗಳು ತಮ್ಮದೇ ಸುರಕ್ಷಿತ DNS ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ಒಳಗೊಂಡ ರಿಜಾಲ್ವರ್ ಮೂಲಕ ಸಿಸ್ಟಮ್ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡಬಹುದು। resolvectl ಫಲಿತಾಂಶ ಸಿಸ್ಟಮ್ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಬ್ರೌಸರ್ ನೀವು ಮಾಡುವ ಪ್ರತಿ ಪರೀಕ್ಷೆಗೂ ಭಿನ್ನವಾಗಿರುತ್ತದೆ। ನೀತಿ ಮುರಿದಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಆ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ।

ಹೆಸರು ಪರಿಹಾರವಾದ ವಿಳಾಸವನ್ನು ಲಿಂಕ್ನ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ। ತಪ್ಪು ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ಸರಿಯಾದ ಹೆಸರು ರೂಟಿಂಗ್ ಅಲ್ಲ, ದಾಖಲೆಯ ಸಮಸ್ಯೆ।

ಲಿಂಕ್ ಬದಲಾದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

ಮತ್ತೆ ಸಂಪರ್ಕ ಅಥವಾ ವೈರ್ಲೆಸ್ ಬದಲಾವಣೆ ಲಿಂಕ್ನ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುತ್ತದೆ, ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ಕೈಯಿಂದ ಸೆಟ್ ಮಾಡಿದ ಎಲ್ಲದರ ಮೇಲೆ ತನ್ನ ಡೊಮೇನ್ಗಳು ಮತ್ತು ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸಬಹುದು। ನಂತರ ಅದೇ ಎರಡು ಹೆಸರುಗಳನ್ನು ಕೇಳಿ ಮತ್ತು ದಾಖಲಾದ ಮೂಲರೇಖೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ। ಕೈ ಬರಹದ ಸಂಪಾದನೆ ಮಾಯವಾಗಿದ್ದರೆ, ಸರಿಪಡಿಸುವಿಕೆ ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ನಲ್ಲಿದೆ ಶೆಲ್ ಆಜ್ಞೆಯಲ್ಲಿ ಅಲ್ಲ। ಮೊದಲು ಮತ್ತು ನಂತರ ದಾಖಲಿಸುವುದೇ ಅದನ್ನು ಗೋಚರವಾಗಿಸುತ್ತದೆ।

ವರದಿಗೆ ಬೇಕಾದ ಹೆಸರುಗಳು ಮತ್ತು ಸರ್ವರ್ ಸಂದರ್ಭವನ್ನು ಮಾತ್ರ ಹಂಚಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಒಳಗಿನ ಪ್ರತ್ಯಯಗಳು ಟೋಪೋಲಜಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ। systemd-resolved ನ ಡೊಮೇನ್ ರೂಟಿಂಗ್ ದಸ್ತಾವೇಜು ಅತಿ ಉದ್ದದ ಹೊಂದಾಣಿಕೆಯ ನಿಯಮ ಮತ್ತು ಟಿಲ್ಡಾದ ವರ್ತನೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಒಮ್ಮೆ ಓದಿದರೆ ಮೇಲಿನ ಕೋಷ್ಟಕದ ಹೆಚ್ಚಿನ ತಪ್ಪುಗಳು ತಪ್ಪುತ್ತವೆ: systemd-resolved ನಲ್ಲಿ ಪ್ರಶ್ನೆ ರೂಟಿಂಗ್।

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