ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸುತ್ತದೆ: ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ VPN DNS ಗಾಗಿ ರೂಟಿಂಗ್ ಡೊಮೇನ್‌ಗಳು

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

ಮೊದಲ ಹಂತ: ರೂಟ್ ಅನ್ನು ರೆಸಾಲ್ವರ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ

ipv4.never-default ರೂಟಿಂಗ್ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸಂಪರ್ಕವನ್ನು ಎಲ್ಲಾ IPv4 ಸಂಚಾರದ ಮಾರ್ಗವಾಗಿ ಸ್ಥಾಪಿಸದಂತೆ NetworkManager ಅನ್ನು ತಡೆಯುತ್ತದೆ. DNS ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಹೊಂದಿಕೆಯಾಗುವ ಸಫಿಕ್ಸ್‌ಗಾಗಿ ಯಾವ ಲಿಂಕ್‌ನ ಹೆಸರು ಸರ್ವರ್‌ಗಳು ಕ್ವೆರಿ ಪಡೆಯುತ್ತವೆ. ಒಂದೂ ಇನ್ನೊಂದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ವರ್ಷಗಳ ಕಾಲ ಒಂದನ್ನು ಹೊತ್ತು ಇನ್ನೊಂದು ಇಲ್ಲದಿರಬಹುದು. ರೂಟ್ ಮಾತ್ರ ಎಂದರೆ ಟನೆಲ್ ಕಂಪನಿಯ ಉಪಜಾಲಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ರೆಸಾಲ್ವರ್ ಕಂಪನಿಯ ಹೆಸರುಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಉಳಿದದ್ದು ಮುಟ್ಟದೆ ಉಳಿಯುತ್ತದೆ.

ರೂಟ್ ಪ್ರಾಪರ್ಟಿ ಮಾತ್ರ ಸೆಟ್ ಮಾಡಿದರೆ ಒಳಗಿನ ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮುರಿದ ಟನೆಲ್‌ನಂತೆ ಕೇಳುವ ಸಮಯ ಮಿತಿಯೊಂದಿಗೆ. ಡೊಮೇನ್ ಮಾತ್ರ ಸೆಟ್ ಮಾಡಿದರೆ ಯಂತ್ರದ ಪ್ರತಿ ಚಿಕ್ಕ ಹೆಸರಿಗೂ ಸದ್ದಿಲ್ಲದೆ ಹುಡುಕಾಟ ಸಫಿಕ್ಸ್ ಸೇರಿಸಿದ್ದೀರಿ. ಎರಡೂ ತಪ್ಪುಗಳು ಟಿಕೆಟ್ ಅನ್ನು VPN ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಅದು ವಿರಳವಾಗಿ ತಪ್ಪಾದ ಭಾಗ.

ಎರಡನೇ ಹಂತ: ಪ್ರೊಫೈಲ್‌ಗೆ ರೂಟಿಂಗ್-ಮಾತ್ರ ಡೊಮೇನ್ ಸೇರಿಸಿ

ಸಂಪರ್ಕದ ಹೆಸರು corp-vpn, ಕಂಪನಿಯ ಸಫಿಕ್ಸ್ internal.example, ಮತ್ತು ಟನೆಲ್‌ನ ರೆಸಾಲ್ವರ್ ಈಗಾಗಲೇ ತಲುಪಬಹುದಾದದ್ದು ಎಂದು ಭಾವಿಸಿ. ಮೊದಲು ಪ್ರಸ್ತುತ ಮೌಲ್ಯಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ಈಗಾಗಲೇ ನಮೂದುಗಳನ್ನು ಹೊಂದಿರಬಹುದಾದ ಪ್ರಾಪರ್ಟಿಗಳನ್ನು ಬದಲಿಸುತ್ತವೆ.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

ಆರಂಭದ ಟಿಲ್ಡಾ ರೂಟಿಂಗ್-ಮಾತ್ರ ಡೊಮೇನ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊಂದಿಕೆಯಾಗುವ ಕ್ವೆರಿಗಳು ಈ ಲಿಂಕ್‌ನ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಸಫಿಕ್ಸ್ ಚಿಕ್ಕ ಹೆಸರುಗಳಿಗೆ ಸೇರುವುದಿಲ್ಲ. ಟಿಲ್ಡಾ ತೆಗೆದರೆ ಅದೇ ಸ್ಟ್ರಿಂಗ್ ಹುಡುಕಾಟ ಸಫಿಕ್ಸ್ ಕೂಡ ಆಗುತ್ತದೆ, ಇದು ಜನರು ಅಪರೂಪಕ್ಕೆ ಉದ್ದೇಶಿಸುವ ಬೇರೆ ಫಲಿತಾಂಶ. ಮೇಲಿನ ಎರಡೂ ಸೆಟ್ಟಿಂಗ್‌ಗಳು IPv4, ಆದ್ದರಿಂದ ದ್ವಿ-ಸ್ಟಾಕ್ ಪ್ರೊಫೈಲ್‌ಗೆ ipv6.never-default ಮತ್ತು ipv6.dns-search ನಲ್ಲಿ ಅದೇ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ IPv6 ಬದಿ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿ ಒಳಗಿನ ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ.

ಮೂರನೇ ಹಂತ: ಯಾವ ಲಿಂಕ್ ಉತ್ತರಿಸಿತು ಎಂದು resolvectl ಗೆ ಕೇಳಿ

