L2TP: ਘਾਤਕ ਸਿਗਨਲ 15, NO_PROPOSAL_CHOSEN ਅਤੇ ਗੁੰਮ modp1024

ਤੁਹਾਡਾ ਕਨੈਕਸ਼ਨ ਅਟਕ ਜਾਂਦਾ ਹੈ, ਕਲਾਇੰਟ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਕਰੀਨ ’ਤੇ ਆਖਰੀ ਲਾਈਨ death_handler: Fatal signal 15 received ਹੁੰਦੀ ਹੈ। ਉਹ ਲਾਈਨ ਰੁਕਾਵਟ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਕਾਰਨ ਦੀ ਨਹੀਂ। IPsec ਲੌਗ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਉੱਤੇ ਲਗਭਗ ਹਮੇਸ਼ਾ NO_PROPOSAL_CHOSEN ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜੋੜੀ ਅਦਲਾ-ਬਦਲੀ ਦੇ ਫੇਜ਼ 2 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਜਿੱਥੇ ਦੋਵੇਂ ਧਿਰਾਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਹੈਸ਼ ਦੀਆਂ ਚੋਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਕੋਈ ਸਾਂਝਾ ਨਾ ਹੋਣ ’ਤੇ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਉਸ ਪੜਾਅ ’ਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਜੇ ਭੇਜੇ ਨਹੀਂ ਗਏ, ਇਸ ਲਈ ਪਾਸਵਰਡ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਨਤੀਜਾ ਨਹੀਂ ਬਦਲੇਗਾ।

Linux ਕਲਾਇੰਟ ’ਤੇ ਆਮ ਤੌਰ ’ਤੇ ਦੋ ਚੀਜ਼ਾਂ ਉਸ ਕਟਾਵ ਨੂੰ ਖਾਲੀ ਕਰਦੀਆਂ ਹਨ। ਸਥਾਨਕ ਡੀਮਨ ਪ੍ਰੋਫਾਈਲ ਵੱਲੋਂ ਮੰਗਿਆ Diffie-Hellman ਸਮੂਹ ਹੁਣ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ ਹੋ ਸਕਦਾ, ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਫੇਜ਼ 1 ਦਾ ਪ੍ਰਸਤਾਵ ਫੇਜ਼ 2 ਦੇ ਖੇਤਰ ਵਿੱਚ ਲੈ ਕੇ ਫਿਰਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਲੌਗ ਵਿੱਚ ਸਬੂਤ ਛੱਡਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖਾਤਾ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

ਉਹ ਦੋ ਸੁਨੇਹੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕਹਿੰਦੇ ਹਨ

IKE ਪੜਾਵਾਂ ਵਿੱਚ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਫੇਜ਼ 1 ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਐਲਗੋਰਿਦਮ ਚੁਣਦਾ ਹੈ; ਫੇਜ਼ 2, ਭਾਵ ਚਾਈਲਡ SA, ਵੱਖਰੇ ਸੈੱਟ ਹੇਠ ਟ੍ਰੈਫਿਕ ਢੋਂਦਾ ਹੈ। NO_PROPOSAL_CHOSEN ਉਹ ਸੂਚਨਾ ਹੈ ਜੋ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਤਦ ਮੋੜਦਾ ਹੈ ਜਦੋਂ ਪੇਸ਼ ਕੀਤੇ ਸੰਯੋਜਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਵੀਕਾਰਯੋਗ ਨਾ ਹੋਵੇ, ਅਤੇ ਇਹ INFORMATIONAL ਅਦਲਾ-ਬਦਲੀ ਦੇ ਅੰਦਰ [ HASH N(NO_PROP) ] ਵਜੋਂ ਦਿਸਦੀ ਹੈ।

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

ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਗੱਲਬਾਤ ਪੜ੍ਹੋ

