OpenVPN ನಲ್ಲಿ ಮೊದಲೇ ರಚಿಸಿದ tun: ಎರಡು ಮಾಲೀಕತ್ವ ಮಾದರಿಗಳ ಹೋಲಿಕೆ

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

ಹೆಸರು ಜೋಡಣೆಯಲ್ಲ

dev tun1 OpenVPN ಬಳಿ ಆ ಹೆಸರಿನ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ ಯೂಸರ್-ಸ್ಪೇಸ್ ಬಿಲ್ಡ್ಗಳು ಅದನ್ನು ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಹೆಸರು ಸಾಮಾನ್ಯ tun ಅಥವಾ tap ಮಾದರಿಯನ್ನು ಅನುಸರಿಸದಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ಗೆ ಹೊಂದುವ dev-type ಕೂಡ ಬೇಕು, ಏಕೆಂದರೆ ಪ್ರಕಾರವನ್ನು ಎಂದಿಗೂ ಸ್ಟ್ರಿಂಗ್ನಿಂದ ಊಹಿಸಲಾಗುವುದಿಲ್ಲ. TAP ಸಾಧನವು ಬೇರೆ ಲೇಬಲ್ನ TUN ಸಾಧನವಲ್ಲ: ತಪ್ಪಾದದನ್ನು ಜೋಡಿಸಿದರೆ ಒಂದೋ ನೇರವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ, ಅಥವಾ ಯಾರೂ ನಿರೀಕ್ಷಿಸದ ಫ್ರೇಮ್ಗಳನ್ನು ಸಾಗಿಸುವ ಲಿಂಕ್ ಉಂಟಾಗುತ್ತದೆ. ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲು ಪ್ರಕಾರವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ನಂತರದ ಪರಿಶೀಲನೆಯೂ ಎರಡೂ ಕಡೆಗಳು ಅದರ ಬಗ್ಗೆ ಒಪ್ಪಿಗೆಯಲ್ಲಿವೆ ಎಂದು ಊಹಿಸುತ್ತದೆ. ನಂತರ, ಪ್ರಕ್ರಿಯೆಯು ಸಾಧನವನ್ನು ನಿಜವಾಗಿ ತೆರೆಯಬಲ್ಲದು ಎಂದು ಖಚಿತಪಡಿಸಿ, ಕೇವಲ ನೋಡುವುದಲ್ಲ.

dev tun1
dev-type tun

ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು /dev/net/tun ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು: ಒಂದು ನೇಮ್ಸ್ಪೇಸ್ನೊಳಗಿನ ಲಿಂಕ್, ಇನ್ನೊಂದು ಯೂಸರ್-ಸ್ಪೇಸ್ ಪ್ರೋಗ್ರಾಂ ಜೋಡಣೆಗೆ ಬಳಸುವ ಅಕ್ಷರ ಸಾಧನ. Linux TUN/TAP ದಾಖಲೆ ಆ ಜೋಡಣೆ ಮಾರ್ಗ ಮತ್ತು ಶಾಶ್ವತ ಸಾಧನಗಳ ಮಾಲೀಕತ್ವ ನಿಯಮಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ip link ಚಲಾಯಿಸಬಲ್ಲ root ಶೆಲ್ ಶೆಲ್ಗೆ ಸವಲತ್ತುಗಳಿವೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಡೀಮನ್ಗೆ ಇವೆ ಎಂದಲ್ಲ. ಸಾಧನ ನೋಡ್ನ ಮಾಲೀಕತ್ವ, ಸೇವೆಯ ಸಾಮರ್ಥ್ಯಗಳ ಗುಂಪು ಮತ್ತು ಅದು ಯಾವ ಬಳಕೆದಾರನಾಗಿ ಚಲಿಸುತ್ತದೆ — ಎಲ್ಲವೂ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ತೆರೆಯುವಿಕೆ ಯಶಸ್ವಿಯಾಗುವ ಮೊದಲು.

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

ಲಿಂಕ್ ಅನ್ನು ಯಾರು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತಾರೆ: ಎರಡು ಮಾಲೀಕತ್ವ ಮಾದರಿಗಳು

