Linux ನಲ್ಲಿ ಲಾಗಿನ್ ಮೊದಲು SSTP ವಿಫಲವಾಗುತ್ತದೆಯೇ? ರನ್‌ಟೈಮ್ ಭಾಗಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಮೆನು ನಮೂದು ಏನನ್ನು ಸೇರಿಸುತ್ತದೆ, ಏನನ್ನು ಇಲ್ಲ

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

ನಂತರ ಕ್ಲೈಂಟ್‌ಗೆ PPP ಬೇಕು, ಏಕೆಂದರೆ SSTP TLS ಸಂಪರ್ಕದೊಳಗೆ PPP ಸೆಷನ್ ಸಾಗಿಸುತ್ತದೆ. pppd ಇಲ್ಲದೆ ಸುರಂಗವು TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸಿ ಸಹ ಮೊದಲ ನಿಯಂತ್ರಣ ಚೌಕಟ್ಟಿನಲ್ಲಿ ಸಾಯಬಹುದು, ಇದು ರುಜುವಾತುಗಳ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಅಲ್ಲ. Debian ಮತ್ತು Ubuntu ನಲ್ಲಿ ಭಾಗಗಳು network-manager-sstp, sstp-client ಮತ್ತು ppp ಆಗಿ ಬರುತ್ತವೆ, ಮತ್ತು ಕೇವಲ ಮೊದಲನೆಯದನ್ನು ಸ್ಥಾಪಿಸುವುದು ಫಾರ್ಮ್ ಪ್ರತಿ ಕ್ಷೇತ್ರವನ್ನು ಸ್ವೀಕರಿಸಿ ಸಂಪರ್ಕ ಎಂದಿಗೂ ಮುಗಿಯದಿರುವ ಸಾಮಾನ್ಯ ಕಾರಣ.

ಡೆಸ್ಕ್‌ಟಾಪ್ ಆಯ್ಕೆ ಇನ್ನೊಂದು ವಿಭಜನೆ ಸೇರಿಸುತ್ತದೆ. Plasma ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು plasma-nm ಮೂಲಕ ಸಂಪಾದಿಸುತ್ತದೆ, ಅದಕ್ಕೆ ತನ್ನದೇ SSTP ಘಟಕ ಬೇಕು ಮತ್ತು ಅದೇ ಸೇವಾ ವಿವರಣೆಯನ್ನು ಓದುತ್ತದೆ, ಆದ್ದರಿಂದ SSTP ನಮೂದು ಇಲ್ಲದ ಸಂಪಾದಕ ಮತ್ತು ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಚೆನ್ನಾಗಿ ರಚಿಸುವ CLI ಮುರಿದ ರನ್‌ಟೈಮ್ ಅಲ್ಲ, ಬದಲಿಗೆ ಸಂಪಾದಕದ ಅರ್ಧ ಭಾಗ ಕಾಣೆಯಾಗಿದೆ.

ಏನನ್ನೂ ಮರುಸ್ಥಾಪಿಸುವ ಮೊದಲು ಮೊದಲ ವಿಫಲ ಹಂತವನ್ನು ಓದಿ

ವಿಫಲ SSTP ಪ್ರಯತ್ನವು ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಹಂತಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಮತ್ತು ವಿಫಲವಾದ ಹಂತ ಯಾವ ಘಟಕವನ್ನು ನೋಡಬೇಕೆಂದು ಹೇಳುತ್ತದೆ.

ಪ್ಲಗಿನ್ ಪ್ರಾರಂಭಿಸುವುದು ಮೊದಲನೆಯದು, ಮತ್ತು ಅಲ್ಲಿ ವಿಫಲತೆ ಸರ್ವರ್ ಬಗ್ಗೆ ಅಲ್ಲ, VPN ಸೇವೆ ಬಗ್ಗೆ ಸಂದೇಶ ನೀಡುತ್ತದೆ. ನಂತರ ಪೋರ್ಟ್ 443 ಗೆ TCP ಸಂಪರ್ಕ ಬರುತ್ತದೆ; ಇಲ್ಲಿ ನಿರಾಕರಣೆ ಅಥವಾ ಸಮಯ ಮೀರುವಿಕೆ ತಲುಪುವಿಕೆಯ ಸಮಸ್ಯೆ, TLS ನದಲ್ಲ. ನಂತರ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ಸರ್ವರ್ ಗುರುತು ಪರಿಶೀಲನೆ, ನಂತರ PPP ಮಾತುಕತೆ ಮತ್ತು ಖಾತೆ ದೃಢೀಕರಣ, ಮತ್ತು ಕೊನೆಗೆ ವಿಳಾಸ ಹಂಚಿಕೆ ಮತ್ತು ಮಾರ್ಗಗಳು. ಪ್ರೊಫೈಲ್ ಒಮ್ಮೆ ಸಕ್ರಿಯಗೊಳಿಸುವಾಗ journalctl -f -u NetworkManager ವೀಕ್ಷಿಸಿ, ಮತ್ತು ಕೊನೆಯ ಸಾಮಾನ್ಯ ಸಾಲಿನ ಬದಲು ಮೊದಲ ನಿರ್ದಿಷ್ಟ ಸಾಲನ್ನು ಓದಿ.

