/etc/resolv.conf ಗಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಎರಡು Linux ಸೇವೆಗಳನ್ನು ನಿಲ್ಲಿಸಿ

DNS ಪದೇ ಪದೇ ಹಿಂದಿನ ಸ್ಥಿತಿಗೆ ಮರಳುತ್ತದೆ, VPN ಮರುಸಂಪರ್ಕ ನಿಮ್ಮ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಗೆ ತಂಡದಲ್ಲಿ ಯಾರೋ ಫೈಲ್ ಅನ್ನು ಲಾಕ್ ಮಾಡಲು ಸೂಚಿಸುತ್ತಾರೆ. ಆ ಕ್ರಮವು ಲಕ್ಷಣವೇ ಹೊರತು ಪರಿಹಾರವಲ್ಲ: ಎರಡೂ ಘಟಕಗಳು /etc/resolv.conf ತಮ್ಮದು ಎಂದು ಭಾವಿಸುತ್ತವೆ, ಮತ್ತು ಕೊನೆಯದಾಗಿ ಬರೆಯುವವನು ಗೆಲ್ಲುತ್ತಾನೆ. ಫೈಲ್ ಲಾಕ್ ಮಾಡುವುದು ಮಾಲೀಕತ್ವದ ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ಮರೆಮಾಡುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನೀವು ನಿಜವಾಗಿ ಬಯಸಿದ ಘಟಕವನ್ನು ಮುರಿಯುತ್ತದೆ. ಕೆಳಗಿನ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ವ್ಯವಸ್ಥೆಯನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ ಹಂತದಲ್ಲಿ ಸರಿಪಡಿಸಿ, ಫೈಲ್ನಲ್ಲಿ ಅಲ್ಲ.

ಪರಿಶೀಲನೆ 1: ಇದು ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಆಗಿದೆಯೇ, ಮತ್ತು ಎಲ್ಲಿಗೆ

ಫೈಲ್ನಿಂದಲೇ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ನೀವು ಸಂಪಾದಿಸುತ್ತಿರುವ ಮಾರ್ಗವು ಫೈಲ್ ಆಗಿಯೇ ಇಲ್ಲದಿರಬಹುದು. ರಿಜಾಲ್ವರ್ನ ರನ್ಟೈಮ್ ಡೈರೆಕ್ಟರಿಗೆ ಹೋಗುವ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್, ಕ್ಲೈಂಟ್ ಸ್ಕ್ರಿಪ್ಟ್ ಪುನಃ ಬರೆಯುವ ಸಾಮಾನ್ಯ ಫೈಲ್ಗಿಂತ ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತದೆ:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved ನ stub ಮಾರ್ಗಕ್ಕೆ ಲಿಂಕ್ ಎಂದರೆ ಫೈಲ್ನ ವಿಷಯವು ಉತ್ಪಾದನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಕೈಯಿಂದ ಸಂಪಾದನೆ ಮುಂದಿನ ಘಟನೆಯಲ್ಲಿ ಮೇಲೆಬರೆಯಲ್ಪಡುತ್ತದೆ. nameserver ಸಾಲುಗಳಿರುವ ಸಾಮಾನ್ಯ ಫೈಲ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಚಲಿಸುವ ಕ್ಲೈಂಟ್ ಅಥವಾ DHCP ಹುಕ್ ಬರೆಯುತ್ತದೆ. ಎರಡೂ ಕಾನೂನುಬದ್ಧ; ಮುಖ್ಯವಾದುದು ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ನಿಮ್ಮಲ್ಲಿ ಯಾವುದು ಇದೆ ಎಂದು ತಿಳಿಯುವುದು.

ಪರಿಶೀಲನೆ 2: ಯಾವ ಡೀಮನ್ ಚಲಿಸುತ್ತಿದೆ

ಏನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂಬುದಲ್ಲ, ಏನು ನಿಜವಾಗಿ ಸಕ್ರಿಯವಾಗಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ. ಆಧುನಿಕ ವಿತರಣೆಯಲ್ಲಿ ಹಲವು ರಿಜಾಲ್ವರ್ಗಳು ಇರಬಹುದು, ಮತ್ತು ಲೂಪ್ಬ್ಯಾಕ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಪೋರ್ಟ್ 53 ಅನ್ನು ಹಿಡಿದಿರುವುದೇ ಉತ್ತರಿಸುತ್ತದೆ:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

