L2TP NO_PROPOSAL_CHOSEN: ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪੜਾਅ ਫੇਲ੍ਹ ਹੋਇਆ?
ਸੂਚਨਾ ਕਹਿੰਦੀ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰਸਤਾਵ ਰੱਦ ਹੋਇਆ, ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ। ਪੜਾਅ ਲਈ ਬੈਕਐਂਡ ਲੌਗ ਪੜ੍ਹੋ, ਫਿਰ ਗੇਟਵੇ ਚਲਾਉਣ ਵਾਲੇ ਨਾਲ ਸੂਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
NO_PROPOSAL_CHOSEN ਕਿਸੇ ਵੀ PPP ਉਪਭੋਗਤਾ-ਨਾਮ ਦੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਲਾਭਦਾਇਕ ਤੱਥ ਹੈ ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਸੰਦੇਸ਼ ਗੁੰਮਰਾਹ ਕਰਦਾ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ ਧਿਰ ਨੇ ਪ੍ਰਸਤਾਵ ਰੱਦ ਕੀਤਾ; ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਪੈਰਾਮੀਟਰ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ ਇਸ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਰੱਦ ਕਰਨਾ IKE ਸੰਬੰਧ ਬਣਾਉਂਦਿਆਂ ਹੋਇਆ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਸੁਰੱਖਿਆ ਦੀ ਗੱਲਬਾਤ ਦੌਰਾਨ। ਇਹਨਾਂ ਦੋ ਸੰਭਾਵਨਾਵਾਂ ਪਿੱਛੇ ਦੋ ਵੱਖਰੇ ਸੁਧਾਰ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਉਸ PFS ਚੈੱਕਬਾਕਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਜਿਸ ਵੱਲ ਲੋਕ ਪਹਿਲਾਂ ਹੱਥ ਪਾਉਂਦੇ ਹਨ।
ਇੱਕ ਸੰਦੇਸ਼, ਦੋ ਪ੍ਰਸਤਾਵ ਸਮੂਹ
IKEv1 L2TP/IPsec ਪ੍ਰਬੰਧ ਵਿੱਚ ਦੋ ਗੱਲਬਾਤਾਂ ਲਗਾਤਾਰ ਹੁੰਦੀਆਂ ਹਨ। ਪੜਾਅ 1 ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ, ਅਖੰਡਤਾ ਐਲਗੋਰਿਦਮ ਅਤੇ Diffie-Hellman ਸਮੂਹ ਤੋਂ IKE ਸੁਰੱਖਿਆ ਸੰਬੰਧ ਬਣਾਉਂਦਾ ਹੈ। ਫਿਰ ਪੜਾਅ 2 ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਦੀ ਸੁਰੱਖਿਆ ਕਿਵੇਂ ਹੋਵੇਗੀ, ਅਤੇ PFS ਦੀ ਲੋੜ ਉਸੇ ਦੂਜੀ ਗੱਲਬਾਤ ਦੀ ਹੈ।
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
ਕਿਉਂਕਿ ਪੜਾਅ ਲਗਾਤਾਰ ਹਨ, ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਜਗ੍ਹਾ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਸੂਚੀ ਦੀ ਤੁਲਨਾ ਕਰਨੀ ਹੈ। ਸੰਦੇਸ਼ ਦਾ ਪੂਰਾ ਨਿਦਾਨ ਮੁੱਲ ਇਸੇ ਵਿੱਚ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਸੈਟਿੰਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਕੱਢ ਲੈਣਾ ਢੁਕਵਾਂ ਹੈ।
PFS ਚੈੱਕਬਾਕਸ ਪੜਾਅ 1 ਦੀ ਮੁਰੰਮਤ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦਾ
PFS ਬੰਦ ਕਰਨਾ ਪੜਾਅ 2 ਦਾ ਇੱਕ ਗੁਣ ਬਦਲਦਾ ਹੈ। ਜੇ ਧਿਰਾਂ ਕਦੇ ਪੜਾਅ 1 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਈਆਂ, ਤਾਂ ESP ਗੱਲਬਾਤ ਕਦੇ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਚੈੱਕਬਾਕਸ ਦਾ ਰੱਦ ਹੋਣ 'ਤੇ ਕੋਈ ਅਸਰ ਨਹੀਂ ਪੈਂਦਾ, ਅਤੇ ਇਸੇ ਲਈ ਇਸਨੂੰ ਬਦਲਣ ਨਾਲ ਉਹੀ ਗਲਤੀ ਵੱਖਰੀ ਸਮਾਂ-ਮੋਹਰ ਨਾਲ ਆਉਂਦੀ ਹੈ।
ਉਲਟੀ ਗਲਤੀ ਵੀ ਓਨੀ ਹੀ ਆਮ ਹੈ। ਸਫਲ IKE ਸੰਬੰਧ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ESP ਪ੍ਰਸਤਾਵ ਸਵੀਕਾਰਯੋਗ ਹੈ, ਅਤੇ ਇਹ ਤਾਂ ਕਦੇ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਪੜਾਅ 2 ਦਾ ਸਮੂਹ ਮਿਲਦਾ ਹੈ। ਸਥਾਪਿਤ ਪ੍ਰਬੰਧਨ ਸੁਰੰਗ ਨੂੰ ਸਿਰਫ਼ ਪੜਾਅ 1 ਬਾਰੇ ਸਬੂਤ ਵਜੋਂ ਲਵੋ। ਲੋਕ ਹਰੀ ਰੇਖਾ ਨੂੰ «ਸੁਰੰਗ ਚੱਲ ਰਹੀ ਹੈ» ਪੜ੍ਹਦੇ ਹਨ, ਫਿਰ ਗਲਤ ਪੜਾਅ 'ਤੇ ਇੱਕ ਘੰਟਾ ਗੁਆ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੱਸਿਆ ਕਿ ਦੂਜੀ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਈ ਸੀ।
ਐਲਗੋਰਿਦਮ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਲੌਗ ਪੜ੍ਹੋ
ਰੱਦ ਹੋਣ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਦੇ ਸੰਦੇਸ਼ ਉਸ ਬੈਕਐਂਡ ਤੋਂ ਇਕੱਠੇ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਜੋੜੋ। ਉਸ ਸੰਬੰਧ ਤੋਂ ਬਿਨਾਂ ਤੁਸੀਂ ਕਿਸੇ ਹੋਰ ਕਨੈਕਸ਼ਨ ਦਾ ਇਤਿਹਾਸ ਪੜ੍ਹ ਰਹੇ ਹੋ ਅਤੇ ਉਸ ਤੋਂ ਸਿੱਟੇ ਕੱਢ ਰਹੇ ਹੋ।
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanਉਹਨਾਂ ਲਾਈਨਾਂ ਤੋਂ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ: ਪੜਾਅ 1 ਦਾ ਸੰਬੰਧ ਸਥਾਪਿਤ ਹੋਇਆ ਕਿ ਨਹੀਂ, ਅਤੇ ਕਿਹੜਾ ਵਟਾਂਦਰਾ ਫੇਲ੍ਹ ਹੋਇਆ। ਇਹ ਦੋ ਜਵਾਬ ਖੋਜ ਨੂੰ ਇੱਕ ਗੁਣ-ਸੂਚੀ ਤੱਕ ਸੀਮਿਤ ਕਰਦੇ ਹਨ। ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸੰਦਰਭ ਤੋਂ ਬਿਨਾਂ ਨਿਰਾ ਸੰਦੇਸ਼ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਫੋਰਮ ਥ੍ਰੈਡ ਤੋਂ ਪ੍ਰਸਤਾਵ ਅਜ਼ਮਾਉਣਾ ਕਿੰਨਾ ਵੀ ਲੁਭਾਉਣਾ ਹੋਵੇ। ਵੱਖਰੇ ਬੈਕਐਂਡ ਵਾਲੀ ਮਸ਼ੀਨ ਤੋਂ ਚੱਲਣ ਵਾਲੀ ਸਟਰਿੰਗ ਕਾਪੀ ਕਰਨ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਰੱਦ ਹੋਣਾ ਦੂਜੇ ਨਾਲ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ।
ਬੈਕਐਂਡ ਦਾ ਵਾਕ-ਢਾਂਚਾ ਸਫ਼ਰ ਨਹੀਂ ਕਰਦਾ
ਕੁਝ ਵੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ NetworkManager-l2tp ਦਾ ਸੰਸਕਰਣ ਅਤੇ IPsec ਬੈਕਐਂਡ ਦਾ ਸੰਸਕਰਣ ਲਿਖੋ। Libreswan ਅਤੇ strongSwan ਪ੍ਰਸਤਾਵ-ਵਾਕ-ਢਾਂਚਾ ਜਾਂ ਇੱਕੋ ਜਿਹੇ ਐਲਗੋਰਿਦਮ-ਸਮੂਹ ਸਾਂਝੇ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਇੱਕ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਸਟਰਿੰਗ ਦੂਜੇ ਵਿੱਚ ਵਾਕ-ਢਾਂਚਾ ਗਲਤੀ ਹੈ। ਸਥਾਪਿਤ ਬੈਕਐਂਡ ਨੀਤੀ ਅਨੁਸਾਰ IKEv1 ਨੂੰ ਵੀ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕੋਈ ਵੀ ਪ੍ਰਸਤਾਵ ਕਦੇ ਸਵੀਕਾਰ ਨਹੀਂ ਹੋਵੇਗਾ।
ਪ੍ਰੋਜੈਕਟ ਦਾ README ਉਹਨਾਂ ਬੈਕਐਂਡ ਅੰਤਰਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਪੜਾਅ 1 ਤੇ ਪੜਾਅ 2 ਦੇ ਖੇਤਰ ਵੱਖਰੇ ਰੱਖਦਾ ਹੈ। ਇਸਨੂੰ ਢਾਂਚੇ ਦੇ ਦਸਤਾਵੇਜ਼ ਵਜੋਂ ਪੜ੍ਹੋ, ਹਰ ਇਤਿਹਾਸਕ ਸਾਈਫਰ ਅਤੇ ਕਮਜ਼ੋਰ ਸਮੂਹ ਚਾਲੂ ਕਰਨ ਦੇ ਸੱਦੇ ਵਜੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਇਵੇਂ ਕਰਕੇ ਸਫਲ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਉਹ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਜੋ ਤੁਹਾਨੂੰ ਬਣਾਉਣ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ।
ਸੂਟ 'ਤੇ ਸਹਿਮਤੀ ਬਣਾਓ, ਫਿਰ ਪੜਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਗੇਟਵੇ ਆਪਰੇਟਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੇ IKE ਅਤੇ ESP ਸੂਟ ਸਮਰਥਿਤ ਅਤੇ ਮਨਜ਼ੂਰ ਹਨ, ਫਿਰ ਉਸ ਜਵਾਬ ਦੀ ਤੁਲਨਾ ਕਲਾਇੰਟ ਦੀਆਂ ਅਸਲ ਪ੍ਰਸਤਾਵਾਂ ਨਾਲ ਕਰੋ, ਉਸਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਨਾਲ ਨਹੀਂ। ਜੇ ਅਸਹਿਮਤੀ ਖਾਸ ਤੌਰ 'ਤੇ ਪੜਾਅ 2 ਦੇ PFS ਬਾਰੇ ਹੈ, ਤਾਂ ਸਮਰਥਿਤ ਸਮੂਹ ਜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮਨਜ਼ੂਰ PFS-ਰਹਿਤ ਨੀਤੀ 'ਤੇ ਫੈਸਲਾ ਕਰੋ। ਗਲਤੀ ਦੇ ਨਾਮ ਤੋਂ ਨੀਤੀ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਓ।
ਜਦੋਂ ਇੱਕੋ ਇੱਕ ਓਵਰਲੈਪ ਅਜਿਹੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਮੰਗਦਾ ਹੈ ਜੋ ਸੰਸਥਾ ਹੁਣ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦੀ, ਫੈਸਲਾ ਗੇਟਵੇ ਦਾ ਜਾਂ ਪ੍ਰੋਟੋਕਾਲ ਤਬਦੀਲੀ ਦਾ ਹੈ। ਕਲਾਇੰਟ ਸਟਰਿੰਗ ਨੂੰ ਉਦੋਂ ਤੱਕ ਚੌੜਾ ਕਰਨਾ ਜਦੋਂ ਤੱਕ ਕੁਝ ਗੱਲਬਾਤ ਨਾ ਹੋਵੇ, ਜਾਣੀ ਜਾਣੀ ਕਮਜ਼ੋਰੀ ਨੂੰ ਨਾਲ ਹਰੀ ਟਿੱਕ ਲਾ ਕੇ ਭੇਜਣ ਦਾ ਤਰੀਕਾ ਹੈ।
ਅਸਲ ਅਸੰਗਤੀ ਸੁਧਾਰਨ ਤੋਂ ਬਾਅਦ, L2TP ਅਤੇ PPP ਦੀ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ IPsec ਸਥਾਪਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਪ੍ਰਮਾਣਿਕਤਾ ਰੱਦ ਨੂੰ ਅਗਲੇ ਪੜਾਅ ਦਾ ਮੰਨੋ। ਫਿਰ ਮਨਜ਼ੂਰ ਪਰੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਨਵੀਨੀਕਰਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਪਹਿਲੇ ਸੰਬੰਧ ਦੀ ਸਥਾਪਨਾ ਇਸਦੇ ਬਾਕੀ ਜੀਵਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।