IKEv1 ਦਾ ਹਾਈਬ੍ਰਿਡ ਪ੍ਰਮਾਣੀਕਰਨ IKEv2 ਦੇ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ
ਹਾਈਬ੍ਰਿਡ ਮੋਡ ਗੇਟਵੇ ਦੇ ਸਬੂਤ ਨੂੰ ਵਰਤੋਂਕਾਰ ਦੇ ਸਬੂਤ ਤੋਂ ਵੱਖ ਰੱਖਦਾ ਸੀ। IKEv2 ਵੱਲ ਜਾਣ ਨਾਲ ਇਹ ਵੱਖਰਾਪਣ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਅਦਾਨ-ਪ੍ਰਦਾਨ, EAP ਢੰਗ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਜਾਂਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਹਰ ਪੁਰਾਣਾ VPN ਪਰੋਫਾਈਲ ਜੋ ਪਹਿਲਾਂ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਫਿਰ ਵਰਤੋਂਕਾਰ ਨਾਮ ਮੰਗਦਾ ਹੈ, ਇੱਕ ਹੀ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵਿੱਚ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀਆਂ ਦੋ ਘਟਨਾਵਾਂ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਇਹ ਰੂਪ ਉਸ ਪ੍ਰੋਟੋਕੋਲ ਤੋਂ ਵੱਧ ਜੀਵਦਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਲਿਆਂਦਾ। IKEv1 ਦਾ ਹਾਈਬ੍ਰਿਡ ਮੋਡ ਬਿਲਕੁਲ ਇਸੇ ਲਈ ਬਣਿਆ ਸੀ: ਗੇਟਵੇ ਆਪਣੇ ਆਪ ਨੂੰ ਜਨਤਕ ਕੁੰਜੀ ਨਾਲ ਸਿੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਬਾਅਦ ਵਿੱਚ XAuth ਰਾਹੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਸਿੱਧ ਕਰਦਾ ਹੈ। IKEv2 ਉਹੀ ਦੋ-ਪੜਾਅ ਵਾਲਾ ਵਿਚਾਰ ਦੂਜੀ ਮਸ਼ੀਨਰੀ ਨਾਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਫ਼ਰਕਾਂ ਵਿੱਚ ਹੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਕੋਈ ਸੰਸਕਰਣ ਸੰਖਿਆ ਇੱਕ ਨੂੰ ਦੂਜੇ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀ, ਅਤੇ ਪੁਰਾਣੇ ਵਿਕਲਪਾਂ ਦੇ ਨਾਮ ਨਵੀਂ ਪਰੋਫਾਈਲ ਵਿੱਚ ਨਕਲ ਕਰਨ ਨਾਲ ਅਜਿਹਾ ਕਲਾਇੰਟ ਮਿਲਦਾ ਹੈ ਜੋ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕੁਝ ਵੀ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ।
ਹਾਈਬ੍ਰਿਡ ਮੋਡ ਨੇ IKEv1 ਦੇ ਅੰਦਰ ਕੀ ਕੀਤਾ
ਹਾਈਬ੍ਰਿਡ ਪਰੋਫਾਈਲ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪੱਖ ਪਹਿਲੇ ਪੜਾਅ ਦੇ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਉੱਤੇ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਦਸਤਖ਼ਤ ਕਰਦਾ ਹੈ ਜਦਕਿ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੋਈ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਇਸ ਲਈ ਪਛਾਣ ਦਾ ਸਬੂਤ ਅਸਮਮਿਤ ਹੈ, ਅਤੇ ਇਸੇ ਨੇ ਗੇਟਵੇ ਨੂੰ ਆਪਣਾ ਮੌਜੂਦਾ PKI ਰੱਖਣ ਅਤੇ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਆਪਣੇ ਡਾਇਰੈਕਟਰੀ ਪਾਸਵਰਡ ਰੱਖਣ ਦਿੱਤੇ। ਪਹਿਲਾ ਪੜਾਅ ਪੂਰਾ ਹੋਣ ’ਤੇ XAuth ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਵਜੋਂ ਚੱਲਦਾ ਹੈ ਜੋ ਹੁਣ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ISAKMP ਚੈਨਲ ਦੇ ਅੰਦਰ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਦੇ ਗੁਣ ਲੈ ਜਾਂਦਾ ਹੈ।
ਧਿਆਨ ਦਿਓ ਭਰੋਸਾ ਕਿੱਥੇ ਪਹੁੰਚਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਦੱਸਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਿਸ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਿਆ; XAuth ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਵਰਤੋਂਕਾਰ ਪਹੁੰਚ ਚਾਹੁੰਦਾ ਹੈ। ਕੋਈ ਕਿਸੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਸੈੱਟ ਕਲਾਇੰਟ ਚੁੱਪਚਾਪ ਪਹਿਲਾ ਜਵਾਬ ਸੁੱਟ ਚੁੱਕਾ ਹੈ। ਹਾਈਬ੍ਰਿਡ ਦਾ ਲੇਬਲ ਪਹਿਲਾਂ ਤੋਂ ਸਾਂਝੀ ਕੁੰਜੀ ਵਾਲੇ ਹਮਲਾਵਰ ਮੋਡ ਅਤੇ XAuth ਲਈ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਉਸੇ ਵਰਤੋਂਕਾਰ ਤਜਰਬੇ ਵਾਲੀ ਵੱਖਰੀ ਬਣਤਰ ਹੈ, ਇਸ ਲਈ ਨਾਮ ਨਹੀਂ, ਪਰੋਫਾਈਲ ਪੜ੍ਹੋ। ਦੋਵੇਂ ਰੂਪ ਉਨ੍ਹਾਂ ਖਰੜਿਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜੋ ਕਦੇ ਮਿਆਰ ਨਹੀਂ ਬਣੇ, ਅਤੇ ਇਸੇ ਲਈ ਦੋ ਨਿਰਮਾਤਾ ਹਾਈਬ੍ਰਿਡ ਮੋਡ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਨਾਲ ਅੰਤਰ-ਸੰਚਾਲਨ ਨਹੀਂ ਕਰ ਸਕਦੇ।
IKEv2 ਉਨ੍ਹਾਂ ਦੋ ਸਬੂਤਾਂ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ
IKEv2 ਕੰਮ ਨੂੰ IKE_SA_INIT ਅਤੇ IKE_AUTH ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਪਹਿਲਾ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕਿਸੇ ਵੀ ਪਛਾਣ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਸਤਾਵਾਂ ਅਤੇ ਕੁੰਜੀਆਂ ਉੱਤੇ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ; ਦੂਜਾ IDi, IDr ਅਤੇ AUTH ਪੇਲੋਡ ਲੈ ਜਾਂਦਾ ਹੈ। EAP ਦੇ ਅਧੀਨ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ ਦਾ ਪਹਿਲਾ AUTH ਪੇਲੋਡ ਖਾਲੀ ਜਾਂਦਾ ਹੈ, ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਹਿਲਾਂ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਦਸਤਖ਼ਤ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ EAP ਗੱਲਬਾਤ IKE_AUTH ਸੁਨੇਹਿਆਂ ਦੇ ਅੰਦਰ ਚੱਲਦੀ ਹੈ।
ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਵਾਲੀ ਮਸ਼ੀਨਰੀ ਕੁੰਜੀ ਸਮੱਗਰੀ ਹੈ। ਸਫਲ EAP ਢੰਗ ਇੱਕ ਸੈਸ਼ਨ ਕੁੰਜੀ ਨਿਰਯਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ ਦਾ ਆਖਰੀ AUTH ਪੇਲੋਡ ਉਸੇ ਤੋਂ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਵਰਤੋਂਕਾਰ ਦਾ ਸਬੂਤ ਅਤੇ ਸੁਰੰਗ ਦੀਆਂ ਕੁੰਜੀਆਂ ਆਪਸ ਵਿੱਚ ਬੱਝੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। XAuth ਦਾ ਅਜਿਹਾ ਕੋਈ ਬਰਾਬਰ ਨਹੀਂ: ਉਸ ਦੇ ਗੁਣ ਪਹਿਲੇ ਪੜਾਅ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਹਨ ਅਤੇ ਕੁੰਜੀਆਂ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਜੋੜਦੇ। ਇਹੀ ਖਾਲੀ ਥਾਂ IKEv2 ਢਾਂਚੇ ਨੇ ਭਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਸੇ ਲਈ ਕੰਮ ਕਰਦਾ IKEv2 ਲੌਗਇਨ ਕੁਝ ਵੀ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।
ਇਹ ਕ੍ਰਮ ਇੱਕ ਲਾਹੇਵੰਦ ਨਿਦਾਨ ਵੀ ਹੈ। ਜਦੋਂ ਕਲਾਇੰਟ ਤੁਹਾਨੂੰ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ IKEv2 EAP ਅਦਾਨ-ਪ੍ਰਦਾਨ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਤਿੰਨ ਪਛਾਣਾਂ ਵੱਖ ਰੱਖੋ
ਮਾਈਗ੍ਰੇਸ਼ਨ ਤਦ ਬਿਗੜਦਾ ਹੈ ਜਦੋਂ ਤਿੰਨ ਪਛਾਣਾਂ ਇੱਕ ਹੀ ਖੇਤਰ ਵਿੱਚ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ। ਗੇਟਵੇ ਦੀ ਪਛਾਣ ਹੈ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ ਸਰਟੀਫਿਕੇਟ ਦੇ subject ਜਾਂ SAN ਵਿੱਚ DNS ਨਾਮ। EAP ਵਿੱਚ ਪੇਸ਼ ਵਰਤੋਂਕਾਰ ਦੀ ਪਛਾਣ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਡੋਮੇਨ ਲੌਗਇਨ, ਪਤਾ ਜਾਂ ਸਪਸ਼ਟ EAP ਪਛਾਣ ਸਟ੍ਰਿੰਗ। ਅਤੇ ਉਹ ਅਧਿਕਾਰ ਸਰੋਤ ਹੈ ਜੋ ਉਸ ਵਰਤੋਂਕਾਰ ਨੂੰ ਨੈੱਟਵਰਕ ਅਤੇ ਰਾਹਾਂ ਉੱਤੇ ਨਕਸ਼ਾ ਕਰਦਾ ਹੈ।
strongSwan ਦਾ swanctl ਸੰਟੈਕਸ ਵੱਖਰਾਪਣ ਦਿਖਾਉਂਦਾ ਹੈ: ਕਨੈਕਸ਼ਨ ਗੇਟਵੇ ਲਈ remote { auth = pubkey } ਅਤੇ ਵਰਤੋਂਕਾਰ ਲਈ local { auth = eap-mschapv2 } ਸੈੱਟ ਕਰਦਾ ਹੈ, ਅਤੇ EAP ਪਛਾਣ ਵੱਖਰੀ ਢੋਈ ਜਾਂਦੀ ਹੈ।
ਜਦੋਂ ਨਵੀਂ ਪਰੋਫਾਈਲ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਦੀ ਪਛਾਣ ਪੁਰਾਣੇ XAuth ਗੁਣਾਂ ਤੋਂ ਵੱਖਰੀ ਹੋਵੇ, ਜਿਵੇਂ ਛੋਟੇ ਨਾਮ ਦੀ ਥਾਂ UPN, ਪ੍ਰਮਾਣੀਕਰਨ ਸਰਵਰ ਅਣਜਾਣ ਵਰਤੋਂਕਾਰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣਾ ਗਲਤ ਪਾਸਵਰਡ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਸਟ੍ਰਿੰਗ ਜਾਂਚੋ।
ਵਿਕਲਪਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ ਅਤੇ ਫਿਰ ਜਾਲਾਂ ਦੀ ਉਮੀਦ ਕਰੋ
ਨਕਸ਼ਾ ਛੋਟਾ ਹੈ ਅਤੇ ਹਰ ਕਤਾਰ ਵਿੱਚ ਇੱਕ ਜਾਲ ਹੈ ਜੋ ਸਿਰਫ਼ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਸਮੇਂ ਦਿਸਦਾ ਹੈ।
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ਉਨ੍ਹਾਂ ਕਤਾਰਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਿਰਫ਼ ਨਾਮ ਬਦਲਣਾ ਨਹੀਂ। ਸੰਰਚਨਾ ਪੇਲੋਡ ਪਤੇ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਟਾਈਪ ਕੀਤੀ ਗੁਣ ਸੂਚੀ ਰਾਹੀਂ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਜਦਕਿ XAuth ਦਾ ਗੁਣ ਖੇਤਰ ਉਸਦੀ ਆਪਣੀ ਕਾਢ ਸੀ; ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲਣਯੋਗ ਮੰਨਣਾ ਉਹੀ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਪਰੋਫਾਈਲ ਅਜਿਹੀ ਸੈਟਿੰਗ ਮੰਗਦੀ ਹੈ ਜੋ ਗੇਟਵੇ ਕਦੇ ਨਹੀਂ ਭੇਜੇਗਾ।
ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾ ਆਪਣੀ ਵੱਖਰੀ ਚੇਤਾਵਨੀ ਦੇ ਹੱਕਦਾਰ ਹਨ। IKEv1 ਦਿਲਚਸਪ ਟ੍ਰੈਫਿਕ ਨੂੰ quick mode ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨਾਲ ਬੱਝੀਆਂ ਪ੍ਰੌਕਸੀ ਆਈਡੀਆਂ ਨਾਲ ਪੇਸ਼ ਕਰਦਾ ਸੀ, ਜਦਕਿ IKEv2 IKE_AUTH ਦੌਰਾਨ ਚੋਣਕਰਤਾਵਾਂ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਕਰਾ ਕਰ ਸਕਦਾ ਹੈ। ਬੇਮੇਲ ਹੋਣ ’ਤੇ child SA ਤੋਂ ਬਿਨਾਂ ਸਥਾਪਿਤ IKE SA ਬਣਦਾ ਹੈ, ਜਿਸਨੂੰ ਕੁਝ ਕਲਾਇੰਟ ਖੁਸ਼ੀ ਨਾਲ ਜੁੜਿਆ ਦਿਖਾਉਂਦੇ ਹਨ।
ਪੁਰਾਣੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸੀਮਾ ਮੰਨੋ
RFC 9395 IKEv1 ਨੂੰ ਪੁਰਾਣਾ ਐਲਾਨਦਾ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣਾ ਹਾਈਬ੍ਰਿਡ ਕਨੈਕਸ਼ਨ ਤਾਰੀਖ਼ ਵਾਲੀ ਅਨੁਕੂਲਤਾ ਦੀ ਸੀਮਾ ਹੈ, ਨੀਂਹ ਨਹੀਂ। ਬਦਲਾਅ ਦੌਰਾਨ ਦੋਵੇਂ ਪਰੋਫਾਈਲ ਨਾਲ-ਨਾਲ ਚਲਾਓ, ਕਿਉਂਕਿ ਅਹਿਮ ਪਰਖ ਇਹ ਨਹੀਂ ਕਿ ਨਵੀਂ ਪਰੋਫਾਈਲ ਉੱਠਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਕਿ ਉਹੀ ਵਰਤੋਂਕਾਰ ਉਸੇ ਡਿਵਾਈਸ ਉੱਤੇ ਉਨ੍ਹਾਂ ਹੀ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸਖ਼ਤ ਰੱਖੋ। ਜਿਵੇਂ ਹੀ ਕਲਾਇੰਟ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਣਾ ਬੰਦ ਕਰਦਾ ਹੈ, ਲਾਲਚ ਹੁੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਜਾਂਚ ਢਿੱਲੀ ਕੀਤੀ ਜਾਵੇ ਜਦ ਤੱਕ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੋਵੇ, ਅਤੇ ਇਹ ਬਚਿਆ ਇੱਕੋ-ਇੱਕ ਸਬੂਤ ਹਰੇ ਨਿਸ਼ਾਨ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਪੁਰਾਣੀ ਪਰੋਫਾਈਲ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਲਿਖੋ: EAP ਢੰਗ, ਪਛਾਣ ਸਟ੍ਰਿੰਗ, ਅਧਿਕਾਰ ਸਰੋਤ ਅਤੇ ਉਹ ਤਾਰੀਖ਼ ਜਦੋਂ ਸਹਾਇਤਾ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ।