OpenVPN ਪਹਿਲੀ ਲਾਈਨ ਨੂੰ ਰੱਦ ਕਰ ਰਿਹਾ ਹੈ? ਫਾਈਲ ਸ਼ਾਇਦ UTF-16 ਹੈ

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

ਮਿੱਥ: ਐਡੀਟਰ ਤੁਹਾਨੂੰ ਫਾਈਲ ਦਿਖਾਉਂਦਾ ਹੈ

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

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

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

ਪਹਿਲੇ ਬਾਈਟ ਅਸਲ ਵਿੱਚ ਕੀ ਕਹਿੰਦੇ ਹਨ

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

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

ਤੁਸੀਂ ਜਿਸ ਪੈਟਰਨ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹੋ ਉਹ ਸ਼ੁਰੂਆਤੀ ਬਾਈਟਾਂ ਦੀ ਜੋੜੀ ਹੈ ਜਿਸ ਤੋਂ ਬਾਅਦ ਅਜਿਹਾ ਪਾਠ ਆਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰ ਦੂਜਾ ਬਾਈਟ ਜ਼ੀਰੋ ਹੈ। FF FE UTF-16 ਲਿਟਲ-ਐਂਡੀਅਨ ਦਰਸਾਉਂਦਾ ਹੈ, FE FF ਬਿਗ-ਐਂਡੀਅਨ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ EF BB BF ਬਾਈਟ ਕ੍ਰਮ ਚਿੰਨ੍ਹ ਵਾਲੀ UTF-8 ਦਰਸਾਉਂਦਾ ਹੈ। ਬਿਨਾਂ ਚਿੰਨ੍ਹ ਵਾਲੀ ਆਮ UTF-8 ਫਾਈਲ ਸਿੱਧੀ ਪਹਿਲੇ ਅੱਖਰ ਦੇ ਬਾਈਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।

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

ਇੱਥੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੂਖਮਤਾ ਹੈ: OpenVPN ਦਾ ਕਨਫਿਗਰੇਸ਼ਨ ਪਾਠਕ ਫਾਈਲ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ UTF-8 ਬਾਈਟ ਕ੍ਰਮ ਚਿੰਨ੍ਹ ਨੂੰ ਸੱਚਮੁੱਚ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ 2.6 ਕਨਫਿਗਰੇਸ਼ਨ ਰੀਡਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਸਹਿਣਸ਼ੀਲਤਾ ਠੀਕ ਉਸੇ ਚਿੰਨ੍ਹ ਲਈ ਹੈ, ਅਤੇ ਜਿਹਨਾਂ ਦੇ ਅੱਖਰ ਜ਼ੀਰੋ ਨਾਲ ਭਰੇ ਹੋਏ ਹਨ ਅਜਿਹੀ UTF-16 ਫਾਈਲ ਲਈ ਇਹ ਕੁਝ ਨਹੀਂ ਕਰਦੀ। ਦੋਵੇਂ ਚਿੰਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਸਮੱਸਿਆ ਮੰਨਣਾ ਮਿੱਥ ਦਾ ਦੂਜਾ ਅੱਧ ਹੈ।

ਸੁਧਾਰੀ ਐਨਕੋਡਿੰਗ ਕੀ ਸੁਧਾਰਦੀ ਨਹੀਂ

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

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

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

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

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

ਸੁਧਾਰੀ ਐਨਕੋਡਿੰਗ ਕੀ ਨਹੀਂ ਸੁਧਾਰਦੀ

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

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

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