OpenVPN DNS ಸರ್ವರ್ ಕಳುಹಿಸಿತು, ಆದರೆ Linux ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ

ಕಳುಹಿಸಿದ DNS ಸರ್ವರ್ ಲಾಗ್ನಲ್ಲಿದೆ, ಟನೆಲ್ ಮೇಲಿದೆ, ಮತ್ತು ಒಳಗಿನ ಹೆಸರುಗಳು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತವೆ. ಕಳುಹಿಸುವಿಕೆಯಲ್ಲಿ ಸ್ವತಃ ಏನೂ ಮುರಿದಿಲ್ಲ; ಸೆಟ್ಟಿಂಗ್ ತಲುಪಿ ಅಲ್ಲೇ ನಿಂತಿತು. ಕಳುಹಿಸಿದ DNS ಆಯ್ಕೆ ಕ್ಲೈಂಟ್ಗೆ ಒಂದು ಸಂದೇಶ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ರಿಜಾಲ್ವರ್ಗೆ ಸೂಚನೆ ಅಲ್ಲ, ಮತ್ತು ಇವೆರಡರ ನಡುವಿನ ಹಸ್ತಾಂತರವೇ ಈ ಪ್ರಕರಣಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮುಗಿಯುವ ಸ್ಥಳ. ಐದು ಪರಿಶೀಲನೆಗಳು, ಕ್ರಮವಾಗಿ, ನಡೆಯದ ಹಸ್ತಾಂತರವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತವೆ.

ಪರಿಶೀಲನೆ ಒಂದು: ಸಂಪರ್ಕ ಹೇಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಸಂಪರ್ಕದ ಮಾಲೀಕರು ರಿಜಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಯಾರು ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಶೆಲ್ನಿಂದ ನೇರ openvpn ಆದೇಶ ತನ್ನ ಪ್ರಕ್ರಿಯೆ ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ಹೊಂದಿಲ್ಲ, ಆದರೆ systemd ಘಟಕ, NetworkManager ಅಥವಾ ಮಾರಾಟಗಾರರ ಕ್ಲೈಂಟ್ ಪ್ರತಿಯೊಂದಕ್ಕೂ DNS ಪ್ರಕಟಿಸುವ ತನ್ನದೇ ದಾರಿಯಿದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಊಹಿಸುವ ಮೊದಲು ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿ ಮತ್ತು ಘಟಕದ ಹೆಸರು ಓದಿ.

ಕಮಾಂಡ್-ಲೈನ್ ಪ್ರಕ್ರಿಯೆ ತಾನಾಗಿಯೇ NetworkManager ಸಂಪರ್ಕವಲ್ಲ, ಮತ್ತು NetworkManager ಸಂಪರ್ಕ ತಾನಾಗಿಯೇ resolv.conf ಬರೆದ ವಸ್ತುವಲ್ಲ. ಆ ಎರಡು ಊಹೆಗಳು ಈ ತನಿಖೆಯಲ್ಲಿ ವ್ಯರ್ಥವಾದ ಹೆಚ್ಚಿನ ಗಂಟೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ನೀವು ನಿಜವಾಗಿ ನೋಡುತ್ತಿರುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಯಾವ ಘಟಕ DNS ಪ್ರಕಟಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ.

ಮುಂದುವರಿಯುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ಬರೆದಿಡಿ. ನಂತರದ ಪ್ರತಿ ಪರಿಶೀಲನೆ ಅವರನ್ನೇ ಅವಲಂಬಿಸಿದೆ.

ಪರಿಶೀಲನೆ ಎರಡು: ರಿಜಾಲ್ವರ್ ಲಿಂಕ್ ನಿಜವಾಗಿ ಏನನ್ನು ಹಿಡಿದಿದೆ

systemd-resolved ಹೋಸ್ಟ್ನಲ್ಲಿ, resolvectl status ಪ್ರತಿ ಲಿಂಕ್ ಅನ್ನು ಅದರ DNS ಸರ್ವರ್ಗಳು ಮತ್ತು ಡೊಮೇನ್ಗಳೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಟನೆಲ್ ಲಿಂಕ್ ಹುಡುಕಿ ಅದರ ನಮೂದುಗಳನ್ನು ಓದಿ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಹೆಸರು tun0 ಎಂದು ಊಹಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಸಂಖ್ಯೆ ಕ್ರಮವು ರಚನೆಯ ಕ್ರಮವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಕಳುಹಿಸಿದ ವಿಳಾಸ ಲಿಂಕ್ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ವಿಫಲವಾದದ್ದು ಕ್ವೆರಿ ಅಲ್ಲ, ಹಸ್ತಾಂತರ.

ವಿಳಾಸ ಇದ್ದರೆ, ಮುಂದಿನ ಪ್ರಶ್ನೆ ಆ ಲಿಂಕ್ ಯಾವ ಡೊಮೇನ್ಗಳನ್ನು ಕ್ಲೇಮ್ ಮಾಡುತ್ತದೆ ಎಂಬುದು. ಡೊಮೇನ್ ಪಟ್ಟಿ ಇಲ್ಲದ ಲಿಂಕ್ ನೇರವಾಗಿ ಕೇಳಿದ ಹೆಸರುಗಳಿಗೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು split-DNS ನಿಯೋಜನೆ ಅದನ್ನು ಅಪರೂಪವಾಗಿ ಬಯಸುತ್ತದೆ. ವಿಳಾಸ ಮಾತ್ರ ಅಗತ್ಯ, ಸಾಕಾಗುವುದಿಲ್ಲ.

ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ರಿಜಾಲ್ವರ್ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಲಿಂಕ್ ಹೆಸರನ್ನು VPN ಲಾಗ್ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿನೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅಲ್ಲಿನ ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಲಾಗ್ ಸಾಲು ಬೇರೆ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬಂದಿದೆ ಎಂದು ಅರ್ಥ.

ಪರಿಶೀಲನೆ ಮೂರು: ಹೆಸರಿನ ಜಾಗ ಆ ಲಿಂಕ್ ಆಯ್ಕೆಮಾಡುತ್ತದೆಯೇ

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

ಡೊಮೇನ್ ಹಂಚಿಕೆ ಪರಿಶೀಲಿಸಿ, ಸರ್ವರ್ ವಿಳಾಸ ಮಾತ್ರವಲ್ಲ. ~corp.example ಎಂದು ಬರೆದ ಡೊಮೇನ್ ರೂಟಿಂಗ್ ಡೊಮೇನ್, ಮತ್ತು ಟಿಲ್ಡೆ ಚಿಹ್ನೆ ಹೆಸರು ಹೇಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ಗೆ ತನ್ನದೇ ರಿಜಾಲ್ವರ್ ಇದ್ದರೆ, ಸಿಸ್ಟಂ ಪರಿಕರದೊಂದಿಗಲ್ಲ, ಅದು ಬಳಸುವ ಅದೇ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಸಿಸ್ಟಂ ರಿಜಾಲ್ವರ್ ತಪ್ಪಿಸುವ ಕ್ವೆರಿ ಪರಿಕರ ಲಿಂಕ್ ಸ್ಥಿತಿ ಏನೇ ಇರಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.

ಪರಿಶೀಲನೆ ನಾಲ್ಕು: ಒಬ್ಬ ಮಾಲೀಕ, ಇಬ್ಬರಲ್ಲ

NetworkManager ಈಗಾಗಲೇ VPN ಮತ್ತು ರಿಜಾಲ್ವರ್ ಸ್ಥಿತಿ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಸಂಬಂಧವಿಲ್ಲದ ಹುಕ್ ಸ್ಕ್ರಿಪ್ಟ್ ಸೇರಿಸುವುದು ಸ್ಪರ್ಧಿ ಲೇಖಕರನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ systemd-resolved ಗಾಗಿ ಒದಗಿಸುವ ಹುಕ್ ಬೆಂಬಲಿತ ಏಕೀಕರಣ, ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ಜೀವನಚಕ್ರ ನಿರೀಕ್ಷಿಸುತ್ತದೆ: script-security 2, up ಮಾರ್ಗ, up-restart, down ಮಾರ್ಗ ಮತ್ತು down-pre. ಆ ಆಯ್ಕೆಗಳು ನೋಂದಣಿ ಮತ್ತು ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ಮೊದಲ ಸಂಪರ್ಕದಲ್ಲಿ ಮಾತ್ರವಲ್ಲ, ಸರಿಯಾದ ಕ್ಷಣಗಳಲ್ಲಿ ನಡೆಯುವಂತೆ ಮಾಡುತ್ತವೆ.

ಮಾರ್ಗದರ್ಶಿಯಿಂದ ನಕಲಿಸಿದ ಉದಾಹರಣೆಯ ಬದಲು ಪ್ಯಾಕೇಜ್ನಿಂದ ಸ್ಥಾಪಿತ ಮಾರ್ಗ ಬಳಸಿ. ಅನುಮತಿಗಳೂ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಹುಕ್ ಸವಲತ್ತುಗಳು ಇಳಿದ ನಂತರ ಚಲಿಸುತ್ತದೆ.

ತನ್ನ ಔಟ್ಪುಟ್ ಗುರಿ ಬದಲಿಸಲು ವಿತರಣೆಯ ರಿಜಾಲ್ವರ್ ಸ್ಕ್ರಿಪ್ಟ್ ಸಂಪಾದಿಸುವುದು ಒಂದು ಹೋಸ್ಟ್ನ ಪರಿಹಾರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದು ಸಾಮಾನ್ಯ ದುರಸ್ತಿ ಅಲ್ಲ.

ಪರಿಶೀಲನೆ ಐದು: ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಅದೇ ಫಲಿತಾಂಶ

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಲಿಂಕ್ ಮತ್ತೆ ಓದಿ. ಒಮ್ಮೆ ಕಾಣಿಸಿಕೊಂಡು ಮುಂದಿನ ಪರಿವರ್ತನೆಯಲ್ಲಿ ಮಾಯವಾಗುವ ನೋಂದಣಿ ಈ ಇಡೀ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಇರುವುದಕ್ಕೆ ಕಾರಣವಾದ ವೈಫಲ್ಯ. ಸಸ್ಪೆಂಡ್ ನಂತರ, ಬಲವಂತದ ಮರುಸಂಪರ್ಕದ ನಂತರ ಮತ್ತು ರಿಜಾಲ್ವರ್ ಸೇವೆ ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ ಪರೀಕ್ಷಿಸಿ. ಪ್ರತಿ ಪರಿವರ್ತನೆ ಬೇರೆ ಕ್ರಮದ ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.

ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಐದೂ ಪರಿಶೀಲನೆಗಳು ಪಾಸಾದಾಗ ಮಾತ್ರ ಕಳುಹಿಸಿದ ಸೆಟ್ಟಿಂಗ್ಗಳು ಬಳಕೆಯಲ್ಲಿವೆ ಎಂದು ಹೇಳಬಹುದು. ಅದಕ್ಕಿಂತ ಮೊದಲಿನದೆಲ್ಲವೂ ಅದೃಷ್ಟದ ಕ್ಷಣದ ಸ್ನ್ಯಾಪ್ಶಾಟ್.