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 ਤੈਨਾਤ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ।