ಬೂಟ್ನಲ್ಲಿ SoftEther ಕ್ಲೈಂಟ್: AccountStartupSet ಮತ್ತು ಡೀಮನ್ ಕ್ರಮ

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

ಖಾತೆಯು ಸ್ವಯಂ ಪ್ರಾರಂಭಕ್ಕೆ ಗುರುತಿಸಲಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ

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

cd /opt/softether/vpnclient
./vpncmd

VPN ಕ್ಲೈಂಟ್ ನಿರ್ವಹಣೆಗಾಗಿ 2 ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು Enter ಒತ್ತಿ ಸ್ಥಳೀಯ ಸರ್ವರ್ ಒಪ್ಪಿಕೊಳ್ಳಿ.

AccountStartupSet
office-hub
exit

AccountStartupSet ಖಾತೆಯನ್ನು ಕ್ಲೈಂಟ್ ಸೇವೆ ಪ್ರಾರಂಭವಾದಾಗ ಮೇಲೇರಿಸಬೇಕಾದ ಖಾತೆಯಾಗಿ ದಾಖಲಿಸುತ್ತದೆ. ಅದು ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ ಅಥವಾ ಹೊಸ ಖಾತೆ ರಚಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹೆಸರು ತಪ್ಪಿದಾಗ ಉಪಯುಕ್ತ ಏನನ್ನೂ ಮುದ್ರಿಸುವುದಿಲ್ಲ. ಆದೇಶದ ನಂತರ ಖಾತೆಗಳ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಓದಿ, ಏಕೆಂದರೆ ಟೈಪಿಂಗ್ ತಪ್ಪು ಮೌನವಾಗಿರುತ್ತದೆ ಮತ್ತು ಜಾರಿಗೆ ಬಾರದ ಫ್ಲ್ಯಾಗ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ.

ಸೇವೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆಯೇ ಮತ್ತು ಸಾಕಷ್ಟು ಮುಂಚೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ

Linux ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಡೈರೆಕ್ಟರಿಯಿಂದ ಡೀಮನ್ ಆಗಿ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು ಬೂಟ್ನ ಯಾವುದೇ ಹಂತ ಖಾತೆ ಬಳಸಲು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಅದು ಚಾಲನೆಯಲ್ಲಿರಬೇಕು. ಡೈರೆಕ್ಟರಿ ಬದಲಿಸಿ ಅದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಸಣ್ಣ ಕೊಕ್ಕೆ ಇನ್ನೂ rc.local ಚಲಾಯಿಸುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸಾಕು.

cd /opt/softether/vpnclient
./vpnclient start

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

ಹಿಂದಿನ ಬೂಟ್ ಬಿಟ್ಟುಹೋದ pid ಕಡತವನ್ನು ನಂಬುವ ಬದಲು ಪ್ರಕ್ರಿಯೆಗಳ ಪಟ್ಟಿ ಪರಿಶೀಲಿಸಿ.

ಅಡಾಪ್ಟರ್ ವಿಳಾಸ ಪಡೆದಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಖಾತೆ ಸಂಪರ್ಕಗೊಂಡ ಕೂಡಲೇ ಕ್ಲೈಂಟ್ ವರ್ಚುವಲ್ ಅಡಾಪ್ಟರ್ ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಅಡಾಪ್ಟರ್ಗೆ ಇನ್ನೂ ವಿಳಾಸ ಬೇಕು. SecureNAT ಚಲಾಯಿಸುವ ಹಬ್ ಸಾಮಾನ್ಯವಾಗಿ DHCP ಗೆ ಉತ್ತರಿಸುತ್ತದೆ; ಭೌತಿಕ LAN ಗೆ ಸೇತುವೆ ಮಾಡಿದ ಹಬ್ ಬದಲಿಗೆ ಆ LAN ನ ಸರ್ವರ್ ಉತ್ತರಿಸುವುದನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ.

ip -brief address
dhclient vpn_vpn1

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

ವಿಳಾಸವಿಲ್ಲದ ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿಯಲ್ಲಿ ಅತ್ಯಂತ ಮೌನ ವೈಫಲ್ಯ, ಏಕೆಂದರೆ ಖಾತೆ ಇನ್ನೂ ಸಂಪರ್ಕವಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.

ಮಾರ್ಗ ನೀವು ಭಾವಿಸಿದ ಕಡೆಗೆ ಹೋಗುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ

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

ip route get 10.10.20.15

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

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

ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಪುನರ್ನಿರ್ಮಾಣ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಬರೆಯಿರಿ

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

ಫ್ಲ್ಯಾಗ್ ಮತ್ತೆ ಅನ್ವಯಿಸಲು ಒಂದು ಸಾಲು ಮತ್ತು ಮರೆಯುವುದು ಸುಲಭ.

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