VPN ನ DNS ಪ್ರತಿ ಲುಕಪ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: NetworkManager ನಲ್ಲಿ dns-priority ಸರಿಪಡಿಸಿ

ಕಚೇರಿ VPN ಗೆ ಸಂಪರ್ಕಿಸಿ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪ್ರತಿ ಹೆಸರಿನ ಲುಕಪ್ ಕಾರ್ಪೊರೇಟ್ ರಿಸಾಲ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಇನ್ನೂ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಸ್ಥಳೀಯ ಪ್ರಿಂಟರ್ ಹೆಸರು ವಿಫಲವಾಗುವವರೆಗೆ ಅಥವಾ split-horizon ದಾಖಲೆ ಕಚೇರಿ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುವವರೆಗೆ ಯಾವುದೂ ಮುರಿದಂತೆ ಕಾಣುವುದಿಲ್ಲ. ಕೆಲವು Fedora ಸೆಟಪ್‌ಗಳಲ್ಲಿ ವಿರುದ್ಧವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ: ಸುರಂಗ ಏರಿದ ನಂತರವೂ ISP ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ಪ್ರಶ್ನೆ — ಈ ಕ್ವೆರಿಯ ಮಾಲೀಕತ್ವ ಯಾವ ರಿಸಾಲ್ವರ್‌ಗೆ — ಮತ್ತು NetworkManager ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಉತ್ತರ ಪ್ರತಿ ಸಂಪರ್ಕದ DNS ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಇರುತ್ತದೆ.

ಎರಡು ಸಂಪರ್ಕ, ಒಂದು ಗೆಲ್ಲುವ ರಿಸಾಲ್ವರ್

ಪ್ರತಿ ಸಂಪರ್ಕವೂ DNS ಆದ್ಯತೆಯನ್ನು ಘೋಷಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ ಸಂಪರ್ಕಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ 50, VPN ಸಂಪರ್ಕಗಳು 0, ಮತ್ತು ಕಡಿಮೆ ಮೌಲ್ಯ ಗೆಲ್ಲುತ್ತದೆ. ಈ ಡೀಫಾಲ್ಟ್ ಕಾರಣವೇ, VPN ಸಂಪರ್ಕವು ಕ್ಲೇಮ್ ಮಾಡುವ ಪ್ರತಿ ಡೊಮೇನ್‌ಗೂ ತಂತಿಯ ಲಿಂಕ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮೀರಿಸುವುದು: ಯಾರೂ ಆಯ್ಕೆ ಮಾಡದೆಯೇ ಶೂನ್ಯ ಐವತ್ತನ್ನು ಸೋಲಿಸುತ್ತದೆ.

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

ಆದ್ಯತೆ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಹುಡುಕಾಟ ಪಟ್ಟಿ ಮಾಲೀಕತ್ವವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

ಹುಡುಕಾಟ ಪಟ್ಟಿ ಮಾಲೀಕತ್ವದ ಘೋಷಣೆ. corp.example ನಂತಹ ಬರಿ ಡೊಮೇನ್ ಹುಡುಕಾಟ ಪ್ರತ್ಯಯ ಮತ್ತು ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಆಗುತ್ತದೆ. ರೂಟಿಂಗ್‌ಗೆ ಮಾತ್ರವಾದ ರೂಪ ~corp.example ಆ ಪ್ರತ್ಯಯದ ಅಡಿಯಲ್ಲಿನ ಲುಕಪ್‌ಗಳನ್ನು ಡೊಮೇನ್ ಅನ್ನು ಸಣ್ಣ ಹೆಸರುಗಳಿಗೆ ಸೇರಿಸದೆ ಈ ಸಂಪರ್ಕಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಆ ಟಿಲ್ಡಾ «ಈ ಸರ್ವರ್‌ಗೆ ಕೇಳು» ಮತ್ತು «ಈ ಸರ್ವರ್‌ಗೆ ಕೇಳು ಮತ್ತು ನನ್ನ ಟೈಪಿಂಗ್ ಮುಗಿಸು» ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಬಳಕೆದಾರರು ಸಣ್ಣ ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಟೈಪ್ ಮಾಡುವಾಗ ಮತ್ತು ದಾಖಲೆಗಳು ಸಂಪೂರ್ಣ ಅರ್ಹ ಹೆಸರುಗಳಿಂದಲೂ ವಿಳಾಸಗೊಳ್ಳುವಾಗ ಎರಡೂ ರೂಪಗಳನ್ನು ಬಳಸಿ. ರಿಸಾಲ್ವರ್ ಬರಿ ಹೆಸರನ್ನು ಹೇಗೆ ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸದೆ ವಿಭಜನೆ ಬೇಕಾದಾಗ ಮಾತ್ರ ರೂಟಿಂಗ್ ರೂಪವನ್ನು ಬಳಸಿ.

ನಂತರ ಆದ್ಯತೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸಿ ಮತ್ತು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸಿ:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

ಋಣಾತ್ಮಕ ಆದ್ಯತೆ «ಈ ಸಂಪರ್ಕಕ್ಕೆ ಆದ್ಯತೆ ನೀಡು» ಎಂದು ಹೇಳುವ ದಾಖಲಿತ ದಾರಿ, ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಹೊಂದಿಸುವುದು IPv6 ಸಂಪರ್ಕವಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ವರ್ತನೆಯನ್ನು ಸ್ಥಿರವಾಗಿರಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸದೆ ಗುಣಲಕ್ಷಣ ಬದಲಿಸುವುದು ಈಗ ಚಾಲನೆಯಲ್ಲಿರುವ ಯಾವುದನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ರಮವು ಸ್ಪಷ್ಟ up ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ವಿಭಜನೆಯನ್ನು systemd-resolved ಹಿಡಿದಿರಲಿ

ಡೀಫಾಲ್ಟ್ dnsmasq ಪ್ಲಗಿನ್ ಕ್ವೆರಿಗಳನ್ನು ಒಂದೇ ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್‌ಗೆ ಸುರಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಲಿಂಕ್‌ನ ಪ್ರತ್ಯೇಕತೆ ಒರಟಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. systemd-resolved ವಿಭಜನೆಯನ್ನು ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು resolvectl query ಉತ್ತರಿಸಿದ ಲಿಂಕ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

ಅದರ ನಂತರ ಕಾರ್ಪೊರೇಟ್ ಲಿಂಕ್ corp.example ಅನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ಉಳಿದದ್ದನ್ನು ಸೇವಿಸುತ್ತದೆ. ಕ್ವೆರಿ ತಪ್ಪು ಲಿಂಕ್‌ಗೆ ತಲುಪಿದಾಗ, ಆಜ್ಞೆಯು ಅದಕ್ಕೆ ಉತ್ತರಿಸಿದ ಲಿಂಕ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ತಿಳಿಯುವುದು ಕೇವಲ ವಿಳಾಸ ತಿಳಿಯುವುದಕ್ಕಿಂತ ಉತ್ತಮ.

DNS ವಿನ್ಯಾಸವನ್ನು ಸುರಂಗ ಪ್ರಕಾರಕ್ಕೆ ಹೊಂದಿಸಿ

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

ನಂತರ ಸುರಂಗದ ಹೊರಗಿನ DNS ಅನ್ನು ತಡೆಯುವ kill switch ಇದೆ. ಸುರಂಗದ ವಲಯಗಳಿಗೆ ಹೆಸರುಗಳು ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಉಳಿದೆಲ್ಲೆಡೆ ವಿಫಲವಾಗುತ್ತವೆ, ಆದರೆ ಸಂಪರ್ಕ ಸಂಪೂರ್ಣ ಆರೋಗ್ಯವಾಗಿರುತ್ತದೆ. ಕಾರ್ಯಸಾಧ್ಯ ಉತ್ತರಗಳೆಂದರೆ LAN ರಿಸಾಲ್ವರ್‌ಗೆ ಸ್ಪಷ್ಟ ಅನುಮತಿ ಅಥವಾ ಕಾರ್ಪೊರೇಟ್ ವಲಯವನ್ನು ಮಾತ್ರ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಸ್ಥಳೀಯ ಕ್ಯಾಶ್, ಮತ್ತು ಎರಡೂ ಸುರಂಗದ ದೋಷವಲ್ಲ, ಮಾಲೀಕರಿರುವ ವಿನಾಯಿತಿ.

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

ಪ್ರತಿ ಲಿಂಕ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ಮೇಲೆ ಮತ್ತೊಮ್ಮೆ

ಒಂದು ಆಂತರಿಕ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಕೇಳಿ, ಮತ್ತು ಕ್ವೆರಿ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನೋಡಿ. ಸೋರಿಕೆ ಪರಿಶೀಲನಾ ಪುಟ ಯಾವ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಹೇಳುತ್ತದೆ, ಸಿಸ್ಟಮ್ ಯಾವ ಲಿಂಕ್ ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಈಗ ಸಂರಚಿಸಿದ ಕ್ರಮದ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಸಂಪರ್ಕ ಕಡಿತ ಮತ್ತು ಮರುಸಂಪರ್ಕದ ನಂತರ ಎರಡೂ ಕ್ವೆರಿಗಳನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಸಂಪರ್ಕ ಸಕ್ರಿಯವಾದಾಗ ಆದ್ಯತೆಗಳು ಮತ್ತೆ ಅನ್ವಯವಾಗುತ್ತವೆ, ಮತ್ತು ಹಳೆಯ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಯಾರಿಗೂ ನೆನಪಿಲ್ಲದ ಅಪ್‌ಗ್ರೇಡ್ ಅನ್ನೂ ಬದುಕಬಲ್ಲದು. ಕೊನೆಯಲ್ಲಿ ನೀವು ಬರೆದಿಡಲು ಬಯಸುವುದು ಯಾವ ರಿಸಾಲ್ವರ್ ಯಾವ ಪ್ರತ್ಯಯದ ಮಾಲೀಕ ಎಂಬುದು, ಜೊತೆಗೆ ನಾಳೆಯೂ ಮಾನ್ಯವಾಗಿರುವ ಪರಿಶೀಲನೆ.