ਡੀਮਨ ਜਿੱਥੇ ਲਿਖਦਾ ਹੈ ਉੱਥੇ ਲੌਗ ਪੱਧਰ ਵਧਾਓ, ਫਿਰ ਆਊਟਪੁੱਟ ਵੇਖਦਿਆਂ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ। NetworkManager ਹੋਸਟ ’ਤੇ L2TP ਪਲੱਗਇਨ ਉਹ ਪੱਧਰ ਬੈਕਐਂਡ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹੇ ਵੰਡਣ ਅਨੁਸਾਰ journal ਜਾਂ ਰਵਾਇਤੀ syslog ਫਾਈਲ ਵਿੱਚ ਪਹੁੰਚਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਦਲਾ-ਬਦਲੀ ਦਿਖਾਏਗਾ: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' ਜਾਂ tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'।

pluto ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਲਾਈਨ libreswan ਤੋਂ ਆਉਂਦੀ ਹੈ, charon strongSwan ਤੋਂ, ਅਤੇ ਦੋਵੇਂ ਇੱਕੋ ਹਾਲਤ ਨੂੰ ਵੱਖਰੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਬਿਆਨ ਕਰਦੇ ਹਨ। ਲੱਭਣ ਯੋਗ ਰੂਪ ਉਹ ਹੈ ਜੋ ਗੁੰਮ ਸਮੂਹ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਜਿਵੇਂ algorithm 'modp1024' is not supported, ਕਿਉਂਕਿ ਇਹ ਧੁੰਦਲੀ ਨਾਕਾਮੀ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦਾ ਹੈ।

modp1024 ਕਿੱਥੇ ਗਿਆ

Diffie-Hellman ਸਮੂਹ 2 ਇੰਨਾ ਕਮਜ਼ੋਰ ਹੈ ਕਿ ਕਈ ਵੰਡਾਂ ਨੇ 3.30 ਤੋਂ ਇਸਨੂੰ libreswan ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਤਦ ਸਾਲਾਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਜਾਂ ਸਿਰਫ਼ aes128-sha1-modp1024 ਸੂਚੀਬੱਧ ਕਰਨ ਵਾਲੀ ਗੇਟਵੇ ਗਾਈਡ ਤੋਂ ਲਿਆ ਪ੍ਰੋਫਾਈਲ ਸਥਾਨਕ ਡੀਮਨ ਤੋਂ ਐਸਾ ਕੁਝ ਮੰਗਦਾ ਹੈ ਜੋ ਉਹ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਨਵੇਂ NetworkManager-l2tp ਬਿਲਡ ਉਸ ਨਤੀਜੇ ਨੂੰ ਹੋਰ ਸੰਭਾਵੀ ਬਣਾਉਂਦੇ ਹਨ: 1.2.16 ਤੋਂ ਉਹ ਸੈੱਟ ਨੂੰ Windows 10 ਅਤੇ iOS ਸ਼ੈਲੀ ਦੇ ਪ੍ਰਸਤਾਵਾਂ ਨਾਲ ਬਦਲਦੇ ਹਨ ਅਤੇ libreswan ਪਤਾ ਲੱਗਣ ’ਤੇ modp1024 ਹਟਾ ਦਿੰਦੇ ਹਨ। ਸਾਹਮਣੀ ਧਿਰ ਅਕਸਰ ਨਿਰਦੋਸ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਉਹੀ ਸਮੂਹ ਪੇਸ਼ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸੈੱਟ ਕੀਤਾ ਸੀ।

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

ਵੱਖਰੇ ਪ੍ਰਭਾਵਾਂ ਵਾਲੀਆਂ ਦੋ ਮੁਰੰਮਤਾਂ

