RADIUS Access-Challenge ਤੋਂ ਬਾਅਦ VPN ਲੌਗਇਨ ਅਟਕ ਜਾਂਦਾ ਹੈ

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

ਇੱਕ ਲੌਗਇਨ, ਦੋ RADIUS ਅਦਾਨ-ਪ੍ਰਦਾਨ

ਜਦੋਂ ਬੈਕਐਂਡ ਦੂਜਾ ਕਾਰਕ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਪਹਿਲੀ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਸਵੀਕ੍ਰਿਤੀ ਜਾਂ ਇਨਕਾਰ ਨਾਲ ਨਹੀਂ ਦਿੰਦਾ। ਉਹ ਕੋਡ 11 ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਅਗਲੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਗੇਟਵੇ ਨੂੰ ਅਗਲੀ ਬੇਨਤੀ ਵਿੱਚ ਵਾਪਸ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ। ਉਹ ਅਗਲੀ ਬੇਨਤੀ ਉਸੇ ਪ੍ਰਮਾਣਿਕਤਾ ਗੱਲਬਾਤ ਦੀ ਹੈ, ਨਵੀਂ ਲੌਗਇਨ ਕੋਸ਼ਿਸ਼ ਦੀ ਨਹੀਂ।

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

ਇਹੀ ਉਹ ਲੱਛਣ ਹੈ ਜਿਸਦਾ ਪਿੱਛਾ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਸਿਰਫ਼ ਕਲਾਇੰਟ ਵੱਲੋਂ ਕਰਨਾ ਸੌਖਾ ਹੈ: ਜੇ VPN ਕਲਾਇੰਟ ਠੀਕ ਇੱਕ ਭੇਤ ਮੰਗਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹ ਪਾਸਵਰਡ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਵੈਧ ਹੈ, ਤਾਂ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਸ਼ਾਇਦ ਚੁਣੌਤੀ ’ਤੇ ਹੀ ਖਤਮ ਹੋ ਗਿਆ।

ਚੁਣੌਤੀ ਅਸਲ ਵਿੱਚ ਕੀ ਢੋਂਦੀ ਹੈ

RADIUS ਵਿਸ਼ੇਸ਼ਤਾ ਧਾਰਾ 4.4 ਵਿੱਚ ਕੋਡ 11 ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਦੋ ਗੁਣਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। Reply-Message ਵਰਤੋਂਕਾਰ ਲਈ ਰੱਖਿਆ ਟੈਕਸਟ ਰੱਖਦੀ ਹੈ, ਅਤੇ State ਇੱਕ ਅਸਪਸ਼ਟ ਮੁੱਲ ਰੱਖਦੀ ਹੈ ਜੋ ਸਰਵਰ ਵਾਪਸ ਚਾਹੁੰਦਾ ਹੈ। NAS ਨੂੰ State ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ, ਸਿਰਫ਼ ਉਸਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਵਾਪਸ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਗਲੀ ਬੇਨਤੀ ਨਵਾਂ Identifier ਅਤੇ ਨਵਾਂ Request Authenticator ਵਰਤਦੀ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਉਹੀ State ਮੁੱਲ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦਾ ਜਵਾਬ ਢੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਰਵਰ ਉਸਨੂੰ ਉਸੇ State ਰਾਹੀਂ ਉਡੀਕ ਰਹੀ ਚੁਣੌਤੀ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਇਸੇ ਲਈ ਗੁਣ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਜਾਂ ਛੱਡ ਦੇਣ ਵਾਲਾ ਗੇਟਵੇ ਇਹ ਰਸਮ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਹਰ ਜਵਾਬ ’ਤੇ response authenticator ਦੀ ਵੀ ਪੁਸ਼ਟੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ NAS ਨੂੰ ਪੈਕੇਟ ਸੁੱਟ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਧਾਰਾ 4.4 ਉਹ ਵੇਰਵਾ ਜੋੜਦੀ ਹੈ ਜੋ ਬਹੁਤੀਆਂ ਚੁੱਪ ਫੇਲ੍ਹਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ: ਜੋ NAS ਚੁਣੌਤੀਆਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ Access-Challenge ਨੂੰ ਇਨਕਾਰ ਮੰਨਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਗੇਟਵੇ ਦੀ VPN ਸੇਵਾ ਉਸ ਸਮਰਥਨ ਤੋਂ ਪੁਰਾਣੀ ਹੈ ਜਾਂ ਉਸਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਬੈਕਐਂਡ ਦੀ ਦੂਜੇ ਕਾਰਕ ਦੀ ਬੇਨਤੀ ਬਿਨਾਂ ਕਿਸੇ ਸੰਕੇਤ ਦੇ ਤੁਰੰਤ «ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹ» ਬਣ ਜਾਂਦੀ ਹੈ।

ਜ਼ੰਜੀਰਬੱਧ ਬੇਨਤੀ ਕਿੱਥੇ ਗੁੰਮ ਹੁੰਦੀ ਹੈ

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

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

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

ਇੱਕ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਟਰੇਸ ਕਰੋ

ਸਰਵਰ-ਸਾਈਡ ਡੀਬੱਗਿੰਗ ਚਾਲੂ ਰੱਖ ਕੇ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ, ਅਤੇ ਹਰ ਹੋਰ ਸੈਸ਼ਨ ਨੂੰ ਕੈਪਚਰ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਰੱਖੋ:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

ਆਉਟਪੁੱਟ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਦੀ ਬਜਾਏ ਗੱਲਬਾਤ ਦਾ ਆਕਾਰ ਲੱਭੋ। Identifier 3 ਵਾਲੀ ਪਹਿਲੀ Access-Request, State ਢੋਣ ਵਾਲੀ Access-Challenge, ਫਿਰ ਉਸ State ਨੂੰ ਦੁਹਰਾਉਣ ਵਾਲੀ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦਾ ਜਵਾਬ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੀ Identifier 4 ਵਾਲੀ ਦੂਜੀ Access-Request। ਜੇ ਦੂਜੀ ਬੇਨਤੀ ਗਾਇਬ ਹੈ, ਤਾਂ ਗੇਟਵੇ ਨੇ ਕਦੇ ਪਿੱਛਾ ਨਹੀਂ ਕੀਤਾ। ਜੇ ਉਹ State ਤੋਂ ਬਿਨਾਂ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਸਰਵਰ ਉਸਨੂੰ ਉਡੀਕ ਰਹੀ ਚੁਣੌਤੀ ਨਾਲ ਨਹੀਂ ਮਿਲਾ ਸਕਦਾ ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ।

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

ਤੁਸੀਂ ਜੋ ਅੰਤਿਮ ਸਥਿਤੀ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਹੈ ਪੂਰੀ ਹੋਈ, ਅਧਿਕਾਰਤ ਗੱਲਬਾਤ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਲੋੜੀਂਦੀ ਸੇਵਾ ਪਹੁੰਚ। RADIUS ਸਰਵਰ ਤੋਂ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਇਸ ਤੋਂ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ।