ਕਿਉਂ ਸਿਰਫ਼ PPP CHAP MPPE ਦੀ ਲੋੜ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ

ਐਨਕ੍ਰਿਪਸ਼ਨ 'ਤੇ ਜ਼ੋਰ ਦੇਣ ਵਾਲਾ PPTP ਪ੍ਰੋਫਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸੇ ਥਾਂ 'ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ: PPP ਇੱਕ ਅਜਿਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਦਲ-ਬਦਲ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ ਜੋ ਕਦੇ ਵੀ MPPE ਨੂੰ ਲੋੜੀਂਦੀ ਕੁੰਜੀ ਸਮੱਗਰੀ ਪੈਦਾ ਨਹੀਂ ਕਰਦੀ। ਟਨਲ ਅੱਧਾ ਜੀਵਤ ਦਿਸਦਾ ਹੈ, ਪਾਸਵਰਡ ਸਵੀਕਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਟ੍ਰੈਫਿਕ ਇਸ ਨੂੰ ਪਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿੰਕ ਡਿੱਗ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਜੁੜਨ ਤੱਕ CHAP ਡ੍ਰੌਪਡਾਊਨ ਵੱਲ ਹੱਥ ਵਧਾਉਣਾ ਅਸਲ ਨੁਕਸ ਲੁਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਨੁਕਸ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਵਿਚਕਾਰ ਦਾ ਇਕਰਾਰਨਾਮਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਇਸ ਤਰ੍ਹਾਂ ਤਰਤੀਬ ਦਿੱਤੀਆਂ ਹਨ ਕਿ ਹਰ ਇੱਕ ਅਗਲੇ ਨਾਲੋਂ ਸਸਤਾ ਕਾਰਨ ਬਾਹਰ ਕਰਦੀ ਹੈ।

ਇੱਕ PPTP ਕਨੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਦੋ ਗੱਲਬਾਤਾਂ ਚੱਲਦੀਆਂ ਹਨ

PPTP GRE ਟਨਲ ਦੇ ਅੰਦਰ ਆਮ PPP ਸੈਸ਼ਨ ਢੋਂਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ। ਬਾਹਰੀ ਪਰਤ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪੈਕਟ ਕਿਵੇਂ ਇਨਕੈਪਸੂਲੇਟ ਹੋਣਗੇ ਅਤੇ ਕਿਹੜਾ ਕੰਟਰੋਲ ਚੈਨਲ ਮੌਜੂਦ ਹੈ; ਅੰਦਰਲਾ PPP ਸੈਸ਼ਨ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਾਥੀ ਕੌਣ ਹੈ ਅਤੇ ਉੱਤੇ ਕਿਹੜੀ ਸੁਰੱਖਿਆ ਚੱਲਦੀ ਹੈ। ਇਸ ਲਈ ਪਾਸਵਰਡ ਦੀ ਮੰਗ ਸਿਰਫ਼ ਅੰਦਰਲੀ ਪਰਤ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਪੂਰਾ ਹੋਇਆ ਬਾਹਰੀ ਹੈਂਡਸ਼ੇਕ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਬਾਰੇ ਵੀ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਪ੍ਰੋਫਾਈਲ ਇੱਥੇ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਲੋਕ ਟਨਲ ਡੀਬੱਗ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਮਤਭੇਦ PPP ਦੇ ਅੰਦਰ ਬੈਠਾ ਹੁੰਦਾ ਹੈ।

ਸਾਧਾਰਨ CHAP RFC 1994 ਦੀ ਚੁਣੌਤੀ-ਜਵਾਬ ਅਦਲ-ਬਦਲ ਹੈ, ਜੋ ਸਾਂਝੇ ਭੇਤ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ 'ਤੇ ਬਣੀ ਹੈ। MS-CHAPv2 ਵੱਖਰੇ ਸੁਨੇਹਿਆਂ ਅਤੇ ਵੱਖਰੇ ਆਉਟਪੁੱਟ ਵਾਲੀ ਦੂਜੀ ਅਦਲ-ਬਦਲ ਹੈ, RFC 2759 ਵਿੱਚ ਮਿਆਰੀਕ੍ਰਿਤ। ਦੋਵਾਂ ਨਾਵਾਂ ਦਾ ਸਾਂਝਾ ਸ਼ਬਦ ਹੀ ਉਹ ਇੱਕੋ ਚੀਜ਼ ਹੈ ਜੋ ਤਾਰ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਸਾਂਝੀ ਹੈ। ਕੋਈ ਵੀ ਨਾਮ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਅਦਲ-ਬਦਲ ਕੀ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਇੱਕੋ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ।