ಆ ಕ್ರಮವು ಸಾಮಾನ್ಯ ತಪ್ಪು ಓದುವಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಯಾವುದೇ ರುಜುವಾತು ಕಳುಹಿಸುವ ಮೊದಲೇ ಪ್ರಮಾಣಪತ್ರದ ದೂರು ವರದಿಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಪಾಸ್‌ವರ್ಡ್ ಬದಲಾಯಿಸುವುದು ಸಹಾಯ ಮಾಡಲಾರದು; PPP ದೃಢೀಕರಣ ನಿರಾಕರಣೆ ಯಶಸ್ವಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಂತರ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಮಾಣಪತ್ರ ಬದಲಾಯಿಸುವುದೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಮೊದಲ ದೋಷ ಮತ್ತು ಅದರ ಹಂತವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಆಗ ಲಕ್ಷಣವಲ್ಲ, ನಿದಾನ ಸಿಗುತ್ತದೆ.

ಪ್ರಮಾಣಪತ್ರದ ಮೇಲಿನ ನಂಬಿಕೆ ಮತ್ತು ಖಾತೆ ಲಾಗಿನ್ ಬೇರೆ ಬೇರೆ ದ್ವಾರಗಳು

ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸರ್ವರ್ ನೀವು ತಲುಪಲು ಉದ್ದೇಶಿಸಿದ್ದೇ ಎಂದು ನೀವು ಸಂರಚಿಸಿದ ನೀಡುವವ ಮತ್ತು ಹೆಸರನ್ನು ಬಳಸಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದರ ನಂತರವೇ PPP ಪದರ ನಿಮ್ಮ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಗೇಟ್‌ವೇಯ ದೃಢೀಕರಣ ವಿಧಾನಕ್ಕೆ ನೀಡುತ್ತದೆ. ಹಾಗಾದರೆ ಎರಡು ಸ್ವತಂತ್ರ ಪರಿಶೀಲನೆಗಳು, ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತವೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳು. ಪಾಸ್‌ವರ್ಡ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಯಾವುದೂ ಮೊದಲನೆಯದನ್ನು ಪ್ರಭಾವಿಸಲಾರದು.

ತಪ್ಪು ನೀಡುವವನನ್ನು ನಂಬುವ ಪ್ರೊಫೈಲ್ ಮೊದಲ ಗೇಟ್‌ನಲ್ಲಿ ಗುರುತು ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಅವನನ್ನು ಸರಿಯಾಗಿ ನಂಬಿ ಹಳೆಯ ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಿಸುವ ಪ್ರೊಫೈಲ್ ಎರಡನೆಯ ಗೇಟ್‌ನಲ್ಲಿ ದೃಢೀಕರಣ ನಿರಾಕರಣೆಯೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡೂ ಸಂಪರ್ಕಿಸದ VPN ನಂತೆ ಕಾಣುತ್ತವೆ, ಮತ್ತು ಒಂದನ್ನೂ ಇನ್ನೊಂದರ ಔಷಧದಿಂದ ಸರಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ.

ಸಂಪಾದಕದ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಊಹಿಸುವ ಬದಲು ಗೇಟ್‌ವೇ ನಿರ್ವಹಿಸುವವರಿಂದ ನಿರೀಕ್ಷಿತ ನೀಡುವವ ಮತ್ತು ಸರ್ವರ್ ಹೆಸರನ್ನು ಪಡೆಯಿರಿ, ಮತ್ತು ಅವರು ಬೇಡುವ ದೃಢೀಕರಣ ವಿಧಾನವನ್ನು ದಾಖಲಿಸಿ. ಸಂಸ್ಥೆಗೆ ಪ್ಲಗಿನ್ ವ್ಯಕ್ತಪಡಿಸಲಾಗದ ವಿಧಾನ ಬೇಕಾದರೆ, ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ ಅದನ್ನು ಮಾಡಬಲ್ಲ ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್, ದೋಷ ಮಾಯವಾಗಲು ಪರಿಶೀಲನೆ ನಿಲ್ಲಿಸಿದ ಪ್ರೊಫೈಲ್ ಅಲ್ಲ.

ಪ್ರೊಫೈಲ್ ಮತ್ತು ರಹಸ್ಯಗಳ ಮಾಲೀಕ ಒಬ್ಬರೇ ಇರಲಿ

ಪ್ರೊಫೈಲ್ ಇದ್ದ ಮೇಲೆ ಅದನ್ನು NetworkManager ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸಿ ಮತ್ತು ಉಂಟಾಗುವ ಮಾರ್ಗಗಳು ಹಾಗೂ ರಿಜಾಲ್ವರ್ ಬದಲಾವಣೆಗಳ ಮಾಲೀಕತ್ವವನ್ನು ಆ ನಿರ್ವಾಹಕನಿಗೆ ಬಿಡಿ. NetworkManager ಈಗಾಗಲೇ ಸಂಪರ್ಕ ನಡೆಸುತ್ತಿರುವಾಗ ಎರಡನೇ ಸ್ವತಂತ್ರ SSTP ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸಿದರೆ ನಿಮಗೆ ಎರಡು ಮಾರ್ಗ ಸೆಟ್‌ಗಳು, ಎರಡು DNS ಸಂರಚನೆಗಳು ಮತ್ತು ಒಂದೇ ಸತ್ಯ ಮೂಲವಿಲ್ಲದ ಡೀಬಗ್ ಸೆಷನ್ ಸಿಗುತ್ತದೆ.

ರಹಸ್ಯಗಳಿಗೂ ಮಾಲೀಕರಿದ್ದಾರೆ. ಸಿಸ್ಟಂ-ವ್ಯಾಪಿ ಬಳಕೆಗೆ ಗುರುತಿಸಿದ ಸಂಪರ್ಕವು ರುಜುವಾತುಗಳನ್ನು ನಿಮ್ಮ ಬಳಕೆದಾರ ಸೆಷನ್‌ಗೆ ಸೀಮಿತವಾದ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ಕೀ ಫೈಲ್‌ನಲ್ಲಿ ಕೈಯಿಂದ ರಚಿಸಿದ ಪ್ರೊಫೈಲ್ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗಿ ಒದಗಿಸುವ ನಿರೀಕ್ಷೆಯಿರುವ ರಹಸ್ಯ ಏಜೆಂಟ್‌ಗೆ ಓದಲಾಗದಿರಬಹುದು. ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗದ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಮತ್ತೆ ಟೈಪ್ ಮಾಡುವ ಮೊದಲು ಪ್ರೊಫೈಲ್ ಯಾವ ಸಂದರ್ಭವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅದೇ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಟರ್ಮಿನಲ್‌ನಿಂದ nmcli ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಅತ್ಯಂತ ವೇಗದ ಪರೀಕ್ಷೆ, ಏಕೆಂದರೆ ಎಂದಿಗೂ ಬಾರದ ಪ್ರಾಂಪ್ಟ್ ಏಜೆಂಟ್‌ಗೆ ಈಗಾಗಲೇ ನೀಡಲು ಏನೂ ಇರಲಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ.

ಸುರಂಗ, ಮಾರ್ಗಗಳು ಮತ್ತು ರಿಜಾಲ್ವರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

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

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

ಕೊನೆಯದಾಗಿ, ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಒಮ್ಮೆ ರೀಬೂಟ್ ಮಾಡಿ. ಪ್ರೊಫೈಲ್ ಮೊದಲ ಪ್ರಯತ್ನದಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಿದರೆ, ಸಮಸ್ಯೆ ರಹಸ್ಯ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಅಥವಾ ಮಾರ್ಗ ಮಾಲೀಕತ್ವದಲ್ಲಿದೆ, ಮತ್ತು ಎರಡನ್ನೂ ಈಗ ಸರಿಪಡಿಸುವುದು ಕೆಲಸದ ದಿನದ ಮಧ್ಯದಲ್ಲಿ ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ಅಗ್ಗ.