resolvectl status ಚಲಾಯಿಸಿ ಮತ್ತು ಪ್ರತಿ ಲಿಂಕ್‌ನ DNS ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಡೊಮೇನ್‌ಗಳನ್ನು ಓದಿ, ನಂತರ ಕ್ವೆರಿ ಮಾಡಲು ಅನುಮತಿ ಇರುವ ನಿಜವಾದ ಒಳಗಿನ ಹೆಸರಿನ ವಿರುದ್ಧ resolvectl query host.internal.example ಚಲಾಯಿಸಿ. ಎರಡನೇ ಆಜ್ಞೆಯೇ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬುದಕ್ಕೆ ಏಕೈಕ ನೇರ ಸಾಕ್ಷಿ, ಏಕೆಂದರೆ ಅದು ಉತ್ತರಿಸಿದ ಲಿಂಕ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಸ್ಥಿತಿ ಪಟ್ಟಿ ಮಾತ್ರ ಸಂರಚನೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಕ್ವೆರಿ ಪರಿಹಾರವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

systemd-resolved ಅತ್ಯುತ್ತಮ ಹೊಂದಾಣಿಕೆಯ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದು ಲಿಂಕ್‌ನ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಡೊಮೇನ್ ಸ್ಪರ್ಧೆಯನ್ನು ಗೆಲ್ಲಬಹುದು. ಕ್ವೆರಿ ನೀವು ನಿರೀಕ್ಷಿಸದ ಲಿಂಕ್‌ನಿಂದ ಮರಳಿದರೆ, VPN ನ DNS ಸರ್ವರ್ ಮುಟ್ಟುವ ಮೊದಲು ಡೊಮೇನ್ ಪಟ್ಟಿಗಳನ್ನು ಓದಿ. ~. ಮೂಲ ಡೊಮೇನ್ ಎಲ್ಲದಕ್ಕೂ ಹೊಂದುತ್ತದೆ, ಮತ್ತು ಅದು ಈಗಾಗಲೇ ಇದ್ದರೆ ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಡೊಮೇನ್ ತನ್ನ ಹೆಸರುಗಳಿಗೆ ಇನ್ನೂ ಗೆಲ್ಲುತ್ತದೆ, ಆದರೆ ಲಿಂಕ್ ನೀವು ಕೇಳಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ಉದ್ದೇಶ ಕಂಪನಿಯ ಹೆಸರುಗಳು ಮಾತ್ರವಾದಾಗ ಆ ಮೂಲ ನಮೂದನ್ನು ತೆಗೆಯಿರಿ ಅಥವಾ ಕಿರಿದಾಗಿಸಿ.

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

ನಾಲ್ಕನೇ ಹಂತ: ಹೆಸರು ಪರಿಹರಿಸಿದಾಗ ಆದರೆ ಸೇವೆ ಅಲ್ಲ

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

ಈ ಪ್ರಶ್ನೆಯ ಜೊತೆ ಸುತ್ತುವ Samba ಬದಲಾವಣೆ ಪ್ರವೇಶ ಪದರಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, DNS ಆಯ್ಕೆಗೆ ಅಲ್ಲ. ಹೆಸರು-ಪರಿಹಾರ ದೋಷಕ್ಕೆ ಅದನ್ನು ಅನ್ವಯಿಸುವುದೇ ಸಣ್ಣ ಸಮಸ್ಯೆಗೆ ಎರಡನೆಯದು ಸಿಗುವ ದಾರಿ.

ಐದನೇ ಹಂತ: ಕಾಣೆಯಾದ ಡೊಮೇನ್ ಸರಿಪಡಿಸಲು ರೆಸಾಲ್ವರ್ ಬದಲಾಯಿಸಬೇಡಿ

ರೆಸಾಲ್ವರ್ ಫೈಲ್ ಮೇಲೆ ಬರೆಯುವ ಅಥವಾ ಬೇರೆ ರೆಸಾಲ್ವರ್ ಮ್ಯಾನೇಜರ್ ಸ್ಥಾಪಿಸುವ ಸಲಹೆ ಬೇರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಅವು ತಮ್ಮದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳಿರುವ ಸಿಸ್ಟಮ್ ಏಕೀಕರಣ ಬದಲಾವಣೆಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಎಂದಿಗೂ ಸಂರಚಿಸದ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಸೇರಿಸುವುದಿಲ್ಲ. ಬದಲಾಯಿಸುವ ಮೊದಲು ಯಂತ್ರದಲ್ಲಿ ಹೆಸರು-ಪರಿಹಾರ ಯಾವ ಘಟಕದ್ದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ systemd-resolved ಇರುವ NetworkManager ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ ಆ ಮಾಲೀಕತ್ವ ಈಗಾಗಲೇ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಅದರ ವಿರುದ್ಧ ಹೋರಾಡುವುದೇ ಕೆಲಸ ಮಾಡುವ ಸೆಟಪ್ ಅನ್ನು ಯಾರೂ ಮರುಸೃಷ್ಟಿಸಲಾಗದಂಥದ್ದಾಗಿ ಮಾಡುವ ದಾರಿ.

ಕೆಲಸದ ಕ್ರಮ: ಟನೆಲ್ ರೆಸಾಲ್ವರ್ ಒದಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ರೂಟಿಂಗ್-ಮಾತ್ರ ಡೊಮೇನ್ ಸೇರಿಸಿ, ಪ್ರೊಫೈಲ್ ನಿಯಂತ್ರಣಗಳ ಮೂಲಕ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಉತ್ತರಿಸುವ ಲಿಂಕ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು ಅದರ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಈ ಕ್ರಮವು ಎರಡನೇ ಸಂದರ್ಶನವಿಲ್ಲದೆ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಒಪ್ಪಿಸಬಹುದಾದ ಫಲಿತಾಂಶವನ್ನು ಬಿಡುತ್ತದೆ.