SIGKILL ನಂತರ OpenVPN DNS ಉಳಿಯುತ್ತದೆ: ಮೊದಲು ಮಾಲೀಕರನ್ನು ಪರಿಶೀಲಿಸಿ
SIGKILL OpenVPN ನ down ಹುಕ್ ಅನ್ನು ಚಲಾಯಿಸಲಾರದು, ಆದರೆ systemd-resolved ಪ್ರತಿ-ಲಿಂಕ್ DNS ಅನ್ನು ಹೇಗಾದರೂ ಬಿಡಬಹುದು. ಏನು ನಿರ್ಗಮಿಸಿತು, ರಿಸಾಲ್ವರ್ ಯಾರದ್ದು ಮತ್ತು ಏನು ಉಳಿದಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
OpenVPN ಕ್ಲೈಂಟ್ ಕೊಲ್ಲಲ್ಪಟ್ಟ ನಂತರ DNS ಪರಿಹರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಪ್ರವೃತ್ತಿ /etc/resolv.conf ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವುದು. ಆ ಬದಲಾವಣೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಒಡೆಯಬಹುದು, ಆದರೆ ನಿಜವಾದ ಹಳೆಯ ಸ್ಥಿತಿ ಬೇರೆಡೆ ಇರುತ್ತದೆ. ಮೊದಲು ಪರಿಹರಿಸಬೇಕಾದ ಪ್ರಶ್ನೆ ಎಂದರೆ ಟನೆಲ್ ಸ್ಥಾಪಿಸಿದ DNS ಸೆಟ್ಟಿಂಗ್ಗಳ ಮಾಲೀಕರು ಯಾರು, ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟ ನಿರ್ಗಮನ ನಿಜವಾಗಿ ಮುಖ್ಯವಾಗಿತ್ತೇ.
ಮೂರು ಷರತ್ತುಗಳು ದುರಸ್ತಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸಿದ ಸಿಗ್ನಲ್, ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಪಡೆದ ರಿಸಾಲ್ವರ್ ಘಟಕ, ಮತ್ತು ಟನೆಲ್ ಲಿಂಕ್ ಇನ್ನೂ ಇದೆಯೇ. ಆ ಕ್ರಮದಲ್ಲಿ ಉತ್ತರಿಸಿ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಜಾಗತಿಕ ಫೈಲ್ ಮುಟ್ಟದೆಯೇ ಬರುತ್ತದೆ.
ಯಾವ ರೀತಿಯ ನಿರ್ಗಮನ ಸಂಭವಿಸಿತು ಎಂದು ನಿರ್ಧರಿಸಿ
Community ಆವೃತ್ತಿಯಲ್ಲಿ OpenVPN ನಲ್ಲಿ SIGINT ಮತ್ತು SIGTERM ಎರಡೂ ಸೌಮ್ಯ ನಿರ್ಗಮನ ವಿನಂತಿಗಳು. SIGKILL ಅನ್ನು ಹಿಡಿಯಲಾಗದು: ಅದನ್ನು ತಡೆಯಲಾಗದು ಅಥವಾ ನಿರ್ವಹಿಸಲಾಗದು, ಆದ್ದರಿಂದ ಯಾವುದೇ ಶಟ್ಡೌನ್ ಕ್ರಮವು ಚಲಿಸುವ ಅವಕಾಶ ಪಡೆಯುವುದಿಲ್ಲ. ಮುಂಭಾಗದ ಟರ್ಮಿನಲ್ನಲ್ಲಿ ಸಾಮಾನ್ಯ Ctrl+C SIGINT ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಕಾಯುವಿಕೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಮೇಲ್ವಿಚಾರಕ ಸಾಮಾನ್ಯವಾಗಿ SIGKILL ಗೆ ಏರುತ್ತದೆ. ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ ಏಕೆಂದರೆ ಎರಡನೇ ಸಂದರ್ಭ ಮಾತ್ರ ಹುಕ್ಗಳನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದೆ ಎಂಬುದನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ.
screen ಅಥವಾ tmux ಒಳಗೆ ಚಲಾಯಿಸುವುದರಿಂದ Ctrl+C ಯಾವ ಸಿಗ್ನಲ್ ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದು ಬದಲಾಗುವುದಿಲ್ಲ. ಟರ್ಮಿನಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದಲ್ಲ, ಪ್ರಕ್ರಿಯೆ ನಿಜವಾಗಿ ಏನನ್ನು ಪಡೆಯಿತು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
ಸೇವೆ ಅಥವಾ ಸಂಪರ್ಕ ನಿರ್ವಾಹಕ ಟನೆಲ್ ಅನ್ನು ಚಲಾಯಿಸಿದಾಗ, pid ಅನ್ನು ಕೊಲ್ಲುವ ಬದಲು ಆ ಒಂದು ಸಂಪರ್ಕವನ್ನು ಅದರ ಮಾಲೀಕರ ಮೂಲಕ ನಿಲ್ಲಿಸಿ. ನಿರ್ವಾಹಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತೆ ಮೇಲೆತ್ತಬಹುದು, ಇದರಿಂದ ನಿಮಗೆ ಹೊಸ ಟನೆಲ್ ಮತ್ತು ಗೊಂದಲಮಯ ರಿಸಾಲ್ವರ್ ಸ್ಥಿತಿ ಉಳಿಯುತ್ತದೆ. ಸ್ವತಂತ್ರ ಪ್ರಕ್ರಿಯೆಗೆ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಚಲಿಸಲು ಸಾಮಾನ್ಯ ನಿಲುಗಡೆ ವಿನಂತಿ ಸಾಕು.
ರಿಸಾಲ್ವರ್ ಯಾರದ್ದು ಎಂದು ನಿರ್ಧರಿಸಿ
systemd-resolved, resolvconf ಶೈಲಿಯ ಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಸರಳ ಫೈಲ್ ಮರುಬರವಣಿಗೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರು. ಮೊದಲನೆಯದು ಪ್ರತಿ-ಲಿಂಕ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಇರಿಸಿ ಇಂಟರ್ಫೇಸ್ ಮಾಯವಾದಾಗ ಅವುಗಳನ್ನು ಬಿಡುತ್ತದೆ. ಎರಡನೆಯದು ಯಾವುದೋ ತೆಗೆದುಹಾಕುವವರೆಗೆ ಉಳಿಯುವ ದಾಖಲೆಗಳನ್ನು ಇರಿಸುತ್ತದೆ. ಮೂರನೆಯದು ಫೈಲ್ ಬರೆದು ಮರುಸ್ಥಾಪನೆಯನ್ನು ಅದನ್ನು ಬರೆದವರಿಗೆ ಬಿಡುತ್ತದೆ.
ದುರಸ್ತಿ ಆಜ್ಞೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ಗುರುತಿಸಿ. ಅದೇ ಲಕ್ಷಣಕ್ಕೆ ಯಾವುದು ಬಳಕೆಯಲ್ಲಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಸರಿಯಾದ ಉತ್ತರಗಳಿವೆ.
NetworkManager ನಿರ್ವಹಿಸುವ VPN ಈಗಾಗಲೇ ರಿಸಾಲ್ವರ್ ಬದಲಾವಣೆಗಳ ಮಾಲೀಕರಾಗಿರಬಹುದು. ಅದರ ಮೇಲೆ ಎರಡನೇ ಸಹಾಯಕ ಸೇರಿಸಿದರೆ ಅದೇ ಲಿಂಕ್ಗಾಗಿ ಸ್ಪರ್ಧಿಸುವ ಇಬ್ಬರು ಮಾಲೀಕರು ಉಂಟಾಗುತ್ತಾರೆ, ಮತ್ತು ಸೋತವರ ಸ್ಥಿತಿ ಮುಂದಿನ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಮತ್ತೆ ಕಾಣಿಸುತ್ತದೆ. ನಿರ್ವಾಹಕ ಜವಾಬ್ದಾರನಾಗಿದ್ದರೆ, ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ಅಲ್ಲ, ನಿರ್ವಾಹಕದಲ್ಲಿ ಸರಿಪಡಿಸಿ.
down ಹುಕ್ ಏನು ಮಾಡಬಹುದು ಮತ್ತು ಏನು ಮಾಡಲಾಗದು
ಸ್ಕ್ರಿಪ್ಟ್ down TUN/TAP ಸಾಧನ ಮುಚ್ಚಿದ ನಂತರ ಒಮ್ಮೆ ಚಲಿಸುತ್ತದೆ. ಸೇರಿಸಿದಾಗ down-pre ಆ ಕ್ರಮವನ್ನು ತಿರುಗಿಸಿ ಸಾಧನ ಇನ್ನೂ ಇರುವಾಗ ಸ್ಕ್ರಿಪ್ಟ್ ಚಲಾಯಿಸುತ್ತದೆ, ಇದನ್ನು ಜೀವಂತ ಲಿಂಕ್ ಬೇಕಾದ ಸಹಾಯಕರು ಕೇಳುತ್ತಾರೆ.
ಯಾವುದೇ ಸೂಚನೆ ಹುಕ್ ಅನ್ನು SIGKILL ನಂತರ ಚಲಾಯಿಸುವಂತೆ ಮಾಡುವುದಿಲ್ಲ. ಸವಲತ್ತುಗಳು ಸಹ down-pre ಮೂಲಕ ಮರುಸ್ಥಾಪಿಸಲ್ಪಡುವುದಿಲ್ಲ: ಡೀಮನ್ user ಅಥವಾ group ಮಟ್ಟಕ್ಕೆ ಇಳಿದರೆ ಅಥವಾ chroot ಒಳಗೆ ಪ್ರವೇಶಿಸಿದರೆ, ಹುಕ್ ಅದು ಬಿಡುವ ಪ್ರವೇಶದೊಂದಿಗೆ ಚಲಿಸುತ್ತದೆ. ಕರೆಯಲಾದ ಹುಕ್ ಆದರೂ ರಿಸಾಲ್ವರ್ ನವೀಕರಿಸಲು ವಿಫಲವಾಗಬಹುದು. OpenVPN ಉಲ್ಲೇಖ ಸಿಗ್ನಲ್ಗಳು ಮತ್ತು ಕಾಲ್ಬ್ಯಾಕ್ ಜೀವನಚಕ್ರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.
ಪ್ರಕ್ರಿಯೆಯ ನಿರ್ಗಮನ ಸ್ಥಿತಿಯ ಜೊತೆಗೆ ಹುಕ್ಕಿನ ಸ್ವಂತ ದೋಷವನ್ನು ಪರಿಶೀಲಿಸಿ. ಕಾಣೆಯಾದ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಮತ್ತು ವಿಫಲವಾದ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ರಿಸಾಲ್ವರ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಲಾಗ್ಗಳಲ್ಲಿ ಬೇರೆ ರೀತಿ.
ನಿಜವಾಗಿ ಉಳಿದಿರುವ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ
systemd-resolved ಬಳಸುವ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, resolvectl status ಯಾವ ಲಿಂಕ್ ಇನ್ನೂ VPN DNS ಸರ್ವರ್ಗಳನ್ನು ಅಥವಾ ರೂಟಿಂಗ್ ಡೊಮೇನ್ಗಳನ್ನು ಹೊತ್ತಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಆ ಲಿಂಕ್ ಹೋದ ಸಂಪರ್ಕದ್ದಾಗಿರಬಹುದು, ಅಥವಾ ಇನ್ನೂ ಎದ್ದಿರುವ ಇನ್ನೊಂದು ಟನೆಲ್ನದ್ದಾಗಿರಬಹುದು.
ಮಾಯವಾಗುವ ಇಂಟರ್ಫೇಸ್ ತನ್ನ ಪ್ರತಿ-ಲಿಂಕ್ ಸಂರಚನೆಯನ್ನು ಜೊತೆಗೆ ಒಯ್ಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಬಿಟ್ಟುಬಿಟ್ಟ ಹುಕ್ ಸ್ವಚ್ಛ DNS ಜೊತೆ ಇರಬಹುದು. ಲಿಂಕ್ ಇನ್ನೂ ನೋಂದಾಯಿತವಾಗಿದ್ದು ನಿಲ್ಲಿಸಿದ ಸಂಪರ್ಕಕ್ಕೆ ಮಾತ್ರ ಸೇರಿದ್ದರೆ, ಮಾಲೀಕ ನಿರ್ವಾಹಕ ಅದನ್ನು ತೆಗೆದುಹಾಕಬೇಕು. ಹಳೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಜಾಗತಿಕ ರಿಸಾಲ್ವರ್ ಫೈಲ್ ಮರುಬರೆದಿದ್ದರೆ, ಬದಲಿಗೆ ಆ ಸ್ಕ್ರಿಪ್ಟ್ನ ದಾಖಲಿತ ಮರುಸ್ಥಾಪನೆ ಹಂತವನ್ನು ಹುಡುಕಿ.
ಬೇರೆ ಲಿಂಕ್ ಕದಿಯದೆ ಮರುಪಡೆಯಿರಿ
ಪ್ರತಿ-ಲಿಂಕ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ನಿಮ್ಮ ನಿರ್ವಹಣೆಯಲ್ಲಿದ್ದಾಗ, resolvectl revert ಲಿಂಕ್ ಹೆಸರನ್ನು ತೆಗೆದುಕೊಂಡು ಆ ಇಂಟರ್ಫೇಸ್ನ ರನ್ಟೈಮ್ DNS ಸಂರಚನೆಯನ್ನು ಅಳಿಸುತ್ತದೆ. ಇದು ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆಯಲ್ಲ, ರನ್ಟೈಮ್ ಕ್ರಿಯೆ, ಆದ್ದರಿಂದ ನಿರಂತರ ಸಂಪರ್ಕ ಸಂರಚನೆ ಅಸ್ಪೃಶ್ಯವಾಗಿ ಉಳಿಯುತ್ತದೆ. ತಪ್ಪು ಲಿಂಕ್ ಹೆಸರಿಸಿದರೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಟನೆಲ್ನ DNS ಅನ್ನು ಅಳಿಸುತ್ತೀರಿ, ಆದ್ದರಿಂದ ಹೆಸರು ಸ್ಥಿತಿ ಔಟ್ಪುಟ್ನಿಂದ ಬರುತ್ತದೆ.
ಸಂಪಾದಿಸುವ ಮೊದಲು /etc/resolv.conf ನಿರ್ವಹಿತ ಸಿಂಬಾಲಿಕ್ ಲಿಂಕ್ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ಇನ್ನೊಮ್ಮೆ ಸಾಮಾನ್ಯವಾಗಿ ನಿಲ್ಲಿಸಿ ಮತ್ತು DNS ಅನ್ನು ಮತ್ತೆ ನೋಡಿ. ಎರಡನೇ ನಿಲುಗಡೆ ಸ್ವಚ್ಛಗೊಳಿಸಿದರೆ, ಹಿಂದಿನ ಸಮಸ್ಯೆ ಸಂರಚನೆಯಲ್ಲ, ಒತ್ತಾಯದ ನಿರ್ಗಮನವಾಗಿತ್ತು.