pptpd ਉੱਤੇ GRE ਲਿਖਣ ਦੀ ਅਸਫਲਤਾ ਪਾਸਵਰਡ ਸਮੱਸਿਆ ਨਹੀਂ

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

ਦੋ ਸੁਨੇਹੇ, ਦੋ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ

ਪੜ੍ਹਨ ਦੀ ਅਸਫਲਤਾ ਦਾ ਅਰਥ ਹੈ ਕਿ GRE ਪੈਕਟ ਕਦੇ ਡੀਮਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਜਾਂ ਅੰਦਰ ਆਉਂਦਿਆਂ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਦਿਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਡੇਟਾ ਮਾਰਗ ਰਾਹੀਂ ਕੁਝ ਨਹੀਂ ਲੰਘਦਾ। ਪ੍ਰਮਾਣਿਕਤਾ ਹੀ ਇੱਕੋ ਚੀਜ਼ ਹੈ ਜੋ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਕੰਮ ਕਰ ਗਈ।

ਲਿਖਣ ਦੀ ਅਸਫਲਤਾ ਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਸੈਸ਼ਨ ਨੇ ਕੁਝ ਅਜਿਹਾ ਤੈਅ ਕੀਤਾ ਜੋ ਕਰਨਲ ਜਾਂ ਕਲਾਇੰਟ ਵਰਤ ਨਹੀਂ ਸਕਦੇ। ਨਿਯੰਤਰਣ ਚੈਨਲ ਪੂਰਾ ਹੋਇਆ, ਅਤੇ ਉਸ ਬਦਲ ਵਿੱਚ ਸਹਿਮਤ ਹੋਏ ਵਿਕਲਪ ਉਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਜੋ ਅੰਤ ਬਿੰਦੂ ਅਸਲ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਸੰਰਚਨਾ ਅਸਹਿਮਤੀ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਘਟਨਾ ਨਹੀਂ।

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

ਪ੍ਰੋਟੋਕਾਲ 47 ਪੋਰਟ 47 ਨਹੀਂ ਹੈ

PPTP ਕਾਲ ਸਥਾਪਿਤ ਕਰਨ ਲਈ TCP 1723 ਅਤੇ ਪੇਲੋਡ ਢੋਣ ਲਈ GRE ਵਰਤਦਾ ਹੈ। GRE IP ਪ੍ਰੋਟੋਕਾਲ 47 ਹੈ, ਪੋਰਟ ਨੰਬਰ ਨਹੀਂ, ਇਸ ਲਈ ਪੋਰਟ 47 ਖੋਲ੍ਹਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਕੋਈ ਲਾਭਦਾਇਕ ਚੀਜ਼ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕਰਦਾ।

ਮਾਰਗ ਵਿੱਚਲੇ ਰਾਊਟਰ ਨੂੰ PPTP passthrough ਸੁਵਿਧਾ ਜਾਂ ਸਪਸ਼ਟ GRE ਆਗਿਆ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ TCP ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਕਦੇ ਪੈਕਟ ਨਹੀਂ ਢੋਂਦੀ, ਜੋ ਉੱਪਰ ਵਾਲੀ ਪੜ੍ਹਨ ਦੀ ਅਸਫਲਤਾ ਹੀ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਫਾਇਰਵਾਲ ਵਿੱਚ ਪੋਰਟ 47 ਨਿਯਮ ਇਸ ਪ੍ਰੋਟੋਕਾਲ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਬਰਬਾਦ ਹੋਈ ਦੁਪਹਿਰ ਹਨ।

ਕਿਹੜਾ ਪਾਸਾ ਟ੍ਰੈਫਿਕ ਸੁੱਟ ਰਿਹਾ ਹੈ ਇਹ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਸਰਵਰ ਉੱਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਇਕੱਠੀਆਂ ਵੇਖੋ: tcpdump -ni any port 1723 or proto gre।

ਜੇ 1723 ਕਾਲ ਸਥਾਪਨਾ ਦਿਖਾਵੇ ਅਤੇ GRE ਚੁੱਪ ਰਹੇ, ਤਾਂ ਰੋਕ ਹੋਸਟ ਤੋਂ ਉੱਪਰ ਹੈ। ਜੇ GRE ਆਵੇ ਅਤੇ ਡੀਮਨ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਸਮੱਸਿਆ ਸਥਾਨਕ ਹੈ ਅਤੇ ਵਿਕਲਪ ਅੱਗੇ ਵੇਖਣ ਦੀ ਥਾਂ ਹਨ।

ਹੋਸਟ ਅਸਲ ਵਿੱਚ ਜਿੱਥੇ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਉੱਥੇ GRE ਦੀ ਆਗਿਆ ਦਿਓ

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

ਸਰਵਰ ਨੂੰ ਹੀ ਭੇਜੇ ਪੈਕਟਾਂ ਲਈ input ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ forward ਲੜੀ ਉਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ ਵੇਖਦੀ। ਫਿਰ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਨਿਯਮ ਦੇ ਕਾਊਂਟਰ ਵੇਖੋ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਪੈਕਟ ਆਉਂਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।