ਸਸਤੀ ਮੁਰੰਮਤ ਇਹ ਹੈ ਕਿ ਐਲਗੋਰਿਦਮ ਹੱਥੋਂ ਪੱਕੇ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਸੰਪਾਦਕ ਵਿੱਚ ਦੋਵੇਂ ਪ੍ਰਸਤਾਵ ਖੇਤਰ ਖਾਲੀ ਕਰੋ ਅਤੇ ਪਲੱਗਇਨ ਨੂੰ ਉਹ ਸੈੱਟ ਚੁਣਨ ਦਿਓ ਜੋ ਦੂਰ ਦੀ ਧਿਰ ਸਵੀਕਾਰਦੀ ਹੈ; ਜੇ ਗੇਟਵੇ ਆਧੁਨਿਕ ਸਮੂਹਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਤਾਂ ਗੱਲਬਾਤ ਵਧੇਰੇ ਕੰਮ ਤੋਂ ਬਿਨਾਂ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਦੂਜੀ ਮੁਰੰਮਤ strongSwan ਸਥਾਪਤ ਕਰਕੇ ਪੁਰਾਣੇ ਗੇਟਵੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਰੱਖਦੀ ਹੈ, ਜਿਸਦੇ ਪੈਕੇਜ਼ ਬਹੁਤੀਆਂ ਵੰਡਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਸਮੂਹ 2 ਲਾਗੂ ਕਰਦੇ ਹਨ। ਇਹ ਡੀਮਨ ਬਦਲਣਾ ਹੈ, ਇਸ ਲਈ ਕੀਮਤ ਹੈ: ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਹੋਸਟ ’ਤੇ ਹੋਰ ਸੁਰੰਗਾਂ libreswan ਸੰਰਚਨਾ ’ਤੇ ਨਿਰਭਰ ਹਨ ਜਾਂ ਨਹੀਂ, ਅਤੇ Fedora ’ਤੇ NetworkManager ਅਤੇ strongSwan ਪਲੱਗਇਨ ਵਿਚਕਾਰ SELinux ਇਨਕਾਰ ਦੀ ਉਮੀਦ ਰੱਖੋ। ਉਹ ਇਨਕਾਰ IKE ਟ੍ਰੇਸ ਵਿੱਚ ਨਹੀਂ, ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਦਿਸਦੇ ਹਨ, ਇਸ ਲਈ ਸਫਲ ਸਥਾਪਨਾ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਸੁਰੰਗ ਟੁੱਟੀ ਦਿਸ ਸਕਦੀ ਹੈ। ਜੋ ਕ੍ਰਮ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਹੈ ਪਹਿਲਾਂ dnf install strongswan, ਫਿਰ rpm -e libreswan।

ਮੇਲ ਖਾਂਦੀਆਂ ਪ੍ਰਸਤਾਵ ਸਤਰਾਂ, ਅਤੇ ਉਹਨਾਂ ਦੁਆਲੇ ਦੇ ਜਾਲ

ਜਦੋਂ ਖੇਤਰ ਹੱਥੋਂ ਭਰਨੇ ਪੈਣ ਤਾਂ ਫੇਜ਼ 1 ਅਤੇ ਫੇਜ਼ 2 ਵੱਖਰੇ ਮੁੱਲ ਲੈਂਦੇ ਹਨ। Meraki ਸ਼ੈਲੀ ਦੀ ਸਾਹਮਣੀ ਧਿਰ ਵਿਰੁੱਧ ਕੰਮ ਕਰਨ ਵਾਲੀ ਜਾਣੀ-ਪਛਾਣੀ ਜੋੜੀ ਫੇਜ਼ 1 ਵਿੱਚ aes128-sha1-modp1024 ਅਤੇ ਉਸਦੇ ਪਿੱਛੇ 3des-sha1-modp1024 ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਦੋਵੇਂ ਵਿਸਮਕ ਚਿੰਨ੍ਹ ਨਾਲ ਬੰਦ ਜੋ ਸੈੱਟ ਨੂੰ ਸਖ਼ਤ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਉਹੀ ਪ੍ਰਸਤਾਵ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।

