Windows ਅਤੇ FortiGate 'ਤੇ IKEv2: ਲੋਕ ਜੋੜਦੇ ਹਨ ਅਜਿਹੀਆਂ ਤਿੰਨ ਸੈਟਿੰਗਾਂ
IKE ਕੁੰਜੀ ਤਬਾਦਲਾ, CHILD SA ਸੁਰੱਖਿਆ ਅਤੇ ਪੀਅਰ ਪ੍ਰਮਾਣਿਕਤਾ ਤਿੰਨ ਵੱਖਰੀਆਂ ਕਤਾਰਾਂ ਹਨ। ਦੋ ਸੰਵਾਦਾਂ ਵਿੱਚ ਗਰੁੱਪ ਨੰਬਰ ਮਿਲ ਜਾਣ ਨਾਲ ਵੀ ਉਹ ਜੁੜਦੀਆਂ ਨਹੀਂ।
Windows ਕਲਾਇੰਟ ਅਤੇ FortiGate ਗੇਟਵੇ ਵਿਚਕਾਰ IKEv2 ਸਮਝੌਤਾ ਲਗਾਤਾਰ ਅਸਫਲ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਨਾ ਮਿਲਣ ਵਾਲੇ ਨੰਬਰ ਦੀ ਭਾਲ ਹੋਰ ਲੰਮੀ ਨੰਬਰ ਸੂਚੀ ਬਣਾਉਂਦੀ ਹੈ। ਸੂਚੀ ਤਦ ਹੀ ਸੰਭਾਲਣਯੋਗ ਬਣਦੀ ਹੈ ਜਦੋਂ ਇਸਨੂੰ ਤਿੰਨ ਕਤਾਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇ ਜੋ ਸੁਤੰਤਰ ਰੂਪ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ: IKE ਦੀ ਸੁਰੱਖਿਆ ਕਰਨ ਵਾਲਾ ਕੁੰਜੀ ਤਬਾਦਲਾ, CHILD SA 'ਤੇ ਲਾਗੂ ਸੁਰੱਖਿਆ, ਅਤੇ ਹਰ ਪਾਸਾ ਕੌਣ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨ ਵਾਲੀ ਪ੍ਰਮਾਣਿਕਤਾ। ਗਰੁੱਪ ਨੰਬਰ ਉਨ੍ਹਾਂ ਕਤਾਰਾਂ ਵਿੱਚੋਂ ਦੋ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਅਰਥ ਰੱਖਦੇ ਹਨ।
ਸੁਤੰਤਰ ਰੂਪ ਨਾਲ ਅਸਫਲ ਹੋਣ ਵਾਲੀਆਂ ਤਿੰਨ ਕਤਾਰਾਂ
ਪਹਿਲੀ ਕਤਾਰ IKE ਦੇ ਅੰਦਰਲਾ ਕੁੰਜੀ ਤਬਾਦਲਾ ਹੈ, ਜੋ ਗੱਲਬਾਤ ਦੀ ਸੁਰੱਖਿਆ ਕਰਨ ਵਾਲੀਆਂ ਕੁੰਜੀਆਂ ਬਣਾਉਂਦਾ ਹੈ। ਦੂਜੀ CHILD SA ਲਈ ਪ੍ਰਸਤਾਵ ਹੈ, ਜੋ ਸੁਰੰਗ ਦੁਆਰਾ ਲਿਜਾਏ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਦੀ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਤੀਜੀ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ, ਜੋ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਹਰ ਪਾਸਾ ਕੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਪਾਸਾ ਉਸਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ।
ਅਸਫਲਤਾਵਾਂ ਵੱਖਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ। ਤਬਾਦਲੇ ਦੀ ਅਸਫਲਤਾ ਕੋਈ ਸੁਰੰਗ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਗੱਲਬਾਤ ਰੋਕ ਦਿੰਦੀ ਹੈ। CHILD SA ਦੀ ਅਸਫਲਤਾ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ, ਕਦੇ-ਕਦੇ ਸਿਰਫ਼ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ 'ਤੇ। ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਅਸਫਲਤਾ ਲੌਗ ਵਿੱਚ ਤਬਾਦਲੇ ਦੀ ਅਸਫਲਤਾ ਵਾਂਗ ਦਿਖ ਸਕਦੀ ਹੈ, ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਪਹਿਲੀ ਗਲਤੀ ਪੜ੍ਹੋ।
ਕਤਾਰਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹਿਸਾਬ-ਕਿਤਾਬ ਨਹੀਂ ਹੈ। ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸੈਟਿੰਗ ਬਦਲਣ ਯੋਗ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਪੂਰੇ ਖੇਤਰ ਦਾ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਕਦਮ ਰੋਕਦਾ ਹੈ, ਭਾਵ ਪ੍ਰਸਤਾਵ ਦੀ ਅਸੰਗਤੀ ਠੀਕ ਕਰਨ ਲਈ ਕੰਮ ਕਰ ਰਹੇ ਪ੍ਰਮਾਣਪੱਤਰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ। ਇੱਕ ਕਤਾਰ ਦਾ ਬਦਲਣਾ ਕਦੇ ਵੀ ਬਾਕੀ ਦੋ ਨੂੰ ਆਪਣੇ ਨਾਲ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹੀ ਆਜ਼ਾਦੀ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਲਿਖਣ ਦਾ ਪੂਰਾ ਉਦੇਸ਼ ਹੈ।
Windows ਦੇ ਦੋ ਖੇਤਰ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ
Windows ਦੋ ਖੇਤਰ ਵੱਖਰੇ ਰੱਖਦਾ ਹੈ: DHGroup ਆਪ IKE ਤਬਾਦਲਾ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ PfsGroup ਸੁਰੰਗ ਦੇ ਅੰਦਰਲੇ ਟ੍ਰੈਫਿਕ ਦੀ ਸੁਰੱਖਿਆ ਕਰਨ ਵਾਲੀ IPsec ਨੀਤੀ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ। ਉਹ ਵੱਖਰੇ ਪੜਾਵਾਂ ਦੇ ਹਨ। Windows ਦੇ IKE ਖੇਤਰ ਦੀ FortiGate ਦੇ ਪੜਾਅ 2 ਮੁੱਲ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਗਲਤ ਜੋੜੀ ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੈ, ਅਤੇ ਨੰਬਰ ਮਿਲ ਸਕਦੇ ਹਨ ਪਰ ਅਧੀਨ ਤਬਾਦਲਾ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAਦੂਜੀ ਅਤੇ ਤੀਜੀ ਕਮਾਂਡ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਸੁਰੱਖਿਆ ਸੰਬੰਧਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਕਲਾਇੰਟ ਤੁਹਾਨੂੰ ਦੇ ਸਕਣ ਵਾਲੇ ਜਵਾਬ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਹੈ। ਮੁੱਖ ਮੋਡ ਸੰਬੰਧ ਹੋਣ ਪਰ ਤੇਜ਼ ਮੋਡ ਸੰਬੰਧ ਨਾ ਹੋਣਾ CHILD SA ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਮਾਣਪੱਤਰ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸਗੋਂ ਪੜਾਅ 2 ਦੀ ਅਸੰਗਤੀ ਦਾ ਸੰਕੇਤ ਹੈ।
ਇੱਕ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਕੀ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਅਤੇ ਕੀ ਚੁਣਿਆ ਗਿਆ, ਇਹ ਦਰਜ ਕਰੋ। ਜਿਸ ਪ੍ਰਸਤਾਵ ਸੂਚੀ ਵਿੱਚ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਸਤਾਵ ਹੈ ਪਰ ਚੁਣਿਆ ਪ੍ਰਸਤਾਵ ਗੇਟਵੇ ਦੀ ਨੀਤੀ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਉਹ ਸੰਰਚਨਾ ਅਸਹਿਮਤੀ ਹੈ, ਅੰਤਰ-ਸੰਚਾਲਨ ਦਾ ਰਹੱਸ ਨਹੀਂ।
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
ਦੀਰਘਵ੍ਰੱਤੀ ਵਕਰ ਦਾ ਗਰੁੱਪ ਤੁਹਾਡੀ ਦਸਤਖਤ ਕੁੰਜੀ ਨਹੀਂ ਚੁਣਦਾ
ਇਸ ਖੇਤਰ ਦਾ ਸਭ ਤੋਂ ਜ਼ਿੱਦੀ ਗਲਤ ਅਨੁਮਾਨ ਇਹ ਹੈ ਕਿ ਦੀਰਘਵ੍ਰੱਤੀ ਵਕਰ ਦਾ DH ਗਰੁੱਪ ਚੁਣਨ ਲਈ ਦੀਰਘਵ੍ਰੱਤੀ ਵਕਰ ਦਾ ਪ੍ਰਮਾਣਪੱਤਰ ਲਾਜ਼ਮੀ ਹੈ। DH ਗਰੁੱਪ ਕੁੰਜੀ ਤਬਾਦਲੇ ਦੀ ਸਮੱਗਰੀ ਦਿੰਦਾ ਹੈ; ਦਸਤਖਤ ਐਲਗੋਰਿਦਮ ਦੀ ਗੱਲਬਾਤ ਪ੍ਰਮਾਣਿਕਤਾ ਢਾਂਚਾ ਕਰਦਾ ਹੈ, ਅਤੇ IKEv2 ਵਿੱਚ ਇਹ ਦੋ ਵੱਖਰੇ ਫੈਸਲੇ ਹਨ।
RFC 7427 ਠੀਕ ਇਸ ਲਈ ਮੌਜੂਦ ਹੈ ਕਿ ਇਹ ਫੈਸਲੇ ਪਹਿਲਾਂ ਉਲਝੇ ਹੋਏ ਸਨ, ਅਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਦਸਤਖਤ ਐਲਗੋਰਿਦਮ ਕੁੰਜੀ ਤਬਾਦਲੇ ਤੋਂ ਸੁਤੰਤਰ ਰੂਪ ਨਾਲ ਕਿਵੇਂ ਘੋਸ਼ਿਤ ਅਤੇ ਚੁਣੇ ਜਾਂਦੇ ਹਨ। ਗੇਟਵੇ ਇੱਕੋ ਸਮੇਂ ਵਕਰ ਗਰੁੱਪ ਅਤੇ ਦਸਤਖਤ ਯੋਜਨਾਵਾਂ ਦੀ ਚੋਣ ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸ ਲਈ ਜਦੋਂ ਗਰੁੱਪ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਗੱਲਬਾਤ ਅਸਫਲ ਹੋਵੇ, ਪ੍ਰਮਾਣਪੱਤਰ ਦੀ ਕੁੰਜੀ ਦੀ ਕਿਸਮ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਵੇਖੋ। ਪ੍ਰਮਾਣਪੱਤਰ ਬਦਲਣਾ ਹੌਲੀ ਅਤੇ ਜੋਖਮ ਭਰਿਆ ਕੰਮ ਹੈ ਜੋ ਘੱਟ ਹੀ ਜਵਾਬ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਪਹਿਲਾਂ ਕਰਨ ਨਾਲ ਇਹ ਜਾਣਨ ਦੀ ਤੁਹਾਡੀ ਸਮਰੱਥਾ ਨਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਬਦਲਾਅ ਨੇ ਸੱਚਮੁੱਚ ਮਦਦ ਕੀਤੀ। ਪ੍ਰਮਾਣਪੱਤਰ ਭੰਡਾਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਤਾਰ ਪੜ੍ਹੋ।
ਦੋਵਾਂ ਨੂੰ ਸਮਝੌਤਾ ਪੱਤਰ ਦੀਆਂ ਵੱਖਰੀਆਂ ਕਤਾਰਾਂ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਗਲਤੀ ਲੁਭਾਉਣੀ ਰਹਿਣਾ ਬੰਦ ਕਰ ਦੇਵੇਗੀ। ਇੱਕ ਕਤਾਰ ਗਰੁੱਪ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਦੂਜੀ ਦਸਤਖਤ ਯੋਜਨਾਵਾਂ ਅਤੇ ਪਛਾਣਾਂ, ਅਤੇ ਕੋਈ ਵੀ ਦੂਜੇ ਬਾਰੇ ਸਬੂਤ ਨਹੀਂ।
ਹਰ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਉਸਦੇ ਅਸਲ ਮਾਲਕ ਕੋਲ ਰੱਖੋ
ਆਪਣਾ ਪ੍ਰਮਾਣਪੱਤਰ ਪੇਸ਼ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ ਨੂੰ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਚਾਹੀਦੀ ਹੈ। ਲੜੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੇ ਪੀਅਰ ਨੂੰ CA ਪ੍ਰਮਾਣਪੱਤਰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ CA ਦੀ ਦਸਤਖਤ ਕੁੰਜੀ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹਨਾਂ ਤਿੰਨ ਤੱਤਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਹੀ ਉਹ ਕਾਰਨ ਹੈ ਕਿ ਲੋਕ ਪ੍ਰਮਾਣਪੱਤਰ ਨੂੰ ਹੋਰ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਦਿਖਾਉਣ ਲਈ VPN ਜੰਤਰ ਵਿੱਚ CA ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਆਯਾਤ ਕਰਦੇ ਹਨ।
FortiOS ਵਿੱਚ ਭੂਮਿਕਾਵਾਂ ਵੱਖਰੀਆਂ ਹਨ: ਆਪਣੀ ਕੁੰਜੀ ਵਾਲਾ ਸਥਾਨਕ ਪ੍ਰਮਾਣਪੱਤਰ, ਪੀਅਰ ਦੀ ਪਛਾਣ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਦੂਰਸਥ ਪ੍ਰਮਾਣਪੱਤਰ, ਅਤੇ ਉਸ CA ਦੁਆਰਾ ਦਸਤਖਤ ਕੀਤੇ ਪ੍ਰਮਾਣਪੱਤਰਾਂ ਵਿੱਚ ਭਰੋਸਾ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲੀ ਦੂਰਸਥ CA ਐਂਟਰੀ। ਨਿੱਜੀ ਕੁੰਜੀ ਤੋਂ ਬਿਨਾਂ ਦੂਰਸਥ CA ਐਂਟਰੀ ਅਧੂਰੀ ਨਹੀਂ ਹੈ; ਇਹ ਆਪਣੇ ਉਦੇਸ਼ ਲਈ ਸਹੀ ਹੈ।
ਆਯਾਤ ਕੀਤੀਆਂ CA ਦਸਤਖਤ ਕੁੰਜੀਆਂ ਉਸ ਜੰਤਰ ਨੂੰ ਪੜ੍ਹ ਸਕਣ ਵਾਲੇ ਹਰ ਵਿਅਕਤੀ ਦੇ ਅਧਿਕਾਰ ਵਧਾਉਂਦੀਆਂ ਹਨ। ਉਹ ਆਮ ਪੀਅਰ ਪੁਸ਼ਟੀ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਦੀਆਂ, ਕਿਉਂਕਿ ਪੁਸ਼ਟੀ ਲਈ ਜਨਤਕ ਪ੍ਰਮਾਣਪੱਤਰ ਅਤੇ ਭਰੋਸੇ ਦਾ ਫੈਸਲਾ ਚਾਹੀਦਾ ਹੈ, ਨਵੇਂ ਪ੍ਰਮਾਣਪੱਤਰ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ।
CA ਦੀ ਦਸਤਖਤ ਕੁੰਜੀ ਨੂੰ ਜਾਰੀਕਰਤਾ ਦੀ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਰੱਖੋ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਕਿਹੜਾ ਜੰਤਰ ਕਿਹੜੀ ਕੁੰਜੀ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਆਡਿਟ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੌਣ ਕਿਸਦਾ ਰੂਪ ਧਾਰਨ ਕਰ ਸਕਦਾ ਸੀ, ਤਦ ਮਾਲਕਾਂ ਦੀ ਛੋਟੀ ਸਾਰਣੀ ਐਲਗੋਰਿਦਮ ਦੀ ਲੰਮੀ ਸਾਰਣੀ ਨਾਲੋਂ ਵਧੇਰੇ ਕੀਮਤੀ ਹੈ। ਕੋਈ ਵੀ ਉਹ ਕੁੰਜੀ ਆਯਾਤ ਨਹੀਂ ਕਰਦਾ ਜੋ ਉਹ ਜਾਣਦਾ ਹੈ ਕਿ ਸਿਰਫ਼ ਇਨਵੈਂਟਰੀ ਲਈ ਹੈ। ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਪਹਿਲਾਂ ਇਨਵੈਂਟਰੀ ਲਿਖੋ।