Check Point ਜਾਂ Nortel ਵਿਰੁੱਧ vpnc: ਇਹ ਕਿਉਂ ਅਟਕਦਾ ਹੈ

ਲੱਛਣ ਨੂੰ ਗਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ: vpnc ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਸਮੂਹ ਦਾ ਪਾਸਵਰਡ ਮੰਗਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਗੱਲਬਾਤ ਦੇ ਇੱਕ ਪੜਾਅ ’ਤੇ ਬੈਠਾ ਰਹਿੰਦਾ ਹੈ ਜਦ ਤੱਕ ਇਹ ਨਾ ਦੱਸੇ ਕਿ ਟਾਰਗਟ ਤੋਂ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆ ਰਿਹਾ। ਆਉਟਪੁੱਟ ਵਿੱਚ ਕਿਤੇ ਵੀ ਗੇਟਵੇ ਉਤਪਾਦ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਖਾਤਾ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਪਸ਼ਟ ਸਿੱਟਾ ਗਲਤ ਪਾਸਵਰਡ ਜਾਂ ਰੋਕਿਆ ਪੋਰਟ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਗੇਟਵੇ ਬਿਲਕੁਲ ਵੀ IPsec ਸਾਥੀ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕਦੇ ਵੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਜਾਂਚਣ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਹੋਰ ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਪੈਟਰਨ ਨੂੰ ਜਾਂਚਣਾ ਢੁਕਵਾਂ ਹੈ।

ਪ੍ਰੋਫ਼ਾਈਲ ਦਾ ਹੋਰ ਖੇਤਰ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਤਪਾਦ ਦੀ ਪਛਾਣ ਕਰੋ।

ਅਸਫਲਤਾ ਗਲਤ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਵਾਂਗ ਦਿਸਦੀ ਹੈ

vpnc UDP 500 ’ਤੇ IKE ਭੇਜ ਕੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ, ਜੇ NAT ਟ੍ਰਾਵਰਸਲ ਦਿੱਤਾ ਜਾਵੇ, ਤਾਂ UDP 4500 ’ਤੇ ਵੀ। ਜੋ ਗੇਟਵੇ IPsec ਦੀ ਥਾਂ SSL ਖ਼ਤਮ ਕਰਦਾ ਹੈ, ਉਹ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਅੰਤ ਵਿੱਚ ਆਮ ਗਲਤੀ ਨਾਲ ਹਾਰ ਮੰਨ ਲੈਂਦਾ ਹੈ। ਜੇ ਉਹੀ ਖਾਤਾ ਛੋਟੀ ਸਹਾਇਕ ਐਪ ਲੋਡ ਕਰਨ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਪੋਰਟਲ ਰਾਹੀਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਪ੍ਰਬਲ ਸੰਕੇਤ ਹੈ ਕਿ ਸੁਰੰਗ SSL ਅਧਾਰਤ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਗਲਤ ਸਵਾਲ ਪੁੱਛ ਰਿਹਾ ਹੈ।

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

ਜਾਂਚੋ ਕਿ ਗੇਟਵੇ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕੋਲ ਦਿੰਦਾ ਹੈ

ਦੋ ਮਿੰਟ ਦੀ ਜਾਂਚ IPsec ਸਾਥੀ ਨੂੰ SSL ਪੋਰਟਲ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਉਸੇ ਨੈੱਟਵਰਕ ਤੋਂ ਚਲਾਓ ਜੋ ਕਲਾਇੰਟ ਵਰਤੇਗਾ, ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਕਿਹੜੇ ਪੋਰਟ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਨਾ ਕਿ ਕਿਹੜੇ ਕਿਸੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹਨ। ਨਤੀਜਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹੀ ਪੋਰਟ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਗੇਟਵੇ ਦੇ ਮਾਲਕ ਨੂੰ ਕਿਹੜਾ ਕਲਾਇੰਟ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਗੇਟਵੇ ਕੋਲ ਦੇ ਹੋਸਟ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਨੈੱਟਵਰਕ ਤੋਂ ਜਾਂਚੋ।

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

ਲੌਗਇਨ ਪੰਨੇ ’ਤੇ ਰੀਡਾਇਰੈਕਟ ਨਾਲ ਖੁੱਲ੍ਹਿਆ 443 ਅਤੇ 500 ਤੇ 4500 ’ਤੇ ਸੰਨਾਟਾ SSL VPN ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। 443 ’ਤੇ ਦਿੱਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ 500 ਅਤੇ 4500 ਖੁੱਲ੍ਹੇ ਹੋਣ ਤਾਂ ਇਹ IPsec ਗੇਟਵੇ ਸੂਚਿਤ ਕਰਦਾ ਹੈ ਜੋ ਵੈੱਬ ਫਰੰਟਐਂਡ ਵੀ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ vpnc ਠੀਕ ਇਸੇ ਸਥਿਤੀ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ।

Check Point ਦਾ SSL Network Extender ਅਤੇ Nortel ਦਾ Aventail ਕਲਾਇੰਟ ਦੋਵੇਂ ਦੂਜੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ IKEv1 ਸਮੂਹ ਭੇਤ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ।

vpnc ਪ੍ਰੋਫ਼ਾਈਲ ਕੀ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

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

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

ਗੇਟਵੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਕਲਾਇੰਟ ਚੁਣਨਾ

Check Point ਗੇਟਵੇ ਲਈ ਉਸ ਗੇਟਵੇ ਸੰਸਕਰਣ ਲਈ ਬਣਾਇਆ SNX ਪੈਕੇਜ ਵਰਤੋ, ਜੋ ਵਿਕਰੇਤਾ ਆਪਣੇ ਦੂਰ-ਪਹੁੰਚ ਦਸਤਾਵੇਜ਼ਾਂ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਪੁਰਾਣੇ SNX ਬਿਲਡ ਮੌਜੂਦਾ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ’ਤੇ ਅਕਸਰ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਹੁਣ ਸਥਾਪਿਤ ਨਾ ਹੋਈਆਂ 32-bit ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਆਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਤਿਆਗਿਆ ਪੈਕੇਜ ਪੈਚ ਕਰਨਾ ਆਮ ਤੌਰ ’ਤੇ ਸਮਰਥਿਤ ਪਲੇਟਫਾਰਮ ’ਤੇ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਚਲਾਉਣ ਨਾਲੋਂ ਬੁਰਾ ਹੁੰਦਾ ਹੈ।

Aventail ਕਲਾਇੰਟਾਂ ਨੇ ਬਹੁਤ ਪਹਿਲਾਂ ਸਮਰਥਨ ਗੁਆ ਦਿੱਤਾ। ਜਿੱਥੇ ਅਜਿਹਾ ਗੇਟਵੇ ਅਜੇ ਵੀ ਸੇਵਾ ਵਿੱਚ ਹੈ, ਉੱਥੇ ਸੰਗਠਨ ਸਮਰੱਥ ਕਰੇ ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਪੋਰਟਲ, ਜਾਂ ਸਮਰਥਿਤ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ’ਤੇ ਵਿਕਰੇਤਾ ਦਾ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਅਸਲੀ ਵਿਕਲਪ ਹਨ।

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