L2TP/IPsec PSK ਅਸਵੀਕਾਰ: ਪਹਿਲਾਂ ਸੰਵਾਦ, ਫਿਰ ਫ਼ਾਈਲਾਂ

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

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

ਸੰਵਾਦ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਖੇਤਰ ਉੱਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ

ਸੰਪਰਕ ਦੀ IPsec ਟੈਬ ਖੋਲ੍ਹੋ ਅਤੇ ਕੁੰਜੀ ਪੇਸਟ ਕਰਨ ਦੀ ਥਾਂ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰੋ। ਚੈਟ ਸੁਨੇਹੇ, PDF ਜਾਂ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਕੁੰਜੀ ਦੇ ਅੰਤ ਵਿੱਚ ਅਜਿਹਾ ਲਾਈਨ ਬ੍ਰੇਕ ਆ ਸਕਦਾ ਹੈ ਜੋ ਖੇਤਰ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਅਤੇ ਦਿਸਦੇ ਅੱਖਰ ਫਿਰ ਵੀ ਸਹੀ ਦਿਸਦੇ ਹਨ।

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

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

/etc/ipsec.d ਵਿੱਚ ਕੁੰਜੀ ਦਾ ਪਿੱਛਾ ਕਰੋ

ਪਲੱਗਇਨ PSK ਨੂੰ IPsec ਡੈਮਨ ਨੂੰ ਕਮਾਂਡ ਲਾਈਨ ਉੱਤੇ ਆਰਗਿਊਮੈਂਟ ਵਜੋਂ ਕਦੇ ਨਹੀਂ ਦਿੰਦਾ। ਇਸ ਦੀ ਥਾਂ ਇਹ ਮੁੱਲ ਨੂੰ ਸੀਕ੍ਰੇਟ ਫ਼ਾਈਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਡੈਮਨ ਉਸ ਫ਼ਾਈਲ ਨੂੰ ਲਵੇ ਇਹ ਵਿਵਸਥਾ ਕਰਦਾ ਹੈ, ਜੇ ਨਹੀਂ ਹੈ ਤਾਂ /etc/ipsec.secrets ਵਿੱਚ include ਲਾਈਨ ਜੋੜਦਾ ਹੈ। ਸੰਵਾਦ ਜੋ ਰੱਖਦਾ ਹੈ ਉਹ ਉਸ ਬਣੀ ਫ਼ਾਈਲ ਲਈ ਇਨਪੁਟ ਹੈ, ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਮੁੱਲ ਨਹੀਂ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੂਚੀ ਬਣਾਓ ਕਿ ਕੀ ਹੈ:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

ਪਲੱਗਇਨ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਹਰ ਸੰਪਰਕ ਲਈ ਇੱਕ ਫ਼ਾਈਲ ਲਿਖਦੇ ਸਨ, ਜਿਸ ਦਾ ਨਾਮ ਸੰਪਰਕ ਦੇ UUID ਉੱਤੇ ਸੀ, ਉਦਾਹਰਣ ਲਈ /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets। ਐਪਲੈਟ ਵਿੱਚ ਪ੍ਰੋਫ਼ਾਈਲ ਮਿਟਾਉਣ ਨਾਲ ਉਹ ਫ਼ਾਈਲ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਨਹੀਂ ਮਿਟਦੀ। ਜੇ ਪਿਛਲੇ ਸਰਵਰ ਦੀ ਪੁਰਾਣੀ ਫ਼ਾਈਲ ਅਜੇ ਵੀ ਡਿਸਕ ਉੱਤੇ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਡੈਮਨ ਉਸ ਪ੍ਰੋਫ਼ਾਈਲ ਦਾ ਭੇਤ ਚੁਣ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੁਣ ਨਹੀਂ ਵਰਤਦੇ, ਅਤੇ ਦਿਸਦਾ ਖੇਤਰ ਸਹੀ ਹੁੰਦਿਆਂ ਵੀ ਸੰਪਰਕ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸਮਝੋ ਕਿ 1.2.12 ਬਦਲਾਅ ਨੇ ਅੱਪਗ੍ਰੇਡਾਂ ਨਾਲ ਕੀ ਕੀਤਾ

