PPTP ನಲ್ಲಿ LCP ಅನ್ನು ಪೀರ್ ಕೊನೆಗೊಳಿಸಿದೆ: ಮೊದಲು MPPE ಸಕ್ರಿಯಗೊಳಿಸಿ

ಲಿಂಕ್ ದೃಢೀಕರಣದ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ಸೆಕೆಂಡ್ ನಂತರ ಲಾಗ್ LCP ಅನ್ನು ಪೀರ್ ಕೊನೆಗೊಳಿಸಿದೆ ಎಂದು ಮುಚ್ಚುತ್ತದೆ. ಆ ಸಾಲು GRE ಸುರಂಗದೊಳಗಿನ PPP ಮಾತುಕತೆಯಿಂದ ಬರುತ್ತದೆ, ಅಂದರೆ ಸಾಗಣೆ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು ಮತ್ತು ಎರಡೂ ತುದಿಗಳು ಲಿಂಕ್ ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಒಪ್ಪಿರಲಿಲ್ಲ. ಗುಪ್ತಪದಗಳು ಮತ್ತು ಸರ್ವರ್ ವಿಳಾಸಗಳು ಇಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದೋಷಿ. ಎನ್ಕ್ರಿಪ್ಷನ್ ನೀತಿಯೇ ಮೊದಲು ಹೋಲಿಸಬೇಕಾದ ವಿಷಯ, ಮತ್ತು Linux ನಲ್ಲಿ pppd ನ ಪೀರ್ ಕಡತವೇ ಮೊದಲು ನೋಡಬೇಕಾದ ಸ್ಥಳ.

LCP ವೈಫಲ್ಯ PPP ಹಂತದ ಬಗ್ಗೆ ಏನು ಹೇಳುತ್ತದೆ

PPTP, PPP ಅನ್ನು GRE ಒಳಗೆ ಸುತ್ತುತ್ತದೆ: TCP 1723 ನಿಯಂತ್ರಣ ಸಂಪರ್ಕ ಕರೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ, GRE ಪೇಲೋಡ್ ಸಾಗಿಸುತ್ತದೆ, ನಂತರ LCP ದೃಢೀಕರಣ ಪ್ರೋಟೋಕಾಲ್, ಸಂಕೋಚನ ಮತ್ತು MPPE ಮುಂತಾದ ಆಯ್ಕೆಗಳನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ. ಅಗತ್ಯವಾದ ಆಯ್ಕೆಯು ಅವರ ಕಡೆ ಅಸ್ವೀಕಾರ್ಯವಾದಾಗ ಪೀರ್ LCP ಕೊನೆಗೊಳಿಸುತ್ತದೆ. CHAP ಅಥವಾ MSCHAPv2 ವಿನಿಮಯ ಪೂರ್ಣಗೊಂಡು ತಕ್ಷಣ LCP ಮುಗಿಯುವ ಲಾಗ್ ನೀತಿಯ ನಿರಾಕರಣೆ, ತಲುಪುವಿಕೆಯ ವೈಫಲ್ಯವಲ್ಲ. ಸುರಂಗವು ಮಾತುಕತೆಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಲುಪದಿದ್ದರೆ, LCP ಸಾಲನ್ನು ಓದುವ ಮೊದಲು pppd ಮತ್ತು ಅದರ ಪ್ಲಗಿನ್ ಪರಿಶೀಲಿಸಿ.

ಎರಡು ಪೂರ್ವಷರತ್ತುಗಳು ಸುಲಭವಾಗಿ ಕಣ್ಣಿಗೆ ಬೀಳುವುದಿಲ್ಲ. pppd ಬೈನರಿ ಇರಬೇಕು, ಮತ್ತು ಪೀರ್ ಕಡತದಲ್ಲಿ ಹೆಸರಿಸಿರುವ PPTP ಪ್ಲಗಿನ್ ಸ್ಥಾಪಿತವಾಗಿರಬೇಕು; ಪ್ಯಾಕೇಜ್ ಇಲ್ಲದಿದ್ದರೆ ಯಾವುದೇ ಆಯ್ಕೆ ಚರ್ಚೆಗೆ ಬರುವ ಮೊದಲೇ ಡಯಲ್ ಮುಗಿಯುತ್ತದೆ.

MPPE ಅನ್ನು ಅದನ್ನು ಬೇಡುವ ಬದಿಯಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಿ

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

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