ਇਸੇ ਲਈ ਸਿਰਫ਼ CHAP ਲੇਬਲ ਵਾਲਾ ਵਿਕਲਪ ਪੁਰਾਣੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਸਰਵਰ MS-CHAPv2 ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਸਾਧਾਰਨ CHAP ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਲਿੰਕ ਕੰਟਰੋਲ ਫਿਰ ਵੀ ਪੂਰਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਪਾਸਵਰਡ ਫਿਰ ਵੀ ਸਵੀਕਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਅਸਫਲਤਾ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਜਦੋਂ ਸਰਵਰ ਕੁਝ ਵੀ ਪੈਦਾ ਨਾ ਕਰਨ ਵਾਲੀ ਅਦਲ-ਬਦਲ ਤੋਂ ਸੁਰੱਖਿਆ ਕੁੰਜੀਆਂ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਲੋੜੀਂਦੇ ਢੰਗ ਨੂੰ ਉਨ੍ਹਾਂ ਕੁੰਜੀਆਂ ਨਾਲ ਮਿਲਾਓ ਜੋ ਇਹ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ

MPPE ਕੁੰਜੀਆਂ ਆਮ ਤੌਰ 'ਤੇ PPP ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹਨ। Microsoft CHAP ਪਰਿਵਾਰ ਲਈ ਵਿਉਤਪਤੀ RFC 3079 ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਹੈ, ਅਤੇ ਇਹ ਇਨਪੁੱਟ ਵਜੋਂ ਸਾਂਝੇ ਭੇਤ ਦੀ ਥਾਂ MS-CHAP ਅਦਲ-ਬਦਲ ਦਾ ਆਉਟਪੁੱਟ ਲੈਂਦੀ ਹੈ। EAP ਢੰਗ ਵੱਖਰੇ ਰਾਹੀਂ ਉਸੇ ਥਾਂ ਪਹੁੰਚਦੇ ਹਨ, ਜਿੱਥੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸਰਵਰ ਕੁੰਜੀਆਂ ਨੂੰ MS-MPPE-Recv-Key ਅਤੇ MS-MPPE-Send-Key ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਜੋਂ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਸਾਧਾਰਨ CHAP ਦੋਵਾਂ ਰਾਹਾਂ ਵਿੱਚ ਕਿਤੇ ਨਹੀਂ ਆਉਂਦਾ, ਅਤੇ ਇਹ ਬੇਮੇਲ ਹੋਣ ਦਾ ਪੂਰਾ ਕਾਰਨ ਇਹੀ ਹੈ।

ਕੁੰਜੀਆਂ ਦੇ ਸਕਣ ਵਾਲੇ ਹਰ ਢੰਗ ਨੂੰ ਇਨਕਾਰ ਕਰਦਿਆਂ MPPE ਮੰਗਣ ਵਾਲਾ ਸੰਰਚਨਾ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਿਰੋਧਾਭਾਸੀ ਹੈ। pppd ਉਹ ਵਿਰੋਧਾਭਾਸ ਕੁੰਜੀਆਂ ਘੜ ਕੇ ਨਹੀਂ, ਲਿੰਕ ਇਨਕਾਰ ਕਰਕੇ ਸੁਲਝਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਦਿਸਣ ਵਾਲਾ ਨਤੀਜਾ ਉਹ ਸੈਸ਼ਨ ਹੈ ਜੋ ਪ੍ਰਮਾਣਿਤ ਹੋ ਕੇ ਫਿਰ ਨੈੱਟਵਰਕ ਪੜਾਅ ਵਿੱਚ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਰਵਰ ਕੁਝ ਵੀ ਵਿਉਤਪੰਨ ਕਰਨ ਵਾਲੇ ਇੱਕੋ ਢੰਗਾਂ ਨੂੰ ਇਨਕਾਰ ਕਰਦਾ ਰਹੇ, ਤਦ ਤੱਕ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਅਜ਼ਮਾਉਣਾ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ।

