VPN ਗੇਟਵੇ ਰਾਹੀਂ EAP: ਵਿਧੀ ਕੌਣ ਖਤਮ ਕਰਦਾ ਹੈ

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

ਲੌਗ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਦੋ ਪ੍ਰਮਾਣਿਕਤਾ ਰਾਹ

ਪਹਿਲੇ ਰਾਹ ਵਿੱਚ VPN ਗੇਟਵੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਇਕੱਠੇ ਕਰਕੇ ਪਾਸਵਰਡ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ RADIUS Access-Request ਭੇਜਦਾ ਹੈ। ਪ੍ਰਮਾਣਿਕਤਾ ਸਰਵਰ ਇਸਦੀ ਤੁਲਨਾ ਆਪਣੇ ਭੰਡਾਰ ਨਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਸਵੀਕਾਰ ਜਾਂ ਅਸਵੀਕਾਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਕਲਾਇੰਟ ਕਦੇ ਵੀ EAP ਵਿਧੀ ਨਹੀਂ ਚਲਾਉਂਦਾ, ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਇਹ ਨਹੀਂ ਮੰਗਿਆ।

ਦੂਜੇ ਰਾਹ ਵਿੱਚ ਕਲਾਇੰਟ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸਰਵਰ EAP ਵਿਧੀ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਚਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਗੇਟਵੇ ਉਹਨਾਂ ਵਿਚਕਾਰ EAP-Message ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਭੇਜਦਾ ਹੈ। ਗੇਟਵੇ ਅਜੇ ਵੀ ਬਾਹਰੀ RADIUS ਗੱਲਬਾਤ ਖਤਮ ਕਰਦਾ ਹੈ, ਪਰ ਵਿਧੀ ਦਾ ਤਰਕ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਹੁੰਦਾ ਹੈ।

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

ਵਿਧੀ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਚੱਲਦੀ ਹੈ

RFC 3579 ਪਾਸ-ਥਰੂ ਪ੍ਰਬੰਧ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: NAS RADIUS ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ EAP ਪੈਕਟ ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹਰ EAP ਕਿਸਮ ਲਈ ਵਿਧੀ-ਖਾਸ ਕੋਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਲਈ ਗੇਟਵੇ PEAP ਅਤੇ EAP-TLS ਦੋਵਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਸਮਰਥਨ ਦੇ ਸਕਦਾ ਹੈ।

ਪਾਸਵਰਡ ਭੇਜਣ ਵਾਲਾ ਗੇਟਵੇ PEAP ਨਹੀਂ ਲੈ ਜਾਂਦਾ, ਭਾਵੇਂ ਬੈਕਐਂਡ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਤੋਂ PEAP ਸਵੀਕਾਰ ਕਰੇ। ਸਰਵਰ ਨੀਤੀ ਵਿੱਚ PEAP ਚਾਲੂ ਕਰਨਾ ਉਸ ਕਲਾਇੰਟ ਵਿੱਚ ਵਿਧੀ ਨਹੀਂ ਜੋੜਦਾ ਜਿਸਨੇ ਕਦੇ ਇੱਕ ਵੀ ਪੇਸ਼ ਨਹੀਂ ਕੀਤੀ।

PPP ਪ੍ਰਮਾਣਿਕਤਾ ਸੈਟਿੰਗਾਂ PPP ਸੇਵਾ ਦੀਆਂ ਹਨ। ਇਹ ਉਸੇ AAA ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਹਰ IPsec ਜਾਂ ਪੁਰਾਣੇ XAuth ਰਾਹ ਨੂੰ ਚੁੱਪਚਾਪ ਮੁੜ-ਸੰਰਚਿਤ ਨਹੀਂ ਕਰਦੀਆਂ, ਇਸ ਲਈ ਇੱਕ ਪਹੁੰਚ ਕਿਸਮ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬਦਲਾਅ ਦੂਜੇ ਨੂੰ ਅਛੂਤਾ ਛੱਡ ਸਕਦਾ ਹੈ।

NAS ਨੂੰ ਕੀ ਸਮਰਥਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ

ਪਾਸ-ਥਰੂ ਲੋੜ ਨੂੰ ਵਿਧੀ ਕੋਡ ਤੋਂ ਵਾਹਕ ਸਮਰਥਨ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਗੇਟਵੇ ਨੂੰ ਆਪਣੇ VPN ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ EAP ਲੈ ਜਾਣਾ ਸੰਭਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ 'ਤੇ RADIUS ਕਲਾਇੰਟ ਸੰਬੰਧਿਤ ਆਕਾਰ ਦੀਆਂ EAP-Message ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਭੇਜ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕੇ।

IKEv2 ਲਈ EAP ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਵਾਹ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਦੀ ਪਛਾਣ ਤੇ ਭਰੋਸਾ ਜਾਂਚ ਉਸੇ ਪ੍ਰਵਾਹ ਤੋਂ ਆਉਂਦੀ ਹੈ। 802.1X ਤੈਨਾਤੀ ਤੋਂ ਉਧਾਰਿਆ PEAP ਲੇਬਲ ਆਪਣੇ ਆਪ ਨਹੀਂ ਲੰਘਦਾ, ਕਿਉਂਕਿ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਗੱਲਬਾਤ ਵੱਖਰੀ ਹੈ।

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

ਨੀਤੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਪੜ੍ਹੋ

ਗੇਟਵੇ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸਰਵਰ 'ਤੇ ਇੱਕ ਮਨਜ਼ੂਰ ਕੋਸ਼ਿਸ਼ ਕੈਪਚਰ ਕਰੋ। RADIUS ਬੇਨਤੀ ਵਿੱਚ EAP-Message ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲੱਭੋ। ਉਹਨਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੱਸਦੀ ਹੈ ਕਿ ਪਾਸ-ਥਰੂ ਰਾਹ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ; ਗੈਰਹਾਜ਼ਰੀ ਪਹਿਚਾਣ ਪੱਤਰਾਂ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

Linux ਗੇਟਵੇ 'ਤੇ RADIUS ਪੋਰਟ 'ਤੇ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤਾਰ 'ਤੇ ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

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

ਸਥਾਨਾਂਤਰਨ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਇੱਕੋ ਬਦਲਾਅ ਵਜੋਂ ਯੋਜਨਾ ਬਣਾਓ

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

ਕੰਮ ਕਰਨ ਵਾਲਾ ਸੰਯੋਗ ਦਰਜ ਕਰੋ: VPN ਪ੍ਰੋਟੋਕੋਲ, EAP ਵਾਹਕ, ਸਾਥੀ ਵਿਧੀ, ਸਰਵਰ ਵਿਧੀ, ਪਹਿਚਾਣ ਪੱਤਰਾਂ ਦੀ ਕਿਸਮ ਅਤੇ ਸਰਵਰ ਪਛਾਣ ਜਾਂਚ।

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