ಸ್ಥಿತಿ ಔಟ್ಪುಟ್ ಪ್ರತಿ ಲಿಂಕ್ನ DNS ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಅದು split DNS ಗಾಗಿ ನಿಮಗೆ ಬೇಕಾದ ನಕ್ಷೆ. ಆಂತರಿಕ ಹೆಸರುಗಳು ಆಂತರಿಕ ಸರ್ವರ್ಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ಗೆ ಹೋಗಬೇಕು ಎಂದಾದರೆ, ಆ ನೀತಿ ಪ್ರತಿ ಲಿಂಕ್ನ ಡೊಮೇನ್ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಫೈಲ್ನಲ್ಲಿ ಸ್ಥಿರ nameserver ಪಟ್ಟಿಗೆ ಚಪ್ಪಟೆಗೊಳಿಸುವುದು ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಮೌನವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

NetworkManager ನ ಸ್ವಂತ ಸಂರಚನೆ ಅದು ಯಾವ ಬ್ಯಾಕೆಂಡ್ ಬಳಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮುಖ್ಯ ಸಂರಚನಾ ಫೈಲ್ನಲ್ಲಿನ ಅದರ dns= ಸೆಟ್ಟಿಂಗ್ ಅದರ ಆಂತರಿಕ ರಿಜಾಲ್ವರ್, dnsmasq, systemd-resolved ಮತ್ತು none ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ವಿತರಣೆ ನಿಮ್ಮ ಪರವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿರಬಹುದು. ಈ ಹೋಸ್ಟ್ನಲ್ಲಿ “DNS ಸರಿಪಡಿಸುವುದು” ಎಂದರೆ ಏನು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಆ ಸೆಟ್ಟಿಂಗ್ ಓದಿ.

ಪರಿಶೀಲನೆ 3: VPN ಕ್ಲೈಂಟ್ಗೆ ಏನು ಬರೆಯಲು ಅನುಮತಿ ಇದೆ

ಸಂಘರ್ಷ ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿಯೇ ವಾಸಿಸುತ್ತದೆ. ರಿಜಾಲ್ವರ್ ಫೈಲ್ ಅನ್ನು ನೇರವಾಗಿ ಪುನಃ ಬರೆಯುವ VPN ಕ್ಲೈಂಟ್ ಅದನ್ನೂ ನಿರ್ವಹಿಸುವ ಯಾವುದೇ ಸೇವೆಯೊಂದಿಗೆ ಹೋರಾಡುತ್ತದೆ, ಮತ್ತು ಸೋಲುವವನು ಮೊದಲು ಚಲಿಸುವವನು. ಇತ್ತೀಚಿನ OpenVPN ಬಿಡುಗಡೆಗಳು ಫೈಲ್ ಪುನಃ ಬರೆಯುವ ಬದಲು DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು systemd-resolved ಗೆ ನೀಡಬಹುದು, ಅದುವೇ ನೀವು ಬಯಸುವ ಸಹಕಾರಿ ವರ್ತನೆ; ಹಳೆಯ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಮತ್ತು ಕೈಯಿಂದ ಬರೆದ ಹುಕ್ಗಳು ಹಳೆಯ ಸಹಾಯಕ ಸಾಧನವನ್ನು ಕರೆಯುತ್ತವೆ ಅಥವಾ ಫೈಲ್ ಮೇಲೆ ಸುಮ್ಮನೆ ಬರೆಯುತ್ತವೆ.