ਪਲੱਗਇਨ ਸੰਸਕਰਣ 1.2.12 ਨੇ ਪ੍ਰਤੀ-ਸੰਪਰਕ ਸੀਕ੍ਰੇਟ ਫ਼ਾਈਲਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਫ਼ਾਈਲ ਨਾਲ ਬਦਲ ਦਿੱਤਾ, /etc/ipsec.d/ipsec.nm-l2tp.secrets। ਅੱਪਗ੍ਰੇਡ ਪੁਰਾਣੀਆਂ UUID-ਅਧਾਰਿਤ ਫ਼ਾਈਲਾਂ ਸਾਫ਼ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਮੌਜੂਦਾ include /etc/ipsec.d/*.secrets ਲਾਈਨ ਉਨ੍ਹਾਂ ਨੂੰ ਅਜੇ ਵੀ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਸੰਸਕਰਣ 1.2.16 ਨੇ ਡਿਫ਼ੌਲਟ ਪ੍ਰਸਤਾਵਾਂ ਦੀ ਸੰਭਾਲ ਬਦਲੀ, ਭੇਤਾਂ ਦਾ ਲੇਆਉਟ ਨਹੀਂ।

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

ਉਹ ਅੱਖਰ ਵੱਖ ਕਰੋ ਜੋ ਸਟੋਰੇਜ ਫ਼ਾਰਮੈਟ ਨਹੀਂ ਰੱਖ ਸਕਦਾ

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

1.2.12 ਤੋਂ ਸਟੋਰ ਕੀਤਾ ਮੁੱਲ ਸਾਦਾ ਲਿਖਤ ਨਹੀਂ ਹੈ। ਪਲੱਗਇਨ ਫ਼ਾਈਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ PSK ਨੂੰ base64 ਵਿੱਚ ਇਨਕੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਰਿਲੀਜ਼ ਨੋਟਸ ਉਸੇ ਇਨਕੋਡਿੰਗ ਨੂੰ ਕਾਰਨ ਦੱਸਦੇ ਹਨ ਕਿ ਦੋਹਰਾ ਹਵਾਲਾ ਅੱਖਰ ਹੁਣ ਕੁੰਜੀ ਵਿੱਚ ਸਵੀਕਾਰਯੋਗ ਹੈ। ਇਸ ਲਈ ਖੇਤਰ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ ਹਵਾਲਾ ਅੱਖਰ ਪੇਸ਼ ਕਰਨ ਯੋਗ ਹੈ; ਹਰ ਨਿਯੰਤਰਣ ਅੱਖਰ ਲਈ ਇਹ ਸੱਚ ਨਹੀਂ।

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

ਪੜ੍ਹੋ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਕਿਹੜੀ ਪਰਤ ਫੇਲ੍ਹ ਹੋਈ

ਪਹਿਲਾਂ ipsec --version ਚਲਾਓ, ਕਿਉਂਕਿ strongSwan ਅਤੇ Libreswan ਵੱਖਰੇ ਫ਼ਾਈਲ ਨਾਮ ਅਤੇ ਸਿੰਟੈਕਸ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਲਈ ਦਿੱਤੀ ਸਲਾਹ ਦੂਜੇ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਦੇ ਸੁਨੇਹੇ ਜਾਂ ਡੈਮਨ ਲੌਗ ਤੋਂ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਪੜਾਅ ਪੜ੍ਹੋ: ਪਹਿਲਾਂ-ਸਾਂਝੀ ਕੁੰਜੀ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਅਸਵੀਕਾਰ ਹੋਏ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਤੋਂ ਵੱਖਰੀ ਘਟਨਾ ਹੈ।

PSK ਟਨਲ ਦੇ ਸਿਰਿਆਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ। ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ L2TP ਦੇ ਅੰਦਰਲੇ ਵਿਅਕਤੀ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੇ ਹਨ, ਅਤੇ IPsec ਸੰਗਠਨ ਚੜ੍ਹਨ ਮਗਰੋਂ PPP ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਸਹੀ PSK ਗ਼ਲਤ ਖਾਤੇ ਨਾਲ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਖਾਤਾ ਬਦਲਣ ਨਾਲ ਉਹ ਕੁੰਜੀ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗੀ ਜੋ ਡੈਮਨ ਨੇ ਕਦੇ ਠੀਕ ਨਹੀਂ ਪੜ੍ਹੀ।

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