ਇਸ ਤੋਂ ਨਿਕਲਣ ਵਾਲਾ ਨਿਯਮ ਛੋਟਾ ਹੈ: ਜੇ ਪ੍ਰੋਫਾਈਲ MPPE ਮੰਗਦਾ ਹੈ, ਤਾਂ ਢੰਗ MS-CHAP ਦੀ ਕਿਸਮ ਜਾਂ ਅਜਿਹਾ EAP ਢੰਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਦੀਆਂ ਕੁੰਜੀਆਂ ਸਰਵਰ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਸਿਰਫ਼ MS-CHAPv2 ਇਨਕਾਰ ਕਰਨਾ ਇਸ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ MS-CHAPv1 ਵੀ ਕੁੰਜੀਆਂ ਵਿਉਤਪੰਨ ਕਰਦਾ ਹੈ ਅਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਇਨਕਾਰ ਨਾ ਕੀਤੇ ਜਾਣ ਤੱਕ ਉਪਲਬਧ ਰਹਿੰਦਾ ਹੈ; ਦੋਵੇਂ ਇਨਕਾਰ ਕਰਨ ਨਾਲ ਸਾਧਾਰਨ CHAP ਅਤੇ PAP ਬਚਦੇ ਹਨ, ਜੋ ਕੁਝ ਵੀ ਵਿਉਤਪੰਨ ਨਹੀਂ ਕਰਦੇ ਅਤੇ ਲੋੜ ਨੂੰ ਅਪੂਰਣ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਜੋ ਤੁਹਾਨੂੰ ਪਸੰਦ ਨਹੀਂ ਉਨ੍ਹਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਦੀ ਥਾਂ ਸਵੀਕਾਰ ਕੀਤੇ ਢੰਗ ਦਾ ਸਪਸ਼ਟ ਨਾਮ ਦਿਓ। ਕਲਾਇੰਟ ਜੁੜੇ ਇਸ ਲਈ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਲੋੜ ਛੱਡਣਾ ਮੁਰੰਮਤ ਨਹੀਂ, ਗਿਰਾਵਟ ਹੈ।

ਕਲਾਇੰਟ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦੇ ਵਿਕਲਪ ਪੜ੍ਹੋ

ਇਨ੍ਹਾਂ ਬੇਮੇਲਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਸਰਵਰ 'ਤੇ ਦੋ ਫਾਈਲਾਂ ਵਿੱਚ ਦਿਸਦੀਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ। Linux PPTP ਐਂਡਪੌਇੰਟ 'ਤੇ ਸੰਬੰਧਿਤ ਸੈਟਿੰਗਾਂ pppd ਵਿਕਲਪ ਫਾਈਲ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ ਜੋ pptpd ਅੱਗੇ ਭੇਜਦਾ ਹੈ। ਇਸ ਨੂੰ ਸਰਵਰ 'ਤੇ ਚਲਾਓ, ਕਲਾਇੰਟ ਸਥਿਤੀ ਸਕ੍ਰੀਨ ਤੋਂ ਨਹੀਂ। ਜਿਹੜੀਆਂ ਲਾਈਨਾਂ ਸੁਰੱਖਿਆ ਮੋਡ ਮੰਗਦੀਆਂ, ਇਨਕਾਰ ਕਰਦੀਆਂ ਜਾਂ ਨਾਮ ਦਿੰਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

ਆਉਟਪੁੱਟ ਨੂੰ ਫਲੈਗਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ, ਇਕਰਾਰਨਾਮਾ ਸਮਝ ਕੇ ਪੜ੍ਹੋ। ਜੋ ਲਾਈਨ MPPE ਮੰਗਦੀ ਹੈ ਪਰ MS-CHAP ਦੀਆਂ ਦੋਵੇਂ ਕਿਸਮਾਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ, ਉਸ ਨੂੰ ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ MS-CHAP ਢੰਗ ਲਈ ਲੋੜ ਦਾ ਨਾ ਹੋਣਾ ਕੁੰਜੀ ਨਾ ਦੇਣ ਵਾਲੀਆਂ ਅਦਲ-ਬਦਲਾਂ ਲਈ ਦਰਵਾਜ਼ਾ ਖੁੱਲ੍ਹਾ ਛੱਡਦਾ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ ਕਿਸ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਇਹ ਭੇਤ ਫਾਈਲ ਤੈਅ ਕਰਦੀ ਹੈ:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਮੁੱਲ ਲਿਖੋ: ਬਾਹਰੀ ਪ੍ਰੋਟੋਕਾਲ, ਸਰਵਰ ਵੱਲੋਂ ਮੰਗਿਆ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ, ਅਤੇ ਸੁਰੱਖਿਆ ਲਾਜ਼ਮੀ ਹੈ ਜਾਂ ਚੋਣਵੀਂ। ਇਹ ਤਿੰਨ ਹਰ ਅਗਲੇ ਫੈਸਲੇ ਨੂੰ ਤੈਅ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਸੰਵਾਦ ਤੋਂ ਇਨ੍ਹਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਹੀ ਪ੍ਰੋਫਾਈਲ ਅੱਧਾ ਸੰਰਚਿਤ ਰਹਿਣ ਦਾ ਰਾਹ ਹੈ। ਕੰਮ ਕਰਦਿਆਂ ਫਾਈਲ ਖੁੱਲ੍ਹੀ ਰੱਖੋ, ਕਿਉਂਕਿ ਅਗਲੇ ਭਾਗ ਨੂੰ ਉਹੀ ਤਿੰਨ ਮੁੱਲ ਚਾਹੀਦੇ ਹਨ।

