L2TP 'ਤੇ NO_PROPOSAL_CHOSEN? ਪਹਿਲਾਂ ਗੇਟਵੇ ਸਕੈਨ ਕਰੋ

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

ਸੁਨੇਹਾ ਕੀ ਬਾਹਰ ਰੱਖਦਾ ਹੈ

ਇਨਕਾਰ ਮੁੱਖ ਮੋਡ ਵਿੱਚ, ਕਿਸੇ ਵੀ L2TP ਜਾਂ PPP ਅਦਲਾ-ਬਦਲੀ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਅਤੇ ਵਰਤੋਂਕਾਰ ਡੇਟਾਬੇਸ ਨੂੰ ਨਹੀਂ ਪੁੱਛਿਆ ਗਿਆ। ਫੇਜ 1 ਇਨਕ੍ਰਿਪਸ਼ਨ, ਅਖੰਡਤਾ ਅਤੇ Diffie-Hellman ਸਮੂਹ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਫੇਜ 2 ਡੇਟਾ ਲਈ ESP ਪ੍ਰਸਤਾਵ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਫੇਜ 1 ਦੀ ਅਸਫਲਤਾ ਫੇਜ 2 ਦੀ PFS ਸੈਟਿੰਗ ਬਦਲ ਕੇ ਠੀਕ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਅਤੇ ਪੂਰਾ ਹੋਇਆ IKE ਸੰਬੰਧ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ESP ਪ੍ਰਸਤਾਵ ਢੁਕਵਾਂ ਹੈ।

ਸਿੰਟੈਕਸ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਬੈਕਐਂਡ ਨੋਟ ਕਰੋ: ipsec --version. libreswan ਅਤੇ strongSwan ਇੱਕੋ ਐਲਗੋਰਿਦਮ ਲਈ ਪ੍ਰਸਤਾਵ ਦੀਆਂ ਵੱਖਰੀਆਂ ਸਪੈਲਿੰਗਾਂ ਸਵੀਕਾਰਦੇ ਹਨ।

ਫਿਰ ਇਨਕਾਰ ਨੂੰ ਸੰਦਰਭ ਵਿੱਚ ਇਸ ਨਾਲ ਪੜ੍ਹੋ: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

ਗੇਟਵੇ ਦਾ ਟ੍ਰਾਂਸਫਾਰਮ ਸੈੱਟ ਸਕੈਨ ਕਰੋ

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

ਪੁਰਾਣੇ ਯੰਤਰ ਅਕਸਰ 3DES, SHA1 ਅਤੇ MODP1024 ਪੇਸ਼ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਤਪਾਦ ਭੇਜਣ ਸਮੇਂ ਇਹੀ ਡਿਫਾਲਟ ਸਨ ਅਤੇ ਕਿਸੇ ਨੇ ਇਨ੍ਹਾਂ ਦੀ ਦੁਬਾਰਾ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ। ਸਕੈਨ ਦਾ ਕੱਚਾ ਆਉਟਪੁੱਟ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਸ ਦਿਨ ਦੂਜੇ ਸਿਰੇ ਨੇ ਕੀ ਪੇਸ਼ ਕੀਤਾ, ਇਸ ਦਾ ਇਹੀ ਇੱਕੋ ਰਿਕਾਰਡ ਹੈ। ਜੇ ਇਹੀ ਉਪਲਬਧ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਓਵਰਲੈਪ ਹੈ, ਤਾਂ ਸਹੀ ਐਸਕਲੇਸ਼ਨ ਗੇਟਵੇ ਦੇ ਮਾਲਕ ਕੋਲ ਹੈ, ਨਾ ਕਿ ਅਜਿਹੇ ਕਲਾਇੰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਕੋਲ ਜੋ ਸਭ ਲਈ ਕਮਜ਼ੋਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਬੰਦ ਕੀਤੇ ਬਿਨਾਂ ਓਵਰਲੈਪ ਮਿਲਾਓ

ਕੇਵਲ ਉਹੀ ਟ੍ਰਾਂਸਫਾਰਮ ਦਾਖਲ ਕਰੋ ਜੋ ਸਕੈਨ ਅਤੇ ਤੁਹਾਡੀ ਨੀਤੀ ਦੋਵਾਂ ਵਿੱਚ ਦਿਸਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਫੇਜ 1 ਵਿੱਚ 3DES, SHA1 ਅਤੇ MODP1024 ਪੇਸ਼ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਬੈਕਐਂਡ ਬਾਰੇ ਚੇਤਾਵਨੀ ਵੱਲ ਧਿਆਨ ਦਿਓ: libreswan 4.x modp1024 ਸਮੂਹ ਨੂੰ ਕੰਪਾਇਲ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇਹ strongSwan ਜਾਂ DH2 ਸਹਾਇਤਾ ਵਾਲੇ libreswan ਬਿਲਡ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਖਰਾਬ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਸਕਰਣ ਦੀ ਜਾਂਚ ਕਰੋ।

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡੈਮਨ ਅਤੇ ਪੋਰਟ ਦੀ ਜਾਂਚ ਕਰੋ

NetworkManager-l2tp ਆਪਣਾ xl2tpd ਇੰਸਟੈਂਸ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜੇ ਸਿਸਟਮ ਸੇਵਾ ਕੋਲ ਪਹਿਲਾਂ ਹੀ UDP 1701 ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਅਸਥਾਈ ਸਰੋਤ ਪੋਰਟ 'ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦੀ RFC 3193 ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਸਰਵਰ ਚੁੱਪਚਾਪ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਾਕਟ ਦੇ ਮਾਲਕ ਦੀ ਜਾਂਚ ਕਰੋ।

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

ਬਾਸੀ ਤਿਆਰ ਕੀਤੇ ਭੇਤ ਦੂਜਾ ਚੁੱਪ ਕਾਰਨ ਹਨ। ਇੱਥੇ ਦੀਆਂ ਫਾਈਲਾਂ /etc/ipsec.d/ ਪੁਰਾਣੇ ਕਨੈਕਸ਼ਨ ਦੇ ਨਾਮ 'ਤੇ ਬਣੀਆਂ ਫਾਈਲਾਂ ਉਹਨਾਂ ਨੂੰ ਬਣਾਉਣ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਟਿਕ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਹਵਾਲਾ ਨਹੀਂ ਦਿੰਦਾ ਉਹਨਾਂ ਨੂੰ ਹਟਾਓ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।

ਅੰਤ ਵਿੱਚ, ਜਾਂਚੋ ਕਿ ਸਲਾਹ ਕਿੱਥੋਂ ਆਈ। ipsec.conf IKEv1 XAuth ਲਈ ਲਿਖੀ ਫਾਈਲ ਕਿਸੇ ਹੋਰ ਕਿਸਮ ਦੇ VPN ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਅਤੇ L2TP ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਇਸਦਾ ਪ੍ਰਸਤਾਵ ਹੀ ਇੱਕੋ ਗਲਤ ਲਾਈਨ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਦਾਖਲ ਕੀਤਾ ਟ੍ਰਾਂਸਫਾਰਮ ਸੈੱਟ ਪ੍ਰੋਫਾਈਲ ਦੇ ਕੋਲ ਨੋਟ ਕਰੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਂਚ ਨਾ ਦੁਹਰਾਏ।