ਇੱਕ IKEv2 ਲੌਗਇਨ ਵਿੱਚ ਦੋ ਪਛਾਣਾਂ: ਪਹਿਲਾਂ ਮਸ਼ੀਨ, ਫਿਰ ਉਪਭੋਗਤਾ
ਦੂਜੇ IKEv2 ਰਾਊਂਡ ਲਈ ਦੋਵਾਂ ਧਿਰਾਂ ਦੀ ਸਹਿਮਤੀ ਲੋੜੀਂਦੀ ਹੈ। ਤੁਸੀਂ ਜਿਸ ਐਂਡਪੌਇੰਟ 'ਤੇ ਹੋ ਉੱਥੋਂ local ਅਤੇ remote ਪੜ੍ਹੋ, ਫਿਰ ਉਹ ਜੋੜੀਆਂ ਜਾਂਚੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕਦੇ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਹੁੰਦੀ ਹੈ, ਪਹਿਲਾ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵਾਧੂ ਪ੍ਰਮਾਣਿਕਤਾ ਰਾਊਂਡ ਬਾਰੇ ਗਲਤੀ ਨਾਲ ਕਨੈਕਸ਼ਨ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਲੜੀ ਵਿੱਚ ਕੁਝ ਗਲਤ ਨਹੀਂ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ। ਗੇਟਵੇ ਨੂੰ ਜੁੜਨ ਵਾਲੀ ਧਿਰ ਤੋਂ ਦੂਜਾ ਸਬੂਤ ਮੰਗਣ ਲਈ ਕਨਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਉਹ ਕਦੇ ਨਹੀਂ ਭੇਜਦਾ। ਕੌਣ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ, ਇਹ ਤੈਅ ਕਰਨਾ ਹੀ ਪੂਰਾ ਕੰਮ ਹੈ, ਅਤੇ ਇਹ ਉਸੇ ਐਂਡਪੌਇੰਟ ਤੋਂ ਨੀਤੀ ਪੜ੍ਹਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਖੜ੍ਹੇ ਹੋ। ਵੱਖਰੀਆਂ ਕਿਸਮਾਂ ਦੇ ਦੋ ਸਬੂਤ, ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ, ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਹੈ, ਚੈੱਕਬਾਕਸ ਨਹੀਂ।
ਲੱਛਣ: ਸਫਲ ਪਹਿਲੇ ਸਬੂਤ ਤੋਂ ਬਾਅਦ ਅਸਫਲਤਾ
ਪਹਿਲਾ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਲੌਗ ਸਿਹਤਮੰਦ ਦਿਸਦਾ ਹੈ, ਜਦ ਤੱਕ ਗੇਟਵੇ EAP ਰਾਹੀਂ ਉਪਭੋਗਤਾ ਪਛਾਣ ਨਹੀਂ ਮੰਗਦਾ। ਫਿਰ ਹੈਂਡਸ਼ੇਕ ਰੁਕ ਜਾਂਦਾ ਹੈ ਜਾਂ ਵਾਧੂ ਰਾਊਂਡ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਵਾਪਸ ਆਉਂਦੀ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਇਜ਼ ਮਸ਼ੀਨ ਸਰਟੀਫਿਕੇਟ ਉਸ ਕਾਰਨ ਰੱਦ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਇਸਦੀ ਜਾਇਜ਼ਤਾ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ। ਨੀਤੀ ਨੇ ਦੂਜਾ ਸਬੂਤ ਮੰਗਿਆ ਸੀ, ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਜਵਾਬ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਿਆ।
ਉਸ ਅਸਫਲਤਾ ਦੇ ਦੋਵੇਂ ਵਰਣਨ ਤੁਸੀਂ ਕਿੱਥੇ ਖੜ੍ਹੇ ਹੋ ਇਸ ਆਧਾਰ 'ਤੇ ਸਹੀ ਹਨ। ਕਲਾਇੰਟ ਵੱਲੋਂ ਇਹ ਜਾਇਜ਼ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਵਾਂਗ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਲੌਗਇਨ ਪੂਰਾ ਨਾ ਕਰ ਸਕਣ ਵਾਲੇ ਕਲਾਇੰਟ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਉਹੀ ਘਟਨਾ ਇੱਕ ਲੌਗ ਵਿੱਚ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਸਮਰੱਥਾ ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। ਕਿਹੜੀ ਹੈ ਇਹ ਸਿਰਫ਼ ਕਨਫਿਗਰ ਕੀਤੀ ਨੀਤੀ ਦੱਸਦੀ ਹੈ।
ਐਕਸਟੈਂਸ਼ਨ ਕੀ ਜੋੜਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
IKEv2 ਇੱਕ ਹੀ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰਮਾਣਿਕਤਾ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਚਲਾਉਣ ਲਈ ਐਕਸਟੈਂਸ਼ਨ ਰੱਖਦਾ ਹੈ। RFC 4739 ਹੋਰ ਕ੍ਰਮਾਂ ਦੇ ਨਾਲ, ਸਰਟੀਫਿਕੇਟ ਪਛਾਣ ਸਾਬਤ ਕਰਕੇ ਫਿਰ EAP ਰਾਹੀਂ ਵਿਅਕਤੀ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ। ਦਸਤਾਵੇਜ਼ Experimental ਸਥਿਤੀ ਵਿੱਚ ਹੈ, ਭਾਵ ਕੋਈ ਵੀ ਅਮਲ ਕਰਨ ਵਾਲਾ ਤੁਹਾਨੂੰ ਇਹ ਸੁਵਿਧਾ ਦੇਣ ਲਈ ਪਾਬੰਦ ਨਹੀਂ। ਸਾਥੀ ਧਿਰ ਦੇ ਇਸ 'ਤੇ ਗੱਲਬਾਤ ਕਰਨ ਤੱਕ ਸਮਰਥਨ ਬਾਰੇ ਕੁਝ ਨਾ ਮੰਨੋ।
ਦੋਵਾਂ ਧਿਰਾਂ ਨੂੰ ਐਕਸਟੈਂਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਅਤੇ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਦੌਰਾਨ ਇਸ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪਵੇਗਾ। ਦੂਜੇ ਰਾਊਂਡ ਲਈ ਕਨਫਿਗਰ ਕੀਤਾ ਗੇਟਵੇ ਕਲਾਇੰਟ ਨੂੰ ਇਹ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਇਸਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਸਰਵਰ ਦੇ ਮੰਗਣ ਤੱਕ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰੇਗਾ। ਇਹ ਅਸਮਾਨਤਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਅਸਫਲਤਾ ਆਮ ਤੌਰ 'ਤੇ ਸਮਰੱਥਾ ਬਾਰੇ ਸਪਸ਼ਟ ਬਿਆਨ ਦੀ ਥਾਂ ਟਾਈਮਆਊਟ ਜਾਂ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਵਜੋਂ ਦਿਸਦੀ ਹੈ। ਇੱਕ ਧਿਰ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹਨ ਨਾਲ ਜੋ ਹੋਵੇਗਾ ਉਸਦਾ ਅੱਧਾ ਪਤਾ ਲੱਗਦਾ ਹੈ।
ਹਰ ਐਂਡਪੌਇੰਟ ਲਈ ਇੱਕ ਸਬੂਤ ਆਮ ਰੂਪ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੈ। ਗੇਟਵੇ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਉਪਭੋਗਤਾ EAP ਰਾਹੀਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਧਿਰ ਨੇ ਦੂਜੇ ਨੂੰ ਠੀਕ ਇੱਕ ਵਾਰ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਹੈ। ਉਹ ਦੋ ਸਬੂਤ ਵਿਰੋਧੀ ਸਿਰਿਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਮਸ਼ੀਨ ਅਤੇ ਇਸਨੂੰ ਵਰਤਣ ਵਾਲੇ ਵਿਅਕਤੀ ਬਾਰੇ ਵੱਖਰਾ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
EAP-TLS ਤੀਜਾ ਰੂਪ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਇਹ ਨਹੀਂ ਹੈ। ਉੱਥੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ EAP ਢੰਗ ਦੇ ਅੰਦਰ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਇੱਕ IKE ਪ੍ਰਮਾਣਿਕਤਾ ਪੂਰੀ ਕਰਦਾ ਹੈ। ਪ੍ਰਮਾਣ-ਪੱਤਰ ਬਹੁ-ਰਾਊਂਡ ਵਾਲੇ ਕੇਸ ਵਾਂਗ ਇੱਕੋ ਜਿਹੇ ਦਿਸ ਸਕਦੇ ਹਨ, ਜਦਕਿ ਪ੍ਰੋਟੋਕੋਲ ਦੋ ਦੀ ਥਾਂ ਇੱਕ ਰਾਊਂਡ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਇਸੇ ਲਈ EAP-TLS ਤੈਨਾਤੀ ਤੋਂ ਨਕਲ ਕੀਤਾ ਡਿਜ਼ਾਈਨ ਉੱਥੇ ਹੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਦੂਜੇ ਸਬੂਤ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ।
ਉਹੀ ਫਾਈਲ ਗੇਟਵੇ 'ਤੇ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ
ਉਹੀ swanctl ਫਾਈਲ ਕਿੱਥੇ ਚੱਲਦੀ ਹੈ ਇਸ ਆਧਾਰ 'ਤੇ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਠੋਕਰ ਮਾਰਦਾ ਹੈ। ਲੈਪਟਾਪ 'ਤੇ ਗੇਟਵੇ ਸਾਥੀ ਧਿਰ ਹੈ, ਅਤੇ ਗੇਟਵੇ 'ਤੇ ਲੈਪਟਾਪ ਸਾਥੀ ਧਿਰ ਹੈ, ਇਸ ਲਈ local ਧਿਰ ਨੂੰ ਮੈਂ ਕੌਣ ਹਾਂ ਅਤੇ remote ਧਿਰ ਨੂੰ ਮੈਂ ਕਿਸਨੂੰ ਸਵੀਕਾਰ ਕਰਾਂਗਾ ਲਿਖੋ। local ਬਲਾਕ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਐਂਡਪੌਇੰਟ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ remote ਬਲਾਕ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਦੂਜੇ ਸਿਰੇ ਤੋਂ ਕੀ ਮੰਗਦਾ ਹੈ। ਦੋ ਫਾਈਲਾਂ ਵਿਚਕਾਰ ਬਲਾਕ ਨਕਲ ਕਰਨ ਨਾਲ ਇੱਕ ਅੱਖਰ ਵੀ ਬਦਲੇ ਬਿਨਾਂ ਇਸਦਾ ਅਰਥ ਉਲਟ ਜਾਂਦਾ ਹੈ। ਦੋ ਫਾਈਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਨਾਲ ਲਗਭਗ ਕੁਝ ਵੀ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ, ਕਿਉਂਕਿ ਉਹੀ ਸ਼ਬਦ ਹਰ ਇੱਕ ਵਿੱਚ ਉਲਟ ਅਰਥ ਦਿੰਦੇ ਹਨ।
ਕਿਸੇ ਭਾਗ ਦੀ ਸਥਿਤੀ ਉਸਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀ ਹੈ, ਜਦ ਤੱਕ ਰਾਊਂਡ ਨੰਬਰ ਇਸਨੂੰ ਨਹੀਂ ਲੰਘਦਾ। ਇਸ ਲਈ ਵਾਧੂ local ਜਾਂ remote ਭਾਗ ਬਦਲ ਨਹੀਂ, ਵਾਧੂ ਰਾਊਂਡ ਦੱਸਦੇ ਹਨ, ਅਤੇ swanctl.conf ਹਵਾਲਾ ਵਿੱਚ ਸਪਸ਼ਟ ਰਾਊਂਡ ਨੰਬਰ ਉਸ ਕ੍ਰਮ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਉਣ ਲਈ ਹੀ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਬਲਾਕ ਹਿਲਾਉਣ ਨਾਲ ਵਿਵਹਾਰ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਕਾਗਜ਼ 'ਤੇ ਸਮਾਨ ਦਿਸਣ ਵਾਲੀਆਂ ਦੋ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਉਲਟ ਕ੍ਰਮ ਵਿੱਚ ਵਿਵਹਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਉਹ ਕ੍ਰਮ-ਨਿਯਮ ਯਾਦ ਰੱਖਣ ਯੋਗ ਅਸਫਲਤਾ-ਢੰਗ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਦੂਜਾ remote ਬਲਾਕ ਹੋਰ ਸਵੀਕਾਰਯੋਗ ਵਿਕਲਪ ਨਹੀਂ ਹੈ, ਇਹ ਦੂਜੀ ਮੰਗ ਹੈ, ਇਸ ਲਈ ਜਾਂ/ਜਾਂ ਵਜੋਂ ਪੜ੍ਹੀ ਜਾਣ ਵਾਲੀ ਨੀਤੀ ਅਤੇ-ਫਿਰ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਗੇਟਵੇ ਨੀਤੀ ਰਜਿਸਟਰਡ ਮਸ਼ੀਨ ਦਾ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਉਸ ਉਪਭੋਗਤਾ ਦਾ EAP ਅਦਾਨ-ਪ੍ਰਦਾਨ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਮੰਗ ਸਕਦੀ ਹੈ।
ਰਾਊਂਡਾਂ ਨੂੰ ਸੁਤੰਤਰ ਕਾਰਕਾਂ ਤੋਂ ਵੱਖਰਾ ਕਰੋ
ਦੋ ਰਾਊਂਡ ਆਪਣੇ ਆਪ ਦੋ ਸੁਤੰਤਰ ਕਾਰਕ ਨਹੀਂ ਹੁੰਦੇ। ਸਬੂਤ ਦੁਹਰਾਉਣਾ, ਜਾਂ ਇੱਕੋ ਭੰਡਾਰ ਵਿੱਚ ਦੋ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਖਣਾ, ਉਹ ਤਾਕਤ ਨਹੀਂ ਦਿੰਦਾ ਜੋ ਡਿਜ਼ਾਈਨ ਨੇ ਜੋੜਨੀ ਸੀ। ਸੁਤੰਤਰਤਾ ਇਸ ਗੱਲ ਦਾ ਗੁਣ ਹੈ ਕਿ ਭੇਤ ਕਿਵੇਂ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੀ ਉਨ੍ਹਾਂ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਕਿੰਨੇ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਰਾਊਂਡਾਂ ਨੂੰ ਕਾਰਕ ਗਿਣਨ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਆਪਣੇ ਕੋਲ ਜੋ ਹੈ ਉਸਨੂੰ ਵਧਾ-ਚੜ੍ਹਾ ਕੇ ਦੱਸਦਾ ਹੈ। ਇਹ ਫ਼ਰਕ ਸਭ ਤੋਂ ਵੱਧ ਉਦੋਂ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਅਨੁਪਾਲਨ ਦਾ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ ਕਿ ਲੌਗਇਨ ਅਸਲ ਵਿੱਚ ਕਿੰਨੇ ਕਾਰਕ ਵਰਤਦਾ ਹੈ।
ਮਸ਼ੀਨ ਸਰਟੀਫਿਕੇਟ ਆਪਣੀ ਸਵੀਕ੍ਰਿਤ ਚਾਬੀ ਦੀ ਮਾਲਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਇਹ ਹਾਰਡਵੇਅਰ ਪ੍ਰਮਾਣਨ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਜੰਤਰ-ਸਿਹਤ ਰਿਪੋਰਟ ਹੈ, ਇਸ ਲਈ ਸਥਿਤੀ ਜਾਣਕਾਰੀ ਚਾਹੁਣ ਵਾਲੀ ਨੀਤੀ ਨੂੰ ਹੋਰ ਵਿਧੀ ਚਾਹੀਦੀ ਹੈ। subject ਖੇਤਰ ਵੀ ਭਰੋਸੇਯੋਗ ਵਸਤੂ-ਸੂਚੀ ਟੈਗ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ subject ਉਹ ਚੁਣਦਾ ਹੈ ਜਿਸਨੇ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਜਾਂ ਰਜਿਸਟਰ ਕੀਤਾ। ਜੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ ਕਿ ਮਸ਼ੀਨ ਸਿਹਤਮੰਦ ਹੈ, ਤਾਂ ਉਹ ਸਬੂਤ ਮਸ਼ੀਨ ਨੂੰ ਮਾਪਣ ਵਾਲੇ ਹਿੱਸੇ ਤੋਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਰ ਰਾਊਂਡ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ ਇਹ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ। ਜਦੋਂ ਦੋ ਰਾਊਂਡ ਇੱਕੋ ਗੱਲ ਦੋ ਵਾਰ ਸਾਬਤ ਕਰਦੇ ਹਨ, ਦੂਜਾ ਭਰੋਸੇ ਦੀ ਥਾਂ ਦੇਰੀ ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਜੋੜਦਾ ਹੈ। ਉਹ ਨੋਟ ਹੀ ਇਸ ਬਹਿਸ ਨੂੰ ਰੋਕਦਾ ਹੈ ਕਿ ਵਾਧੂ ਰਾਊਂਡ ਆਪਣੀ ਲਾਗਤ ਦੇ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।
ਜੋੜੀ-ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਇਨਕਾਰ ਜਾਂਚੋ
ਕਿਹੜੀਆਂ ਮਸ਼ੀਨ ਪਛਾਣਾਂ ਕਿਹੜੇ ਲੋਕਾਂ ਨਾਲ ਜੋੜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਇਹ ਤੈਅ ਕਰੋ, ਅਤੇ ਨਿਯਮ ਉੱਥੇ ਲਿਖੋ ਜਿੱਥੇ ਲਾਗੂਕਰਨ ਰਹਿੰਦਾ ਹੈ। ਨਾਲ-ਨਾਲ ਰੱਖੇ ਦੋ ਜਾਇਜ਼ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜੋੜੀ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ, ਕਿਉਂਕਿ ਜੋੜੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਬਲਕਿ ਅਧਿਕਾਰ ਦਾ ਫੈਸਲਾ ਹੈ। ਰਜਿਸਟਰੇਸ਼ਨ ਰਿਕਾਰਡ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਬੈਕਐਂਡ ਨੂੰ ਸੰਸਥਾ ਦਾ ਚਾਹਿਆ ਸਬੰਧ ਲਾਗੂ ਕਰਨਾ ਪਵੇਗਾ।
ਫਿਰ ਉਹ ਜਾਂਚੋ ਜੋ ਅਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਨਾ-ਮਨਜ਼ੂਰ ਮਸ਼ੀਨ 'ਤੇ ਸਵੀਕ੍ਰਿਤ ਉਪਭੋਗਤਾ, ਮਸ਼ੀਨ ਦੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਾਲਾ ਨਾ-ਮਨਜ਼ੂਰ ਉਪਭੋਗਤਾ, ਅਤੇ ਵਾਧੂ ਰਾਊਂਡ ਨਾ ਕਰ ਸਕਣ ਵਾਲਾ ਸਾਥੀ। ਜੇ ਤਿੰਨੇ ਚੁੱਪਚਾਪ ਉਹੀ ਪਹੁੰਚ ਪਾ ਲੈਣ, ਤਾਂ ਨੀਤੀ ਲਾਗੂ ਕਰਨ ਦੀ ਥਾਂ ਇਰਾਦਾ ਦੱਸਦੀ ਹੈ। ਘੋਸ਼ਿਤ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਤੁਲਨਾ ਡੈਮਨ ਵੱਲੋਂ ਦੱਸੇ ਨਾਲ ਕਰੋ, ਕਿਉਂਕਿ ਕਦੇ ਨਾ ਮਿਲਿਆ ਕਨੈਕਸ਼ਨ ਪਾਸ ਹੋਏ ਨਿਯਮ ਵਾਂਗ ਹੀ ਦਿਸਦਾ ਹੈ:
swanctl --list-conns
swanctl --list-sas
ਸਿਰਫ਼ ਸਫਲ ਲੌਗਇਨ ਨਹੀਂ, ਸਗੋਂ ਗੱਲਬਾਤ ਹੋਏ ਰਾਊਂਡ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਮਿਲਣ ਵਾਲਾ ਅਧਿਕਾਰ ਵੀ ਜਾਂਚੋ। ਅਤੇ ਸ਼ਾਰਟਕਟ ਵਜੋਂ ਪੁਰਾਣੀਆਂ IKEv1 XAuth ਸੈਟਿੰਗਾਂ ਵੱਲ ਨਾ ਵਧੋ: ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੋਣ ਤੱਕ ਲੋੜੀਂਦਾ ਰਾਊਂਡ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਪ੍ਰੋਟੋਕੋਲ, ਭੂਮਿਕਾਵਾਂ, ਕ੍ਰਮ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਅਸਲ ਵਿਵਹਾਰ ਮਿਲਾਓ। ਜੋ ਰਾਊਂਡ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਉਸਨੂੰ ਮਿਟਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਦੋ-ਸਬੂਤ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਚੁੱਪਚਾਪ ਉਸ ਇੱਕ-ਸਬੂਤ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਜਿਸਦੀ ਕਿਸੇ ਨੇ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ। ਮਿਟਾਉਣ ਨੂੰ ਤਬਦੀਲੀ-ਰਿਕਾਰਡ ਵਿੱਚ ਰੱਖੋ।