Windows ਅਤੇ strongSwan ਸਾਈਫਰ: ਸਹੀ ਪਰਤ ਮਿਲਾਓ

ਦੋਵੇਂ ਸਿਰੇ AES-128 ਕਹਿੰਦੇ ਹਨ ਅਤੇ ਸੁਰੰਗ ਫਿਰ ਵੀ ਬਣਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ। CBC ਅਤੇ GCM ਵੱਖਰੇ ਰੂਪਾਂਤਰ ਹਨ ਜੋ ਸੰਜੋਗ ਨਾਲ ਇੱਕੋ ਕੀ ਲੰਬਾਈ ਸਾਂਝੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਪੇਸ਼ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਦੂਜਾ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ ਨੂੰ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਕਰਦਾ। AES ਸ਼ਬਦ ਇੱਕ ਪਰਿਵਾਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਸਮਝੌਤੇ ਦਾ ਨਹੀਂ।

ਦੂਜਾ ਧੁਰਾ ਵੀ ਹੈ, ਅਤੇ ਉਲਝਾਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਉਹੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਦੋ ਪਰਤਾਂ, ਦੋ ਸੁਤੰਤਰ ਸੂਚੀਆਂ

IKE ਆਪ ਵਾਰਤਾਲਾਪ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਟ੍ਰੈਫਿਕ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। Windows ਪਹਿਲੇ ਨੂੰ ਐਨਕ੍ਰਿਪਸ਼ਨ ਢੰਗ ਅਤੇ ਅਖੰਡਤਾ ਢੰਗ ਵਜੋਂ, ਅਤੇ ਦੂਜੇ ਨੂੰ ਸਾਈਫਰ ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਰੂਪਾਂਤਰ ਸਥਿਰਾਂਕ ਵਜੋਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਖੇਤਰ ਇੱਕ ਦੂਜੇ ਦੇ ਉਪਨਾਮ ਨਹੀਂ ਹਨ, ਅਤੇ ਇੱਕ ਵਿੱਚ ਵੈਧ ਮੁੱਲ ਦੂਜੇ ਵਿੱਚ ਅਰਥਹੀਣ ਜਾਂ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਵੰਡ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਪ੍ਰੋਫਾਈਲ ਪੜ੍ਹਨ ਨਾਲ ਬਹੁਤਾ ਉਲਝਾਅ ਦੂਰ ਹੁੰਦਾ ਹੈ।

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

ਗੇਟਵੇ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸੂਚੀਆਂ ਲਿਖੋ। ਯਾਦ ਤੋਂ ਕੀਤੀ ਤੁਲਨਾ ਉਹ ਢੰਗ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਖੇਤਰ ਦੋ ਵਾਰ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਕਦੇ ਨਹੀਂ। ਪ੍ਰੋਫਾਈਲ ਦੇ ਕੋਲ ਗੇਟਵੇ ਕੰਸੋਲ ਖੁੱਲ੍ਹਾ ਰੱਖੋ।

ਗਲਤੀ ਨੂੰ ਪ੍ਰਸਤਾਵਾਂ ਦੇ ਕੋਲ ਪੜ੍ਹੋ

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

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

CBC ਅਤੇ GCM ਨੂੰ ਵੱਖਰੇ ਬਦਲ ਵਜੋਂ ਰੱਖੋ

ਜਿਸ ਗੇਟਵੇ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੋਈ ਵੀ ਪਰਿਵਾਰ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਉਸਨੂੰ ਇੱਕ ਨਹੀਂ, ਦੋ ਪ੍ਰਸਤਾਵ ਚਾਹੀਦੇ ਹਨ। strongSwan ਵਿੱਚ ਕਾਮਾ ਬਦਲਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਾਈਫਨ ਇੱਕ ਸੈੱਟ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਦੋਵੇਂ ਪਰਿਵਾਰਾਂ ਨੂੰ ਹਾਈਫਨਾਂ ਨਾਲ ਜੋੜਨ ਨਾਲ ਦੋ ਸਵੀਕਾਰਯੋਗ ਪ੍ਰਸਤਾਵਾਂ ਦੀ ਬਜਾਏ ਇੱਕ ਅਸੰਭਵ ਪ੍ਰਸਤਾਵ ਬਣਦਾ ਹੈ।

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

ESP ਪ੍ਰਸਤਾਵ ਮੁੜ-ਨਾਮਿਤ IKE ਪ੍ਰਸਤਾਵ ਨਹੀਂ ਹੈ

ਸਾਈਫਰ ਟੋਕਨ ਦੋਵੇਂ ਸੂਚੀਆਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਲਗਭਗ ਹੋਰ ਕੁਝ ਵੀ ਅੱਗੇ ਨਹੀਂ ਜਾਂਦਾ। ESP ਪ੍ਰਸਤਾਵ ਵਿੱਚ ਕੀ-ਅਦਲਾ-ਬਦਲੀ ਦਾ ਸਿਊਡੋ-ਰੈਂਡਮ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਸਦੀਆਂ ਅਖੰਡਤਾ ਤੇ ਅੱਗੇ-ਗੋਪਨੀਅਤਾ ਦੀਆਂ ਲੋੜਾਂ IKE ਲਾਈਨ ਤੋਂ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ ਦੂਜੇ ਪਾਸੇ ਦੀ Windows ਨੀਤੀ ਵਿਰੁੱਧ ਦਲੀਲ ਨਾਲ ਤੈਅ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਸੂਚੀ ਦਾ ਦੂਜੀ ਵਿੱਚ ਯਾਂਤ੍ਰਿਕ ਅਨੁਵਾਦ ਅਜਿਹਾ ਕੁਝ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਵਾਰਤਾਲਾਪ ਨਹੀਂ ਕਰਦਾ।

ਇੱਕ ਦਿਸ਼ਾ ਚੁਣੋ ਅਤੇ ਉਸੇ ਵਿੱਚ ਰਹੋ। ਜਾਂ ਤਾਂ ਗੇਟਵੇ ਸਿਰਫ਼-GCM ਨੀਤੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਪੂਰੀ ਸੰਗਤ ਨੀਤੀ ਤਾਇਨਾਤ ਕਰਦਾ ਹੈ, ਜਾਂ ਗੇਟਵੇ ਦੋਵੇਂ ਪਰਿਵਾਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਆਪਣਾ ਮੌਜੂਦਾ ਸੈੱਟ ਰੱਖਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਨੀਤੀ ਜਿਸ ਫਾਲਬੈਕ ਦੀ ਮਨਾਹੀ ਕਰਦੀ ਹੈ ਉਸਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਹੱਲ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਇਹ ਗਲਤੀ ਨੂੰ ਕਿੰਨੀ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਹਟਾ ਦੇਵੇ।

ਦੋਵੇਂ ਸੈੱਟ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਫਿਰ ਕੀ ਨਵੀਨੀਕਰਨ

ਚੁਣੇ ਕੀ-ਅਦਲਾ-ਬਦਲੀ ਸੈੱਟ ਅਤੇ ਚੁਣੇ ਟ੍ਰੈਫਿਕ ਸੈੱਟ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੀਆਂ ਸੂਚੀਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ ਅਤੇ ਸੁਤੰਤਰ ਤੌਰ ਉੱਤੇ ਸਫਲ ਹੋ ਸਕਦੇ ਹਨ। ਫਿਰ ਕੀ ਨਵੀਨੀਕਰਨ ਹੋਣ ਦਿਓ ਅਤੇ ਉਸਨੂੰ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਕੰਮ ਕਰਨ ਵਾਲਾ ਪਹਿਲਾ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਕੀ ਨਵੀਨੀਕਰਨ ਅਜਿਹੇ ਪ੍ਰਸਤਾਵ-ਸੈੱਟ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ ਅੰਸ਼ਕ ਤੌਰ ਉੱਤੇ ਸਵੀਕਾਰਯੋਗ ਹੈ।

ਉਹ ਸਬੂਤ ਤਬਦੀਲੀ ਨਾਲ ਰੱਖੋ। ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਟੁੱਟਣਾ ਕਿਸੇ ਦੇ ਟਾਈਮਰ ਜਾਂ ਪਲੇਟਫਾਰਮ ਨੁਕਸ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣਾ ਅਸਫਲ-ਅਦਲਾ-ਬਦਲੀ ਰਿਕਾਰਡ ਮੰਗਦਾ ਹੈ।