ಮೊದಲ ಮಾದರಿಯಲ್ಲಿ OpenVPN ಸಂಪರ್ಕವನ್ನು ಎತ್ತುವ ಭಾಗವಾಗಿ ವಿಳಾಸಗಳು ಮತ್ತು ಮಾರ್ಗಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಇದು ಡೀಫಾಲ್ಟ್ ವರ್ತನೆ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದದ್ದು, ಏಕೆಂದರೆ ಒಂದೇ ಘಟಕ ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸಿ ಮತ್ತೆ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಎರಡನೇ ಮಾದರಿಯಲ್ಲಿ ಬಾಹ್ಯ ನಿರ್ವಾಹಕರು ಇಂಟರ್ಫೇಸ್ನ ಮಾಲೀಕರು, ಮತ್ತು ifconfig-noexec OpenVPN ತನ್ನ ವಿಳಾಸ ಕಾನ್ಫಿಗರೇಶನ್ ಆದೇಶಗಳನ್ನು ಚಲಾಯಿಸದಂತೆ ತಡೆದು ನಿಯತಾಂಕಗಳನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ಗಳಿಗೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಆಗ ನಿರ್ವಾಹಕರು ಸರಿಯಾದ ಸ್ಥಳೀಯ ಮತ್ತು ಸಹವರ್ತಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತಾವೇ ಅನ್ವಯಿಸಬೇಕು, ಇದು ಆಯ್ಕೆಯ ಹೆಸರು ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೆಲಸ. ಎರಡರ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಲಿಂಕ್ ಎತ್ತಿರುವಾಗ ಅದನ್ನು ಯಾರು ಬದಲಾಯಿಸಬಹುದು ಎಂಬ ಪ್ರಶ್ನೆ.

ifconfig-noexec ವಿಳಾಸಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುತ್ತದೆ: ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಅಸ್ಪೃಷ್ಟವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಮಾರ್ಗಗಳ ಕಾನ್ಫಿಗರೇಶನ್ route-noexec ಗೆ ಸೇರಿದೆ. ಎರಡೂ ನಿರ್ದೇಶನಗಳನ್ನು ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಮಾಲೀಕರೊಂದಿಗೆ ಪರಿಗಣಿಸಿ, ಏಕೆಂದರೆ ಒಂದನ್ನು ಹೊಂದಿಸಿ ಇನ್ನೊಂದನ್ನು ಊಹಿಸುವುದು ಅರ್ಧ-ಕಾನ್ಫಿಗರ್ ಆದ ಲಿಂಕ್ಗಳ ಸಾಮಾನ್ಯ ಮೂಲ. ಪ್ರತಿ ಪದರಕ್ಕೂ ನಿಖರವಾಗಿ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ಆಯ್ಕೆಮಾಡಿ, ವಿಳಾಸಗಳು ಒಂದೆಡೆ ಮತ್ತು ಮಾರ್ಗಗಳು ಒಂದೆಡೆ. ನೆಟ್ವರ್ಕ್ ನಿರ್ವಾಹಕ ಮತ್ತು VPN ಸಹಾಯಕ ಇಬ್ಬರೂ ವಿಳಾಸಗಳನ್ನು ಬರೆದರೆ, ಸಂಪರ್ಕ ಕಡಿತವು ಇನ್ನೊಂದು ಕಡೆ ಇನ್ನೂ ಅವಲಂಬಿಸಿರುವ ಸ್ಥಿತಿಯನ್ನು ಅಳಿಸುತ್ತದೆ.

ಮುಖ್ಯವಾದ ನೇಮ್ಸ್ಪೇಸ್ನಿಂದ ಸಾಧನವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ip -details link show dev tun1
ip tuntap show

ಮೊದಲ ಆದೇಶವು ಲಿಂಕ್ ಅನ್ನು ಕರ್ನೆಲ್ ನೋಡುವಂತೆ ಮುದ್ರಿಸುತ್ತದೆ, ಫ್ಲ್ಯಾಗ್ಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಪ್ರಕಾರ ಸೇರಿದಂತೆ, ಮತ್ತು ಹೀಗೆ ಇದೇ ನೀವು ಉದ್ದೇಶಿಸಿದ ಸಾಧನ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತೀರಿ. ಎರಡನೆಯದು ಶಾಶ್ವತ tun/tap ನಮೂದುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಅವು ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆ ಹಿಡಿದಿಲ್ಲದೆಯೂ ಇರುತ್ತವೆ. ತನ್ನ ನಿಗದಿತ ಮಾಲೀಕನಿಗಾಗಿ ಕಾಯುತ್ತಿರುವ ಇಂಟರ್ಫೇಸ್ ಬೇರೆ VPN ಗೆ ಜೋಡಿಸಿದ ಜೀವಂತ ಸುರಂಗಕ್ಕಿಂತ ಬೇರೆ ಪರಿಸ್ಥಿತಿ, ಮತ್ತು ನಿಮ್ಮದೇ ಜೋಡಣೆ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ಎರಡನೆಯದು ಮಾತ್ರ ವಿವರಿಸುತ್ತದೆ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಸಾಧನವನ್ನು ಹಿಡಿದಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಶಾಶ್ವತ ನಮೂದು ಮತ್ತು ನಿರತ ಇಂಟರ್ಫೇಸ್ಗೆ ಬೇರೆ ಬೇರೆ ಪರಿಹಾರಗಳಿವೆ.

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

ಎರಡು ರೀತಿಯ ಶಾಶ್ವತತೆ