PPP ਪੜਾਅ ਅਨੁਸਾਰ ਅਸਫਲਤਾ ਲੱਭੋ

PPP ਅਸਫਲਤਾਵਾਂ ਪੜਾਵਾਂ ਵਿੱਚ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਪੜਾਅ ਦੱਸਦਾ ਹੈ ਕਿ ਇਕਰਾਰਨਾਮੇ ਦੀ ਕਿਹੜੀ ਧਾਰਾ ਟੁੱਟੀ। ਜੋ ਲਿੰਕ ਕਦੇ ਲਿੰਕ ਕੰਟਰੋਲ ਨਹੀਂ ਛੱਡਦਾ ਉਸ ਵਿੱਚ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਜਾਂ ਗੱਲਬਾਤ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਜਦਕਿ ਜੋ ਪ੍ਰਮਾਣਿਤ ਹੋ ਕੇ ਫਿਰ ਮਰ ਜਾਂਦਾ ਹੈ ਉਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਨੀਤੀ ਜਾਂ ਕੁੰਜੀ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ। ਜੋ ਲਿੰਕ ਉੱਪਰ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਢੋਂਦਾ ਉਹ ਰਾਊਟਿੰਗ ਵੱਲ ਵਧ ਗਿਆ ਹੈ, ਜੋ ਵੱਖਰੀ ਜਾਂਚ ਹੈ।

ਜਰਨਲ ਪੜਾਅ ਦੀਆਂ ਲਾਈਨਾਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਉਹ ਉੱਚੇ ਡੀਬੱਗ ਪੱਧਰ ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹਨ। PPP ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਸੁਰੱਖਿਆ ਸੁਨੇਹੇ ਮੰਗੋ, ਫਿਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਪੜ੍ਹੋ। ਆਖ਼ਰੀ ਲਾਈਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਧਾਰਾ ਦਾ ਨਾਮ ਦਿੰਦੀਆਂ ਹਨ:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

ਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਅਤੇ ਫਿਰ ਇਹ ਸ਼ਿਕਾਇਤ ਲੱਭੋ ਕਿ ਸੁਰੱਖਿਆ ਮੰਗੀ ਗਈ ਸੀ ਪਰ ਗੱਲਬਾਤ ਨਹੀਂ ਹੋਈ। ਦੂਜਾ ਸੁਨੇਹਾ ਉੱਪਰਲੇ ਵਿਰੋਧਾਭਾਸ ਦਾ ਦਸਤਖ਼ਤ ਹੈ, ਅਤੇ ਸਰਵਰ ਕੁੰਜੀ ਪੈਦਾ ਕਰ ਸਕਣ ਵਾਲੇ ਇੱਕੋ ਢੰਗ ਨੂੰ ਇਨਕਾਰ ਕਰਦਾ ਰਹੇ, ਤਦ ਤੱਕ ਕਿੰਨੀ ਵੀ ਵਾਰ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਇਹ ਮਿਟਦਾ ਨਹੀਂ। ਦੋ ਜਾਲ ਨਾਮ ਦੇਣ ਯੋਗ ਹਨ: ਪੜਾਅ ਦੀਆਂ ਲਾਈਨਾਂ ਪੜ੍ਹੇ ਬਿਨਾਂ ਡੀਬੱਗ ਪੱਧਰ ਵਧਾਉਣਾ ਸ਼ੋਰ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਚੁਣੌਤੀ ਸਮੱਗਰੀ ਜਾਂ ਪਾਸਵਰਡ ਫੜਨਾ ਸੰਰਚਨਾ ਦੇ ਕੰਮ ਨੂੰ ਪਛਾਣ-ਪੱਤਰ ਲੀਕ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਵਿਕਲਪ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪੜਾਅ ਦਰਜ ਕਰੋ।