ਫਿਰ ਫੇਜ਼ 2 ਉਸੇ ਸਖ਼ਤ ਨਿਸ਼ਾਨ ਨਾਲ ਅਤੇ Diffie-Hellman ਪਿਛੇਤਰ ਤੋਂ ਬਿਨਾਂ aes128-sha1 ਅਤੇ 3des-sha1 ਤੱਕ ਸੁੰਗੜ ਜਾਂਦਾ ਹੈ। -modp1024 ਲੈ ਕੇ ਚੱਲਣ ਵਾਲੀ ਫੇਜ਼ 2 ਦੀ ਲਾਈਨ ਗ਼ਲਤ ਖੇਤਰ ਵਿੱਚ ਫੇਜ਼ 1 ਦਾ ਮੁੱਲ ਹੈ, ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਹਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ’ਤੇ ਇਸਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਉਹ ਲਾਈਨ ਦੂਜੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕਾਪੀ ਕਰੋ ਅਤੇ ਦੂਜੀ ਪ੍ਰੋਫਾਈਲ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਨਾਕਾਮ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਟਾਈਪਿੰਗ ਗ਼ਲਤੀ ਪੂਰੇ ਬੇੜੇ ਦੀ ਘਟਨਾ ਬਣ ਜਾਂਦੀ ਹੈ।

ਹੋਰ ਖ਼ਰਾਬੀਆਂ ਪ੍ਰਸਤਾਵ ਦੀ ਬੇਮੇਲ ਨਾ ਹੁੰਦਿਆਂ ਵੀ ਉਹੀ ਪੌਪਅੱਪ ਪਹਿਨਦੀਆਂ ਹਨ। KDE ’ਤੇ L2TP ਕਿਸਮ ਪਲੱਗਇਨ ਸਥਾਪਤ ਹੋਣ ’ਤੇ ਵੀ ਸੂਚੀਬੱਧ ਹੋ ਸਕਦੀ ਹੈ ਜਦਕਿ ਹਰ ਕਨੈਕਸ਼ਨ ਤੁਰੰਤ ਮਰ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਕਨੈਕਸ਼ਨ ਸੰਪਾਦਕ ਅਤੇ ਰਨਟਾਈਮ ਸਹਾਇਕ ਵੱਖਰੇ ਪੈਕੇਜ ਵਜੋਂ ਆਉਂਦੇ ਹਨ। ਸਕਰੀਨ ਰਹਿਤ ਹੋਸਟ ਕੰਮ ਕਰਦੇ ਡੈਸਕਟਾਪ ਤੋਂ ਪ੍ਰੋਫਾਈਲ ਮੁੜ ਵਰਤ ਸਕਦੇ ਹਨ: ਇਸਨੂੰ /etc/NetworkManager/system-connections/ ਤੋਂ ਕਾਪੀ ਕਰੋ, ਮੋਡ 600 ’ਤੇ ਸੈੱਟ ਕਰੋ, ਫਿਰ nmcli con reload ਚਲਾਓ। ਇਸਨੂੰ nmcli con up id work-l2tp ਨਾਲ ਉੱਪਰ ਲਿਆਓ, ਕਿਉਂਕਿ ਨੰਗਾ ਰੂਪ UUID ਮੰਗਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਪੁਰਾਣੀ ifname ਐਂਟਰੀ ਹਟਾਓ, ਨਹੀਂ ਤਾਂ ਬਾਕੀ ਸਭ ਠੀਕ ਹੋਣ ’ਤੇ ਵੀ ਮੈਨੇਜਰ Could not find source connection ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਚਾਬੀ ਸਾਦੇ ਟੈਕਸਟ ਵਜੋਂ ਜਾਂ 0s ਅਤੇ ਫਿਰ base64 ਵਜੋਂ ਸੰਭਾਲੀ ਜਾ ਸਕਦੀ ਹੈ; ਦੋਵੇਂ ਰੂਪ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਮੁੱਲ ਗੇਟਵੇ ਨਾਲ ਬਾਈਟ-ਦਰ-ਬਾਈਟ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਸ ਨਾਲ ਕਾਪੀ ਕੀਤੀਆਂ ਅੰਤਿਮ ਖਾਲੀ ਥਾਵਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ।