OpenVPN ಇನ್ನೂ ಹಳೆಯ ರೂಟ್ಗಳನ್ನು ತಳ್ಳುತ್ತಿದೆಯೇ? ಅದು ಏನನ್ನು ಲೋಡ್ ಮಾಡಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

ಕೆಳಗಿನ ಹೋಲಿಕೆ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಹೊರಕ್ಕೆ ಸಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾವ ಫೈಲ್ ಜಾರಿಯಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಪ್ರಕ್ರಿಯೆಯೇ ನಿರ್ಧರಿಸುತ್ತದೆ.

ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಮತ್ತು ಪ್ರಕ್ರಿಯೆ ಓದುವ ಫೈಲ್

unit ಮತ್ತು ಅದು ರಚಿಸಿದ ಆಜ್ಞಾ ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ. systemd ಹೋಸ್ಟ್ನಲ್ಲಿ systemctl cat openvpn@server ExecStart ಸಾಲನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು instance unit ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನ ಸಂರಚನಾ ಮಾರ್ಗವನ್ನು instance ಹೆಸರಿನಿಂದ ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ openvpn@office ಆಗಿ ಪ್ರಾರಂಭಿಸಿದ ಡೀಮನ್ openvpn@server ಆಗಿ ಪ್ರಾರಂಭಿಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ ಫೈಲ್ ಓದುತ್ತದೆ. ಇದನ್ನು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯ argv ಜೊತೆ ಹೋಲಿಸಿ. ಸಂರಚನಾ ನಿರ್ವಹಣಾ ಸಾಧನವು ಬದಲಾವಣೆ ಕಳೆದುಕೊಳ್ಳುವ ಇನ್ನೊಂದು ದಾರಿ ಸೇರಿಸುತ್ತದೆ: ಅದು ಸರಿಯಾದ ಫೈಲ್ ಅನ್ನು unit ಎಂದೂ ಉಲ್ಲೇಖಿಸದ ಸ್ಥಳದಲ್ಲಿ ಬರೆಯಬಹುದು, ಆಗ ಯಶಸ್ವಿ ನಿಯೋಜನೆ ಏನೂ ಮಾಡದಂತೆ ಕಾಣುತ್ತದೆ.

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

ಸರ್ವರ್ ಏನನ್ನು ತಳ್ಳುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ

ತಳ್ಳಲಾದ ರೂಟ್ ಎರಡು ಫಿಲ್ಟರ್ಗಳನ್ನು ದಾಟಬೇಕು. ಸರ್ವರ್ನಲ್ಲಿ ಅದು ಲೋಡ್ ಆದ ಸಂರಚನೆಯಲ್ಲಿ ಇರಬೇಕು, ಕಾಮೆಂಟ್ ಮಾಡಿದ ಬ್ಲಾಕ್ನಲ್ಲಿ ಅಥವಾ ಹೆಸರು ಹೊಂದಿಕೆಯಾಗದ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಫೈಲ್ನಲ್ಲಿ ಅಲ್ಲ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ pull ಸಕ್ರಿಯವಾಗಿರಬೇಕು ಮತ್ತು ಯಾವ pull-filter ಆಯ್ಕೆಯನ್ನು ಬಿಸಾಡಬಾರದು. verbosity 4 ಜೊತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ವರದಿ ಮಾಡುವ ತಳ್ಳಲಾದ ಆಯ್ಕೆಗಳನ್ನು ಓದಿ: ರೂಟ್ ಆ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸಿದರೆ, ಸರ್ವರ್ ತನ್ನ ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಅದನ್ನು ಸ್ಥಾಪಿಸದಿರಲು ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತಿದೆ.

ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಫೈಲ್ಗಳು ಗೊಂದಲದ ಸಾಮಾನ್ಯ ಮೂಲ. ಪ್ರಮಾಣಪತ್ರದ common name ನಿಂದ ಹೆಸರಿಸಿದ ಫೈಲ್ ಆಯ್ಕೆಗಳನ್ನು ಆ ಕ್ಲೈಂಟ್ಗೆ ಮಾತ್ರ ತಳ್ಳುತ್ತದೆ, ಮತ್ತು ಒಂದು ಅಕ್ಷರದ ವ್ಯತ್ಯಾಸ ತಳ್ಳುವಿಕೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ನಿಲ್ಲಿಸುತ್ತದೆ, ಎರಡೂ ಕಡೆ ದೋಷ ಕಾಣಿಸುವುದಿಲ್ಲ. ಸರ್ವರ್ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಕಂಡ common name ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಮೌಲ್ಯವನ್ನು ಫೈಲ್ ಹೆಸರಿನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಕ್ಲೈಂಟ್ನ ಹೆಸರು ಎಂದು ನೀವು ಭಾವಿಸುವುದರೊಂದಿಗೆ ಅಲ್ಲ.

