0x ਜਾਂ 0s? ipsec.secrets ਵਿੱਚ PSK ਫਾਰਮੈਟ ਨੂੰ ਸਮਝਣਾ

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

ਲੱਛਣ ਸਾਈਫਰ ਵੱਲ ਨਹੀਂ, ਐਨਕੋਡਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

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

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

ਇੱਕ ਰਾਜ਼, ਫਾਈਲ ਇਸਨੂੰ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ

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

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

ਉਸ ਬਲਾਕ ਦੇ ਦੋ ਵੇਰਵੇ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦੇ ਹਨ। ਹੈਕਸਾਡੈਸੀਮਲ ਅੰਕ ਦੋਵੇਂ ਕੇਸ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ 0x6b657931 ਅਤੇ 0x6B657931 ਇੱਕੋ ਮੁੱਲ ਹਨ, ਪਰ ਵਿਸ਼ਮ ਗਿਣਤੀ ਵਿੱਚ ਅੱਖਰ ਰੱਦ ਹੋਣ ਦੀ ਥਾਂ ਚੁੱਪਚਾਪ ਗਲਤ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕਟਾਈ ਤੋਂ ਬਾਅਦ ਦਾ ਹਰ ਬਾਈਟ ਖਿਸਕ ਜਾਂਦਾ ਹੈ। Base64 ਪੈਡਿੰਗ ਮੁੱਲ ਦਾ ਹਿੱਸਾ ਹੈ, ਇਸ ਲਈ ਅੰਤਲੇ = ਚਿੰਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਚਿਪਕਾਈ ਸਤਰ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਥਾਂ ਵੱਖਰੇ ਬਾਈਟ ਵਿੱਚ ਡੀਕੋਡ ਹੁੰਦੀ ਹੈ।

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

Base64 ਪਾਠ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ

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

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

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

ਹਰ ਸਾਥੀ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਬਾਈਟ ਵਰਤਦਾ ਹੈ, ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਗਲਤੀ ਦੀ ਸਤਰ ਤੋਂ ਕਾਰਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਪਹਿਲਾਂ ਡੈਮਨ ਦਾ ਕਨੈਕਸ਼ਨ ਤੇ ਨਜ਼ਰੀਆ ਅਤੇ ਫਿਰ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਪੜ੍ਹੋ। ਸੰਭਾਲੀ ਲੰਬਾਈ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਤੇਜ਼ ਤਰਕਸੰਗਤਤਾ ਜਾਂਚ ਹੈ, ਕਿਉਂਕਿ ਐਨਕੋਡਿਡ ਪਾਠ ਉਸ ਬਾਈਟ ਤੋਂ ਲੰਮਾ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਉਹ ਪ੍ਰਤੀਨਿਧ ਕਰਦਾ ਹੈ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪਛਾਣ ਕਤਾਰ ਮੇਲ ਖਾਦੀ, ਕਿਉਂਕਿ ਗਲਤ ਸਾਥੀ ਹੇਠ ਰੱਖਿਆ ਸਹੀ ਰਾਜ਼ ਗਲਤ ਵਾਂਗ ਹੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਕਤਾਰਾਂ ਦਾ ਕ੍ਰਮ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ: ਪਹਿਲਾ ਮੇਲ ਜਿੱਤਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਪਰ ਵੱਲ ਦੀ ਚੌੜੀ %any ਕਤਾਰ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਸੋਧੀ ਖਾਸ ਕਤਾਰ ਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲ ਦਿੰਦੀ ਹੈ।

ਫਾਈਲ ਸਹੀ ਹੋਣ ਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਥਾਂ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ। ipsec rereadsecrets IKE ਡੈਮਨ ਦੀ ਨਕਲ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ, ਅਤੇ swanctl ਸੈੱਟਅੱਪ ਆਪਣੀ ਕਮਾਂਡ ਰਾਹੀਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਲੋਡ ਕਰਦਾ ਹੈ। ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਹਰ ਸਥਾਪਿਤ ਸੰਬੰਧ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਤੁਲਨਾ ਨਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ।

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

ਨਤੀਜਾ ਲੁਕਾਏ ਬਿਨਾਂ ਫਾਈਲ ਬਦਲੋ

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

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