ਹਰ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਬਜਾਏ ਵੰਡ ਦੀ ਫਾਇਰਵਾਲ ਸੇਵਾ ਰਾਹੀਂ ਨਿਯਮ ਨੂੰ ਸਥਾਈ ਬਣਾਓ। nftables ਹੋਸਟ ਉੱਤੇ input ਅਤੇ forward ਦੋਵੇਂ ਲੜੀਆਂ ਵਿੱਚ ip protocol gre ਮਿਲਾਓ।

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ppp_generic ਮੌਡਿਊਲ ਵੀ ਲੋਡ ਹੈ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਵਾਪਸੀ ਦਿਸ਼ਾ ਸੁੱਟ ਰਹੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਫਾਇਰਵਾਲ ਸਮੱਸਿਆ ਵਰਗੀਆਂ ਦਿਖਣ ਵਾਲੀਆਂ ਪਰ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਗੁੰਮ ਕਰਨਲ ਮੌਡਿਊਲ ਜਾਂਚਣ ਤੱਕ ਬਿਲਕੁਲ ਰੋਕੇ ਪ੍ਰੋਟੋਕਾਲ ਵਰਗਾ ਦਿਖਦਾ ਹੈ।

ਵਿਕਲਪਾਂ ਨੂੰ ਉਸ ਕਲਾਇੰਟ ਨਾਲ ਮਿਲਾਓ ਜੋ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਹੈ

ਦੂਜੀ ਰਿਪੋਰਟ ਦਾ ਸੁਧਾਰ /etc/ppp/pptpd-options ਵਿੱਚ ਹੈ, ਜਿੱਥੇ ਵਿਧੀ PAP, CHAP ਅਤੇ MSCHAP ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ, ਸੰਬੰਧਿਤ require ਲਾਈਨਾਂ ਨੂੰ ਟਿੱਪਣੀ ਕਰਦੀ ਹੈ ਅਤੇ ਸਥਿਤੀ ਵਾਲਾ MPPE ਰੱਖਦੀ ਹੈ। ਉਹ ਵਿਧੀ ਇੱਕ ਕਲਾਇੰਟ ਮਿਸ਼ਰਣ ਲਈ ਲਿਖੀ ਗਈ ਸੀ, ਅਤੇ ਅੱਖਾਂ ਬੰਦ ਕਰਕੇ ਨਕਲ ਕਰਨਾ ਆਮ ਸਥਿਤੀ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਰੱਦ ਕਰਨ ਵਾਲੀਆਂ ਲਾਈਨਾਂ ਨੂੰ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ, ਸਗੋਂ ਲੇਖਕ ਕੋਲ ਕਿਹੜੇ ਕਲਾਇੰਟ ਸਨ ਦੇ ਬਿਆਨ ਵਜੋਂ ਪੜ੍ਹੋ।

Windows ਕਲਾਇੰਟ ਨੂੰ ਆਮ ਤੌਰ ਉੱਤੇ MS-CHAPv2 ਨਾਲ MPPE-128 ਚਾਹੀਦਾ ਹੈ। ਉਹ ਲੋੜਾਂ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਵਿਕਲਪ ਹਟਾਓ ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰ ਸਕਦਾ।

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

ਕਲਾਇੰਟ ਦਾ ਗਲਤੀ ਨੰਬਰ ਪੜ੍ਹੋ

ਕਲਾਇੰਟ ਦਾ ਸੰਖਿਆਤਮਕ ਕੋਡ ਸਰਵਰ ਲੌਗ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਪੜਾਅ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ। ਹੋਰ ਕੁਝ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਪੜ੍ਹੋ। 691 ਦਾ ਅਰਥ ਹੈ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਦ ਹੋਏ, 721 ਦਾ ਅਰਥ ਹੈ ਸਰਵਰ ਨੇ ਕਦੇ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ, ਅਤੇ 619 ਦਾ ਅਰਥ ਹੈ ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਗਿਆ। ਨੰਬਰ ਨਾਲ ਦੋ ਮਿੰਟ ਸੰਰਚਨਾ ਨਾਲ ਇੱਕ ਘੰਟਾ ਬਚਾਉਂਦੇ ਹਨ।

ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਕੋਡ ਦੀ ਸਰਵਰ ਲੌਗ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਸੇ ਕਲਾਇੰਟ ਨਾਲ ਦੁਬਾਰਾ ਪਰਖੋ। ਨਹੀਂ ਤਾਂ ਦੂਜੀ ਅਸਫਲਤਾ ਪਹਿਲੀ ਦੇ ਪਿੱਛੇ ਲੁਕ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੁਧਾਰ ਅਪ੍ਰਭਾਵੀ ਦਿਖਦਾ ਹੈ।

ਜਦੋਂ ਲੌਗਇਨ ਸਫਲ ਹੋਵੇ ਅਤੇ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਾ ਹਿੱਲੇ, ਤਾਂ GRE ਅਜੇ ਵੀ ਸ਼ੱਕੀ ਹੈ। ਇਹ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਭੰਡਾਰ ਦੀ ਬਜਾਏ ਕੈਪਚਰ ਵੱਲ ਮੁੜਨ ਦਾ ਪਲ ਹੈ।