ತಳ್ಳಲಾದ ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು

ತನ್ನ ಸ್ಥಳೀಯ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು redirect-gateway ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್ ಎರಡನೇ, ಸಂಬಂಧವಿಲ್ಲದ ಕೊರತೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಸರ್ವರ್ನ ಪ್ರೋಬ್ಗಳು ಟನಲ್ ವಿಳಾಸವನ್ನು ತಲುಪುತ್ತವೆ, ಆದರೆ ಉತ್ತರಗಳು ಎಂದೂ ಬರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸರ್ವರ್ನ ಟನಲ್ IP ಗೆ ಕಳುಹಿಸಿದ ಉತ್ತರವು ಕ್ಲೈಂಟ್ನ ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಮೂಲಕ ಮಾರ್ಗವಾಗುತ್ತದೆ. ಇಲ್ಲಿ ತಳ್ಳಲಾದ ಸಬ್ನೆಟ್ ರೂಟ್ ತಪ್ಪಲ್ಲ; ಇಲ್ಲದಿರುವುದು ಸರ್ವರ್ನ ಟನಲ್ ನೆಟ್ವರ್ಕ್ನ ಸಂಚಾರವನ್ನು ಟನಲ್ ಸಾಧನದ ಮೂಲಕ ಹಿಂತಿರುಗಿಸುವ ಮಾರ್ಗ.

ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಆ ರೂಟ್ ಸೇರಿಸುವುದು ಸರ್ವರ್ ಪ್ರಾರಂಭಿಸಿದ ಪ್ರೋಬ್ಗಳಿಗೆ ಉತ್ತರಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಅದು ತಳ್ಳಲಾದ ಸಬ್ನೆಟ್ ರೂಟ್ಗೆ ಪರ್ಯಾಯವಲ್ಲ, ಮತ್ತು ವಿಲೋಮವೂ ನಿಜ, ಏಕೆಂದರೆ ಎರಡೂ ವಿರುದ್ಧ ದಿಕ್ಕುಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಕೋಷ್ಟಕಗಳನ್ನು ಹೋಲಿಸಿ

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

ಮೂರು ಗುರುತುಗಳನ್ನು ಜೊತೆಯಾಗಿ ಇರಿಸಿ: ಸಂರಚನಾ ಮಾರ್ಗ, unit ಅಥವಾ instance ಹೆಸರು, ಮತ್ತು ನೀವು ಪರೀಕ್ಷಿಸಿದ ಕ್ಲೈಂಟ್ ಗುರುತು.

ಈ ಮೂರು ಮುಂದಿನ ಘಟನೆಯನ್ನು ಮತ್ತೊಂದು ತನಿಖೆಯ ಬದಲು ಐದು ನಿಮಿಷಗಳ ಪರಿಶೀಲನೆಯಾಗಿ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಟನಲ್ ಬೇರೆಯವರ ಸಮಸ್ಯೆಯಾದಾಗ ಸಹೋದ್ಯೋಗಿಗೆ ಬೇಕಾಗುವುದೂ ಇವೇ.

ಮರುಪ್ರಾರಂಭವನ್ನು ದಾಟಿ ಉಳಿಯುವ ರೂಟ್ ಸಮಸ್ಯೆ ಹಲವು ವೇಳೆ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯೇ ಅಲ್ಲ; ದೋಷ ನೀವು ಪದೇ ಪದೇ ಓದುವ ಕೋಷ್ಟಕದ ಮೇಲಿನ ಹಂತದಲ್ಲಿದೆ.