ਪੁਰਾਣਾ ਐਂਡਪੌਇੰਟ ਬੰਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਕਾਸ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

MPPE ਲਿੰਕ ਸੁਰੱਖਿਆ ਦਾ ਇਤਿਹਾਸਕ ਤੰਤਰ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਮੌਜੂਦਗੀ PPTP ਨੂੰ ਨਵੀਂ ਤੈਨਾਤੀ ਲਈ ਸਮਝਦਾਰ ਚੋਣ ਨਹੀਂ ਬਣਾਉਂਦੀ। Microsoft ਦੀ ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਨਵੀਂ ਦੂਰਸਥ ਪਹੁੰਚ ਤੈਨਾਤੀ ਲਈ PPTP ਅਤੇ ਪਹਿਲਾਂ-ਸਾਂਝੀ ਕੁੰਜੀ ਵਾਲੇ L2TP/IPsec ਵਿਰੁੱਧ ਸਲਾਹ ਦਿੰਦੀ ਹੈ। ਪੁਰਾਣਾ ਐਂਡਪੌਇੰਟ ਜੀਵਤ ਰੱਖਣਾ ਮੌਜੂਦਾ ਸੇਵਾ ਬਾਰੇ ਫੈਸਲਾ ਹੈ, ਅਗਲੇ ਲਈ ਨਮੂਨਾ ਨਹੀਂ।

ਜਦੋਂ ਐਂਡਪੌਇੰਟ ਰਹਿਣਾ ਹੀ ਹੋਵੇ, ਇਕਰਾਰਨਾਮਾ ਲਿਖੋ: ਬਾਹਰੀ ਪ੍ਰੋਟੋਕਾਲ, ਲੋੜੀਂਦਾ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ, ਲਾਜ਼ਮੀ ਸੁਰੱਖਿਆ, ਅਤੇ ਉਹ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਜੋ ਇਸ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਜਾ ਸਕਦਾ ਹੈ, ਪੁਰਾਣੇ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲ ਦੀ ਗੇਟਵੇ ਪਛਾਣ, ਉਸ ਦੀ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪਛਾਣ-ਪੱਤਰ ਕਿੱਥੇ ਰਹਿਣਗੇ ਚੁਣੋ। ਫਿਰ ਰੂਟ, DNS ਅਤੇ ਉਹ ਸਰੋਤ ਯੋਜਿਤ ਕਰੋ ਜਿਨ੍ਹਾਂ ਤੱਕ ਹਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਪਹੁੰਚ ਦਾ ਅਧਿਕਾਰ ਹੈ। ਲਕਸ਼ਿਤ ਕਲਾਇੰਟ ਨੂੰ ਚੱਲ ਰਹੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਨਹੀਂ, ਮਾਲਕ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਜਾਂਚੋ।

ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਇਨਕਾਰ ਇਨਕਾਰ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਰਖ ਪਾਸ ਹੋਵੇ ਇਸ ਲਈ ਅਸੁਰੱਖਿਅਤ ਮੋਡ ਵਿੱਚ ਮੁੜਨਾ ਨੀਤੀ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਖੁਲਾਸੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਤਿਆਰ ਹਾਲਤ ਸਮਰਥਿਤ, ਦਸਤਾਵੇਜ਼ੀ ਇਕਰਾਰਨਾਮਾ ਹੈ, ਇੱਕ ਪੁਰਾਣਾ ਕਨੈਕਸ਼ਨ ਸਫਲ ਕਰਨ ਵਾਲਾ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਸਮੂਹ ਨਹੀਂ। ਬਦਲ ਉਹੀ ਜਾਂਚਾਂ ਪਾਸ ਨਾ ਕਰੇ, ਤਦ ਤੱਕ ਪੁਰਾਣਾ ਪ੍ਰੋਫਾਈਲ ਆਪਣੀ ਥਾਂ 'ਤੇ, ਨਾ ਵਰਤਿਆ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੱਖੋ।