FortiGate Azure ਰੀਕੀ: peer SA ਪ੍ਰਸਤਾਵ ਸਥਾਨਕ ਨੀਤੀ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ
ਕੰਮ ਕਰਦੀ IKEv2 ਸੁਰੰਗ ਵੀ ਬਦਲਵੀਂ CHILD SA ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੀ ਹੈ। ਨਵੀਨੀਕਰਨ ਅਸਲ ਵਿੱਚ ਜਿਸ ਪ੍ਰਸਤਾਵ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਉਸ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਪਹਿਲੇ ping ਵੱਲੋਂ ਵਰਤੇ ਪ੍ਰਸਤਾਵ ਦੀ ਨਹੀਂ।
ਸੁਰੰਗ ਉੱਪਰ ਆਈ, ਟ੍ਰੈਫਿਕ ਵਹਿਆ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਲਾਗ ਕਹਿੰਦਾ ਹੈ peer SA proposal not match local policy. ਬਹੁਤੇ ਲੋਕ ਉਸ ਲਾਈਨ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਪੜ੍ਹਦੇ ਹਨ ਕਿ ਦੋਵੇਂ ਸੰਰਚਨਾਵਾਂ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਧਾ। ਆਮ ਤੌਰ ’ਤੇ ਇਸਦਾ ਅਰਥ ਹੋਰ ਸੰਗਰਾ ਹੁੰਦਾ ਹੈ: ਉਹ ਪਹਿਲੀ CHILD SA ਲਈ ਮੇਲ ਖਾਧਾ ਅਤੇ ਪਹਿਲੇ ਨਵੀਨੀਕਰਨ ’ਤੇ ਮੇਲ ਖਾਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਕਿਉਂਕਿ ਪਹਿਲੀ ਸਾਂਝ ਨੂੰ ਕਦੇ ਉਹ ਅਦਲਾ-ਬਦਲੀ ਲੋੜੀਂਦੀ ਨਹੀਂ ਸੀ ਜੋ ਬਾਅਦ ਵਾਲੀਆਂ ਕਰਦੀਆਂ ਹਨ। ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਵੇਖੋ।
ਪਹਿਲੀ CHILD SA ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੀ ਹੈ, ਬਾਅਦ ਵਾਲੀਆਂ ਗੱਲਬਾਤ ਕਰਦੀਆਂ ਹਨ
IKEv2 ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ CHILD SA IKE_AUTH ਦੌਰਾਨ ਬਣਦੀ ਹੈ, ਅਤੇ ਇਸ ਦੀਆਂ ਚਾਬੀਆਂ IKE SA ਦੀ ਚਾਬੀ ਸਮੱਗਰੀ ਤੋਂ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਉਸ ਵਕਤ ਕੋਈ ਵੱਖਰੀ Diffie-Hellman ਅਦਲਾ-ਬਦਲੀ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਜਿਹੜਾ PFS ਸਮੂਹ ਇੱਕ peer ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਹਾਲੇ ਪਰਖਿਆ ਹੀ ਨਹੀਂ ਜਾਂਦਾ। ਸੁਰੰਗ ਤੰਦਰੁਸਤ ਦਿਸਦੀ ਹੈ ਕਿਉਂਕਿ ਜਿਸ ਲੋੜ ’ਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਵੋਗੇ ਉਹ ਕਦੇ ਪਰਖੀ ਨਹੀਂ ਗਈ।
CHILD_SA ਰੀਕੀ ਵੱਖਰਾ ਸੁਨੇਹਾ-ਕ੍ਰਮ ਹੈ। ਜਦੋਂ PFS ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ, peer ਨਵੀਂ ਚਾਬੀ ਅਦਲਾ-ਬਦਲੀ ਕਰਦੇ ਹਨ ਅਤੇ ਦੋਵਾਂ ਧਿਰਾਂ ਵੱਲੋਂ ਸਵੀਕਾਰਯੋਗ ਸਮੂਹ, ਨਾਲ ਹੀ ਨਵੀਂ ਸਾਂਝ ਲਈ ESP ਪ੍ਰਸਤਾਵ ’ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਹੈ। ਉਹੀ ਪਲ ਹੈ ਜਦੋਂ ਅਸੰਗਤੀ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਗਲਤੀ ਮਾਰਗ ਦੀ ਥਾਂ ਪ੍ਰਸਤਾਵ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ।
ਇਸ ਲਈ “ਕੱਲ੍ਹ ਇਹ ਕੰਮ ਕਰਦੀ ਸੀ” ਤੁਹਾਨੂੰ ਪ੍ਰਸਤਾਵ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤੀ ਅਦਲਾ-ਬਦਲੀ ਸਫਲ ਰਹੀ, ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਸੀ।
ਫੇਲ੍ਹ ਹੋਈ ਅਦਲਾ-ਬਦਲੀ ਪੜ੍ਹੋ, ਪਹਿਲਾ ping ਨਹੀਂ
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵਾਂ ਸਿਰਿਆਂ ਤੋਂ ਸਫਲ IKE ਪ੍ਰਮਾਣਿਕਤਾ, ਸ਼ੁਰੂਆਤੀ CHILD SA ਅਤੇ ਫੇਲ੍ਹ ਹੋਇਆ ਬਦਲ ਇਕੱਠਾ ਕਰੋ। ਫਿਰ ਕਾਰਵਾਈ ਨੂੰ ਸਹੀ ਨਾਮ ਦਿਓ: IKE SA ਰੀਕੀ, IKE ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ CHILD SA ਰੀਕੀ ਤਿੰਨ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ, ਅਤੇ “ਪੜਾਅ 2” ਆਮ ਗੱਲਬਾਤ ਵਿੱਚ ਇਹਨਾਂ ਸਭ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।
ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰ ਫੇਲ੍ਹ ਹੋਏ ਕਨੈਕਸ਼ਨ ਲਈ ਤੁਲਨਾ ਕਰੋ, ਸੁਰੰਗ ਲਈ ਆਮ ਤੌਰ ’ਤੇ ਨਹੀਂ।
| ਪਰਤ | ਤੁਲਨਾ ਕਰਨ ਯੋਗ ਮੁੱਲ |
|---|---|
| IKE | ਸੰਸਕਰਣ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਅਖੰਡਤਾ ਜਾਂ PRF ਬੰਦੋਬਸਤ, DH ਸਮੂਹ |
| IPsec / CHILD | ESP ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਅਖੰਡਤਾ, ਲੋੜੀਂਦਾ PFS ਜਾਂ ਚਾਬੀ-ਅਦਲਾ-ਬਦਲੀ ਸਮੂਹ |
| ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ | ਸਥਾਨਕ ਅਤੇ ਦੂਰਲੇ ਚੋਣਕਰਤਾ, ਨਾਲ ਹੀ ਨੀਤੀ-ਅਧਾਰਿਤ ਕੋਈ ਵੀ ਚੋਣਕਰਤਾ ਸੈਟਿੰਗ |
FortiGate ’ਤੇ ਉਸ ਸੁਰੰਗ ਲਈ ਪੜਾਅ-2 ਪ੍ਰਸਤਾਵ, PFS ਸੈਟਿੰਗ ਅਤੇ ਸਵੀਕਾਰ ਕੀਤੇ DH ਸਮੂਹ ਖੋਲ੍ਹੋ। ਪਹਿਲਾਂ ਬਣੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਲੋਡ ਕੀਤੇ ਮੁੱਲ ਪੜ੍ਹੋ। GUI ਸਫ਼ੇ ਦਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਸਬੂਤ ਹੈ, ਕਿਉਂਕਿ ਅੱਪਗ੍ਰੇਡ ਮਗਰੋਂ ਦੋਵੇਂ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਬਦਲਿਆ ਹਿੱਸਾ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਟਿਕਟ ਨਾਲ ਰੱਖੋ।
Azure ਦੀ ਡਿਫਾਲਟ ਨੀਤੀ ਵੀ ਇੱਕ ਨੀਤੀ ਹੈ
ਕਨੈਕਸ਼ਨ ਨਾਲ ਕੋਈ ਕਸਟਮ ਨੀਤੀ ਜੁੜੀ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ Azure ਕੋਈ ਵੀ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ। ਕਨੈਕਸ਼ਨ ਗੇਟਵੇ ਦੇ ਡਿਫਾਲਟ ਪ੍ਰਸਤਾਵ-ਸਮੂਹ ’ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ FortiGate ਵੱਲੋਂ ਦਿੱਤੇ ਜਾਣ ਨਾਲੋਂ ਵਿਸ਼ਾਲ ਜਾਂ ਸੰਗਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਦੋਵੇਂ ਸਮੂਹ IKE ਲਈ ਓਵਰਲੈਪ ਕਰਦੇ ਹਨ ਪਰ PFS ਵਾਲੇ ESP ਲਈ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਇਹੀ ਫੇਲ੍ਹਤਾ ਨਮੂਨਾ ਮਿਲੇਗਾ।
ਇਹ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਦਿੱਖ ਅਸਲ ਵਿੱਚ ਜੁੜੀ ਨੀਤੀ ਦਿਖਾਉਂਦੀ ਹੈ, ਭੇਤ ਖੋਲ੍ਹੇ ਬਿਨਾਂ:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesਆਪਣੇ ਅਸਲ ਸਰੋਤ ਨਾਮ ਵਰਤੋ। ਜਦੋਂ ਸਪੱਸ਼ਟ ਨੀਤੀ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਉਹ ਕਨੈਕਸ਼ਨ ਸਰੋਤ ’ਤੇ ਸੈੱਟ ਕਰੋ। ਇਹ ਪੂਰੇ ਗੇਟਵੇ ਦਾ ਸਵਿੱਚ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਉਸੇ ਗੇਟਵੇ ਦੀਆਂ ਹੋਰ ਸੁਰੰਗਾਂ ’ਤੇ ਚੁੱਪਚਾਪ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ।
ਪੋਰਟਲ ਵਿੱਚ, ਉਸ ਕਨੈਕਸ਼ਨ ਦਾ Configuration ਸਫ਼ਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਕਸਟਮ IPsec/IKE ਨੀਤੀ ਜਾਂਦੀ ਹੈ। Microsoft ਦੀ ਕਸਟਮ-ਨੀਤੀ ਗਾਈਡ ਸਮਰਥਿਤ ਪੈਰਾਮੀਟਰ ਅਤੇ SKU ਲੋੜਾਂ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ। Azure ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਇੱਕ ਪੂਰਨ ਸੰਜੋਗ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ IKE ਖੇਤਰ ਅਤੇ IPsec ਖੇਤਰ ਇਕੱਠੇ ਦੱਸਦੇ ਹੋ, ਇੱਕ-ਇੱਕ ਕਰਕੇ ਨਹੀਂ।
PFS ਇੱਕ ਲੋੜ ਹੈ, ਪਲਟਣ ਵਾਲਾ ਸਵਿੱਚ ਨਹੀਂ
ਜੇ ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਆਧਾਰ-ਰੇਖਾ PFS ਮੰਗਦੀ ਹੈ, ਤਾਂ ਹੱਲ ਉਹ ਸਮੂਹ ਹੈ ਜਿਸ ਨੂੰ ਦੋਵਾਂ ਧਿਰਾਂ ਦੇ ਦੋਵੇਂ peer ਸਵੀਕਾਰ ਕਰਨ, ਜੋ ਮੇਲ ਖਾਂਦੀ ਨੀਤੀ ਰਾਹੀਂ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ। ਗਲਤੀ ਮਿਟਾਉਣ ਲਈ PFS ਬੰਦ ਕਰਨਾ ਉਸ ਸੁਰੱਖਿਆ ਗੁਣ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਅਤੇ ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਅਸੰਗਤੀ ਵਜੋਂ ਮੁੜ ਆਉਂਦਾ ਹੈ।
Azure-ਖਾਸ ਇੱਕ ਜਾਲ: ਜਦੋਂ ਤੁਸੀਂ ESP ਲਈ GCM ਚੁਣਦੇ ਹੋ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਅਖੰਡਤਾ ਦੀਆਂ ਚੋਣਾਂ ਨੂੰ ਉਹੀ GCM ਐਲਗੋਰਿਦਮ ਅਤੇ ਉਹੀ ਚਾਬੀ ਲੰਬਾਈ ਦੱਸਣੀ ਪੈਂਦੀ ਹੈ। GCM ਸਾਈਫਰ ਨੂੰ ਵੱਖਰੇ ਅਖੰਡਤਾ ਐਲਗੋਰਿਦਮ ਨਾਲ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹਾ ਸੰਜੋਗ ਬਣਦਾ ਹੈ ਜਿਸ ਨੂੰ ਸੇਵਾ ਰੱਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਨੀਤੀ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨ ਤੱਕ ਇਹ peer ਅਸੰਗਤੀ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।
ਦੋਵੇਂ ਸਿਰੇ ਸਮਰਥਨ ਕਰਨ ਅਤੇ ਤੁਹਾਡੀ ਲੋੜ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਸੰਜੋਗ ਚੁਣੋ, ਫਿਰ ਉਸ ਨੂੰ ਤਬਦੀਲੀ-ਰਿਕਾਰਡ ਵਿੱਚ ਲਿਖੋ। ਅਗਲਾ ਵਿਅਕਤੀ ਉਸ ਰਿਕਾਰਡ ਨਾਲ ਤੁਲਨਾ ਕਰੇਗਾ, ਕੰਮ ਕਰਦੀ ਸੁਰੰਗ ਦੀ ਯਾਦ ਨਾਲ ਨਹੀਂ। ਇਸ ਵਿੱਚ PFS ਸਮੂਹ ਅਤੇ ESP ਪ੍ਰਸਤਾਵ ਰੱਖੋ, ਸਿਰਫ਼ ਨੀਤੀ ਦਾ ਨਾਮ ਨਹੀਂ। ਜੇ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਪੁੱਛੇ ਕਿ ਆਡਿਟ ਕਿਉਂ ਫੇਲ੍ਹ ਹੋਇਆ ਜਾਂ ਰੀਕੀ ਕਿਉਂ ਹੌਲੀ ਹੈ, ਤਾਂ ਉਹ ਲਾਈਨ ਦੋਵੇਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।
ਫੇਲ੍ਹ ਹੋਈ ਅਦਲਾ-ਬਦਲੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਤਬਦੀਲੀ ਨੂੰ ਬਹਾਲੀ ਮਾਰਗ ਨਾਲ ਤੈਅ ਕਰੋ, ਕਿਉਂਕਿ ਨੀਤੀ ਸੋਧਣ ਨਾਲ ਤੁਸੀਂ ਸੁਧਾਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸੁਰੰਗ ਵਿੱਚ ਰੁਕਾਵਟ ਆ ਸਕਦੀ ਹੈ। ਟ੍ਰੈਫਿਕ ਮੁੜ ਆਉਣ ਮਗਰੋਂ CHILD_SA ਨਵੀਨੀਕਰਨ ਦੀ ਉਡੀਕ ਕਰੋ ਜਾਂ ਉਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵੀਂ ਸਾਂਝ ਲੋੜੀਂਦੇ PFS ਸਮੂਹ ਨਾਲ ਬਣੀ ਹੈ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਉਸ ਰਾਹੀਂ ਜਾਰੀ ਹੈ।
ਦੋ ਗੁੰਮਰਾਹਕੁੰਨ ਸੰਕੇਤਾਂ ਦਾ ਨਾਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। SA ਉਮਰਾਂ ਸਥਾਨਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਇਸ ਲਈ ਅਸਮਾਨ ਮੁੱਲ ਆਮ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣਾ ਸਿਰਫ਼ ਇਹ ਤਬਦੀਲ ਕਰਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਕਦੋਂ ਦਿਸਦੀ ਹੈ। DPD ਪਤਾ ਲਾਉਂਦਾ ਹੈ ਕਿ peer ਜੀਵਿਤ ਹੈ ਜਾਂ ਨਹੀਂ; ਉਸ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਵਧਾਉਣ ਨਾਲ ESP ਜਾਂ PFS ਚੋਣਾਂ ਨਹੀਂ ਮਿਲਦੀਆਂ।
ਤਬਦੀਲੀ ਮਗਰੋਂ ਗੱਲਬਾਤ ਹੋਇਆ ਨਤੀਜਾ ਅਤੇ ਅਗਲੀ ਘਟਨਾ ਦਰਜ ਕਰੋ। ਜੇ ਕਨੈਕਸ਼ਨ ਹੁਣ IKE ਪ੍ਰਮਾਣਿਕਤਾ ਪੂਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੁਣੇ ਸੋਧੀਆਂ IKE ਸੈਟਿੰਗਾਂ ਵੇਖ ਰਹੇ ਹੋ, ਮੂਲ CHILD-ਨਵੀਨੀਕਰਨ ਫੇਲ੍ਹਤਾ ਨਹੀਂ।