ಡಯಲ್ ಮಾಡುವ ಮೊದಲು modprobe ppp_mppe ಮೂಲಕ ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಮಾಡಿ, ಏಕೆಂದರೆ ಅದಿಲ್ಲದೆ require-mppe-128 ವಿಫಲವಾಗುತ್ತದೆ. Windows ನಲ್ಲಿ ಸಮಾನ ನಿಯಂತ್ರಣ VPN ನಮೂದಿನ ಭದ್ರತಾ ಟ್ಯಾಬ್, ಅಲ್ಲಿ ಸರ್ವರ್ ನೀಡುವುದನ್ನು ಸ್ವೀಕರಿಸುವ ಬದಲು ಎನ್ಕ್ರಿಪ್ಷನ್ ಬೇಡುವಂತೆ ಕ್ಲೈಂಟ್ಗೆ ಹೇಳಬೇಕು. ಸರ್ವರ್ ಇನ್ನೂ LCP ಕೊನೆಗೊಳಿಸಿದರೆ, MPPE ಕಡ್ಡಾಯ, ಐಚ್ಛಿಕ ಅಥವಾ ನಿಷ್ಕ್ರಿಯ ಎಂದು ಅದರ ನಿರ್ವಾಹಕರನ್ನು ಕೇಳಿ, ಏಕೆಂದರೆ ಸರ್ವರ್ ನಿರಾಕರಿಸುವ ರಕ್ಷಣೆಯನ್ನು ಕ್ಲೈಂಟ್ ಮಾತುಕತೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಂದೇಶ ಮಾಯವಾಗಲಿ ಎಂದು ಎನ್ಕ್ರಿಪ್ಷನ್ ಆಫ್ ಮಾಡುವುದು ತಪ್ಪು ದಿಕ್ಕು: ಅದು ಈ ಪ್ರೋಟೋಕಾಲ್ ಹೊಂದಿರುವ ಏಕೈಕ ರಕ್ಷಣೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಸಂಪಾದಿಸುವ ಮೊದಲು ಕೆಲಸ ಮಾಡುವ ಪೀರ್ ಕಡತವನ್ನು ಉಳಿಸಿ. ತಪ್ಪಾಗಿ ಟೈಪ್ ಮಾಡಿದ require-mppe ಸಾಲು ಅದೇ ಸಾಮಾನ್ಯ LCP ವೈಫಲ್ಯವನ್ನು ಪುನರಾವರ್ತಿಸಿ ನಿಮ್ಮನ್ನು ಆರಂಭಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.

ಆಪ್ಲೆಟ್ ಬದಲು pppd ನ ಸ್ವಂತ ಲಾಗ್ ಓದಿ

ಡೆಸ್ಕ್ಟಾಪ್ ಆಪ್ಲೆಟ್ಗಳು ಸಂಪರ್ಕ ಕಡಿತವನ್ನು ತೋರಿಸಿ ಕಾರಣವನ್ನು ಮರೆಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದು ಪ್ರಯತ್ನದ ಬಗ್ಗೆ ಡೀಮನ್ ನ ವಿವರಣೆಯನ್ನು ಓದಿ. systemd ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸಂದೇಶ ಜರ್ನಲ್ಗೆ ಸೇರುತ್ತದೆ; ಹಳೆಯ ಸಂರಚನೆಗಳು ಸಾಂಪ್ರದಾಯಿಕ ಲಾಗ್ ಕಡತಗಳಿಗೆ ಬರೆಯುತ್ತವೆ.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

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

ಮರುಸಂಪರ್ಕಗಳಲ್ಲಿ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ: ಹುಕ್ ಹೆಸರುಗಳು ಮತ್ತು MTU

ಲಿಂಕ್ ನಿಂತ ನಂತರ, ಅದು ಮರುಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಎರಡು ವಿವರಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ಹುಕ್ಗಳು /etc/ppp/ip-up.d ಮತ್ತು /etc/network/if-up.d ನಲ್ಲಿವೆ, ಮತ್ತು ಎರಡೂ ಡೈರೆಕ್ಟರಿಗಳನ್ನು run-parts ಸಂಸ್ಕರಿಸುತ್ತದೆ, ಅದರ ಕಡತನಾಮ ಫಿಲ್ಟರ್ ಚುಕ್ಕೆ ಇರುವ ಯಾವುದನ್ನೂ ನಿರಾಕರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ set-pptp.sh ಎಂಬ ಸ್ಕ್ರಿಪ್ಟ್ ತಪ್ಪಿಸಲ್ಪಡುತ್ತದೆ, ಆದರೆ set-pptp ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್ನ ಒಳಗಿನ ವಿಷಯವನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದೇ ಹುಕ್ನ ಒಳಗಿನಿಂದ ಚಿಕ್ಕ MTU ಅನ್ನು ಹೊಂದಿಸಿ, ಇದರಿಂದ ಪ್ರತಿ ಹೊಸ ppp ಇಂಟರ್ಫೇಸ್ ಕೈಯಿಂದ ಆಜ್ಞೆ ಇಲ್ಲದೆ ಅದನ್ನು ಪಡೆಯುತ್ತದೆ.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೆಷನ್ ಕೊನೆಗೊಳಿಸಲು, ಪ್ರಕ್ರಿಯೆ ಹೆಸರುಗಳನ್ನು ಮಾದರಿ ಹೊಂದಿಸುವ ಬದಲು pppd ದಾಖಲಿಸಿದ pid ಅನ್ನು ಗುರಿಯಾಗಿಸಿ, ಏಕೆಂದರೆ ppp ಇರುವ ಎಲ್ಲವನ್ನೂ ಕೊಲ್ಲುವುದು ಸಂಬಂಧವಿಲ್ಲದ ಲಿಂಕ್ಗಳನ್ನೂ ಕಿತ್ತುಹಾಕುತ್ತದೆ. PPTP ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಮತ್ತು MS-CHAPv2 ದುರ್ಬಲವಾಗಿದೆ, ಆದ್ದರಿಂದ ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರಬೇಕಾದ ಲಿಂಕ್ನ ನಿರ್ವಹಣೆ ಎಂದು ಪರಿಗಣಿಸಿ, ಹೊಸ ಸ್ಥಳದಲ್ಲಿ PPTP ನಿಯೋಜಿಸಲು ಕಾರಣವಾಗಿ ಅಲ್ಲ.