ಕರ್ನೆಲ್ ಶಾಶ್ವತತೆ ಮತ್ತು persist-tun ಗೊಂದಲಕ್ಕೀಡಾಗಲು ಸುಲಭ ಮತ್ತು ತಪ್ಪಾದರೆ ದುಬಾರಿಯಾದ ಜೀವಿತಾವಧಿಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಶಾಶ್ವತ ಸಾಧನವು ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಲುಗಡೆಯನ್ನು ದಾಟಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಆರಂಭ ಅದನ್ನು ಮತ್ತೆ ಬಳಸಬಹುದು. persist-tun ಒಂದೇ OpenVPN ಪ್ರಕ್ರಿಯೆಯೊಳಗೆ ಬೆಂಬಲಿತ ಮೃದು ಮರುಹೊಂದಿಕೆಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಬಹಳ ಚಿಕ್ಕ ದಿಗಂತ. ಎರಡೂ ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಿದರೆ ಮಾರ್ಗಗಳು ಮತ್ತು ವಿಳಾಸಗಳು ಅಲ್ಲಿಯೇ ಉಳಿಯುತ್ತವೆ ಎಂದು ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಕಾಣುವ ಇಂಟರ್ಫೇಸ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಗೂಢಲಿಪೀಕೃತ ಅಧಿವೇಶನದ ಸಾಕ್ಷಿಯಲ್ಲ.

ಬ್ಯಾಕೆಂಡ್ ಅನ್ನೂ ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲೇ ರಚಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಯಾವ ಅನುಷ್ಠಾನ ಅದನ್ನು ತೆರೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ನೇರ ಡೇಟಾ ಮಾರ್ಗವನ್ನು ಹೊತ್ತಿರುವ ಸಮುದಾಯ ಬಿಲ್ಡ್ಗಳು ವಿನ್ಯಾಸ ಬೇರೆ ಹೇಳದಿದ್ದರೆ ಅದನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಆವೃತ್ತಿ ಸ್ವಿಚ್ ಅನ್ನು ಬೆಂಬಲಿಸುವಲ್ಲಿ, disable-dco ಬದಲಿಗೆ ಯೂಸರ್-ಸ್ಪೇಸ್ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ; ಹಳೆಯ ಎಂಜಿನ್ಗಳು ಮತ್ತು ಇತರ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಅಂತಹ ನಿರ್ದೇಶನವಿಲ್ಲ, ಆದ್ದರಿಂದ ಆವೃತ್ತಿಯ ಷರತ್ತನ್ನು ಆಯ್ಕೆಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಅದು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸಬೇಡಿ.

ಕೇವಲ ಆರಂಭವನ್ನು ಪರೀಕ್ಷಿಸಿದರೆ ಏನು ಮುರಿಯುತ್ತದೆ

ಮಾಲೀಕತ್ವದ ಒಪ್ಪಂದವು ಮೊದಲ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿ ಕೊನೆಯದರಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಇದು ಆರಂಭವನ್ನು ಒಂಟಿಯಾಗಿ ದುರ್ಬಲ ಪರಿಶೀಲನೆಯನ್ನಾಗಿಸುತ್ತದೆ. ಬದಲಿಗೆ ಎರಡು ಪರಿವರ್ತನೆಗಳನ್ನು ಗಮನಿಸಿ: ಮೃದು ಮರುಹೊಂದಿಕೆ, ಮತ್ತು ಪೂರ್ಣ ನಿಲುಗಡೆಯ ನಂತರದ ಆರಂಭ.

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

ಮೃದು ಮರುಹೊಂದಿಕೆಯು ಅಧಿವೇಶನವನ್ನು ಬಳಸಬಹುದಾಗಿ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಾನಿಯಾಗದಂತೆ ಬಿಡಬೇಕು, ಮತ್ತು ಆ ಕೆಲಸವನ್ನೇ persist-tun ಮಾಡುತ್ತದೆ. ಪೂರ್ಣ ನಿಲುಗಡೆ ಎಂಬುದು ಬಾಹ್ಯ ನಿರ್ವಾಹಕ ತನ್ನನ್ನು ಬಯಲು ಮಾಡುವ ಸ್ಥಳ: ಲಿಂಕ್ ಅಥವಾ ಅದರ ವಿಳಾಸಗಳು ನಿಲುಗಡೆಯನ್ನು ದಾಟಿ ಉಳಿದರೆ, ಅವು ಬೇರೆ ಯಾರಿಗೋ ಸೇರಿವೆ, ಮತ್ತು ಅದು ನೀವು ದಾಖಲಿಸಿದ ಸ್ಥಿತಿಯೋ ಅಥವಾ ಈಗಷ್ಟೇ ಕಂಡುಕೊಂಡ ದೋಷವೋ. ಎರಡೂ ವೀಕ್ಷಣೆಗಳನ್ನು ಪ್ರೊಫೈಲ್ನ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಮುಂದಿನ ಬದಲಾವಣೆ ರೇಖಾಚಿತ್ರದಿಂದಲ್ಲ, ಸಾಕ್ಷ್ಯದಿಂದ ಆರಂಭವಾಗಲಿ.