IKEv2 ਅਦਲਾ-ਬਦਲੀ ਕੰਮ ਕਰਦੀ ਹੈ, ਫਿਰ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ: ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ

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

ਜਾਂਚ 1: ਸੁਨੇਹਾ ਨਹੀਂ, ਪੜਾਅ ਪੜ੍ਹੋ

ਰੱਦ ਕਰਨਾ ਤਿੰਨ ਥਾਵਾਂ ਤੋਂ ਆ ਸਕਦਾ ਹੈ: ਕਲਾਇੰਟ ਸਰਵਰ ਦੀ ਪਛਾਣ ਰੱਦ ਕਰਦਾ ਹੈ, ਗੇਟਵੇ ਕਲਾਇੰਟ ਦਾ ਸਬੂਤ ਰੱਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਹਰੀ ਪ੍ਰਮਾਣੀਕਰਨ ਸੇਵਾ ਖਾਤਾ ਰੱਦ ਕਰਦੀ ਹੈ।

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

ਜਾਂਚ 2: ਕਿਹੜੀ ਪਛਾਣ ਜਾਂਚੀ ਗਈ

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

strongSwan ਦੀ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਇਹ ਕਲਾਇੰਟ ਉੱਤੇ rightid ਹੈ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਗੇਟਵੇ ਦੀ ਆਪਣੀ ਪਛਾਣ, ਅਤੇ EAP ਦੀ ਗੱਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬੇਮੇਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

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

ਜਾਂਚ 3: ਜੇ EAP ਸ਼ਾਮਲ ਹੈ

ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਨੂੰ ਸਮਰਥਿਤ ਢੰਗ ਉੱਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪਵੇਗਾ, ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਦਿੱਤੀ ਪਛਾਣ ਸਵੀਕਾਰ ਕਰਨੀ ਪਵੇਗੀ।

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

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

ਜਾਂਚ 4: ਸਫਲ ਲਾਗਇਨ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ

IKE_AUTH ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, CHILD_SA ਗੱਲਬਾਤ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾ ਸਥਾਪਿਤ ਹੋਣਗੇ, ਅਤੇ ਉੱਥੇ ਹੀ ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੋ ਕੇ ਵੀ ਕੁਝ ਪਾਸ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਨਵਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਲਾਗਇਨ ਅਕਸਰ ਉਹ ਚੋਣਕਰਤਾ ਜਾਂ ਰੂਟ ਸਮੱਸਿਆ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਫੇਲ੍ਹਤਾ ਪਿੱਛੇ ਲੁਕੀ ਹੋਈ ਸੀ। ਜੇ ਟਨਲ ਉੱਪਰ ਆ ਜਾਂਦੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਫਿਰ ਵੀ ਆਪਣੀ ਮੰਜ਼ਿਲ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਤਾਂ ਦੁਬਾਰਾ ਪਛਾਣ ਵੱਲ ਨਹੀਂ ਸਗੋਂ ਗੱਲਬਾਤ ਵਾਲੇ ਚੋਣਕਰਤਾਵਾਂ ਅਤੇ ਰੂਟਾਂ ਵੱਲ ਵੇਖੋ। ਉਸ ਸਮੇਂ ਪਛਾਣ ਸੈਟਿੰਗਾਂ ਬਦਲਣਾ ਗਲਤ ਪੜਾਅ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਲਾਗਇਨ ਤੋੜ ਦਿੰਦਾ ਹੈ। swanctl --list-sas ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਜੋ IKE SA ਤੋਂ ਵੱਖਰੇ ਬੱਚਿਆਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਚੋਣਕਰਤਾਵਾਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ।

ਜਾਂਚ 5: ਸਹਾਇਤਾ ਨੂੰ ਕੀ ਦੇਣਾ ਹੈ

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

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