WireGuard ನ ಪರಿಸ್ಥಿತಿ ಆಕಾರದಲ್ಲಿ ಸಮಾನವಾಗಿದೆ: ಇಂಟರ್ಫೇಸ್ ಸಂರಚನೆಯೇ DNS ನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಸುತ್ತಲಿನ ಸಾಧನಗಳು ರಿಜಾಲ್ವರ್ ಸಹಾಯಕ ಅಥವಾ resolved ಏಕೀಕರಣದ ಮೂಲಕ ನಿರ್ವಹಿಸುತ್ತವೆ. ಅಂತಹ ಎರಡು ಸಹಾಯಕಗಳು ಸ್ಥಾಪಿತವಾಗಿದ್ದರೆ, ಎರಡೂ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ತಮ್ಮ ಜಗತ್ತಿನ ದೃಷ್ಟಿಯನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ.

ಊಹಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್ನ up ಮತ್ತು down ಹುಕ್ಗಳನ್ನು ಓದಿ. /etc/openvpn/up.sh ಅಥವಾ ಸಮಾನ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ ಕೆಲವು ಸಾಲುಗಳ shell, ಇಲ್ಲದಿದ್ದರೆ ಯದ್ವಾತದ್ವ ಎನಿಸುವ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸ್ಪರ್ಧಿಸುವ ಬದಲು ಸಹಕರಿಸುವಂತೆ ಮಾಡುವ ಸ್ಥಳವೂ ಅದೇ.

ಪರಿಶೀಲನೆ 4: ಅದನ್ನು ಮಾಲೀಕನಲ್ಲಿಯೇ ಸರಿಪಡಿಸಿ, ಫೈಲ್ನಲ್ಲಿ ಅಲ್ಲ

ಮಾಲೀಕರು ಯಾರು ಎಂದು ತಿಳಿದ ನಂತರ, ಆ ಮಾಲೀಕರು ಬೆಂಬಲಿಸುವ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ DNS ಸಂರಚಿಸಿ. systemd-resolved ಗೆ ಇದು ಸ್ಥಿರ ಫೈಲ್ ಬದಲು ಪ್ರತಿ ಲಿಂಕ್ನ ಸೆಟ್ಟಿಂಗ್ಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳು; NetworkManager ಗೆ ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ನ DNS ಸೆಟ್ಟಿಂಗ್ಗಳು ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ಬ್ಯಾಕೆಂಡ್; resolvconf ಏಕೀಕರಣ ಬಳಸುವ ವಿತರಣೆಗೆ ಆ ಸಹಾಯಕದ ಮೂಲಕ ಬರೆಯುವುದು.

ಫೈಲ್ ಅನ್ನು ಅಪರಿವರ್ತನೀಯ ಮಾಡಬೇಡಿ. ಅಪರಿವರ್ತನೀಯ ಗುಣಲಕ್ಷಣವು ಕಾನೂನುಬದ್ಧ DHCP ನವೀಕರಣಗಳು ಮತ್ತು VPN ನವೀಕರಣಗಳನ್ನು ನೀವು ಹೋರಾಡುತ್ತಿದ್ದವುಗಳ ಜೊತೆಗೆ ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಪ್ಯಾಕೇಜ್ ಅಪ್ಗ್ರೇಡ್ ಅಥವಾ ಮರುಸಂಪರ್ಕವು ಸಂರಚನೆಯಿಂದ ಯಾರೂ ವಿವರಿಸಲಾಗದ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುವ ಸ್ಥಿತಿಯಲ್ಲಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಿಡುತ್ತದೆ. ಅದು ಮಾಲೀಕತ್ವದ ಸಂಘರ್ಷವನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಅದುವೇ ನೀವು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದ ವಿಷಯ.

ಎರಡು ಘಟಕಗಳು ನಿಜವಾಗಿಯೂ ಜೊತೆಯಾಗಿ ಇರಬೇಕಾದರೆ, ಅವುಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳನ್ನು ಕೊಡಿ. ನೆಟ್ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ಇಂಟರ್ಫೇಸ್ ಮಟ್ಟದ ಸಂರಚನೆಯನ್ನು ಹೊಂದಿರಲಿ, VPN ಕ್ಲೈಂಟ್ ಅದೇ ಏಕೀಕರಣದ ಮೂಲಕ ಪ್ರತಿ ಲಿಂಕ್ನ DNS ಮತ್ತು ಡೊಮೇನ್ಗಳನ್ನು ನೀಡಲಿ, ಮತ್ತು ಫೈಲ್ ಅನ್ನು ನೇರವಾಗಿ ಬರೆಯುವ ಮೂರನೇ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ. systemd-resolved ನ ದಸ್ತಾವೇಜು ಅದು ಬೆಂಬಲಿಸುವ ಮೋಡ್ಗಳನ್ನು ಮತ್ತು ಪ್ರತಿಯೊಂದೂ /etc/resolv.conf ನಲ್ಲಿ ಏನನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ನೀವು ಉಳಿಸಿಕೊಳ್ಳಬೇಕಾದ ನೀತಿಯ ಪ್ರಮಾಣಕ್ಕೆ ಹೊಂದುವ ಮೋಡ್ ಆಯ್ಕೆಮಾಡಿ. split DNS ಮುಖ್ಯವಾದರೆ, ಪ್ರತಿ ಲಿಂಕ್ನ ಡೊಮೇನ್ಗಳಿರುವ stub ವ್ಯವಸ್ಥೆ ಅದನ್ನು ಉಳಿಸುತ್ತದೆ, ಆದರೆ upstream ಸರ್ವರ್ಗಳನ್ನು ಫೈಲ್ಗೆ ನಕಲಿಸುವ ಮೋಡ್ ಅದನ್ನು ಮೌನವಾಗಿ ಚಪ್ಪಟೆಗೊಳಿಸುತ್ತದೆ.

ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರಿಶೀಲಿಸಿ, ಸಂಪಾದನೆಯ ನಂತರವಲ್ಲ

ನಿಮ್ಮ ಬದಲಾವಣೆಯ ನಂತರ ತಕ್ಷಣ ಸರಿಯಾಗಿ ಕಾಣುವ ಫೈಲ್ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಮುಂದಿನ ಘಟನೆ ಇನ್ನೂ ಸಂಭವಿಸಿಲ್ಲ. ಅದನ್ನು ಹಿಂದೆ ಮುರಿಯುತ್ತಿದ್ದ ಕ್ರಮವನ್ನು ಪ್ರಚೋದಿಸಿ: ಸುರಂಗವನ್ನು ಇಳಿಸಿ ಮತ್ತೆ ಏರಿಸಿ, DHCP ಲೀಸ್ ನವೀಕರಿಸಿ ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಬದಲಿಸಿ, ನಂತರ ಅದೇ ಮೌಲ್ಯಗಳನ್ನು ಮತ್ತೆ ಓದಿ.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

ನಂತರ ಮುಖ್ಯವಾದ ವ್ಯತ್ಯಾಸವನ್ನು ದೃಢೀಕರಿಸಿ: ಆಂತರಿಕ ಹೆಸರು ಆಂತರಿಕ ಸರ್ವರ್ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರು ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಎಲ್ಲವನ್ನೂ ಆಂತರಿಕ ಸರ್ವರ್ಗೆ ಕಳುಹಿಸುವ ಸಂರಚನೆ, ಯಾರಾದರೂ ಸುರಂಗದ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ ತಲುಪಲು ಪ್ರಯತ್ನಿಸುವವರೆಗೆ ಚೆನ್ನಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಸಾರ್ವಜನಿಕಕ್ಕೆ ಕಳುಹಿಸುವ ಸಂರಚನೆ ಆಂತರಿಕ ಹೆಸರುಗಳನ್ನು ಸೋರಿಸುತ್ತದೆ.

ನಿಯೋಜನಾ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಮಾಲೀಕ, ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಮೋಡ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಆ ಒಂದೇ ಪ್ಯಾರಾಗ್ರಾಫ್ ಭವಿಷ್ಯದ ಪ್ಯಾಕೇಜ್ ಅಪ್ಗ್ರೇಡ್ ಅನ್ನು ಘಟನೆಯಿಂದ ಪರಿಶೀಲನಾ ಅಂಶವಾಗಿ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ chattr ಆದೇಶದಿಂದ ಅದೇ ಸಂಘರ್ಷವನ್ನು ಮತ್ತೆ ಕಂಡುಹಿಡಿಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ.