.ovpn ਫ਼ਾਈਲ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦੀ

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

ਫ਼ਾਈਲ ਨੂੰ ਆਪਣੇ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸੂਚੀ ਵਜੋਂ ਪੜ੍ਹੋ, ਅਤੇ ਇਸ ਦੀਆਂ ਬਹੁਤੀਆਂ ਲਾਈਨਾਂ ਸਪਸ਼ਟ ਹੋ ਜਾਣਗੀਆਂ।

ਫ਼ਾਈਲ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਸਰਵਰ ਦਾ ਨਹੀਂ

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

ਇਸੇ ਲਈ ਉਹੀ ਫ਼ਾਈਲ ਦੋ ਕਲਾਇੰਟਾਂ ’ਤੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ: ਫ਼ਾਈਲ ਮੰਗਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ।

ਟਰਾਂਸਪੋਰਟ ਲਾਈਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸਰੋਤੇ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਐਂਬੈਡ ਕੀਤੀਆਂ ਕੁੰਜੀਆਂ ਫ਼ਾਈਲ ਸੰਭਾਲਣ ਦਾ ਤਰੀਕਾ ਬਦਲਦੀਆਂ ਹਨ

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

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

ਰੂਟ ਅਤੇ DNS ਸ਼ਾਇਦ ਫ਼ਾਈਲ ਵਿੱਚੋਂ ਹੀ ਨਾ ਆਉਣ

ਰੂਟਿੰਗ ਸਰਵਰ ਧੱਕ ਸਕਦਾ ਹੈ, ਪ੍ਰੋਫ਼ਾਈਲ redirect-gateway ਨਾਲ ਸੈੱਟ ਕਰ ਸਕਦੀ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਡਿਫ਼ਾਲਟ ’ਤੇ ਛੱਡੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਤੁਹਾਡੀ ਡਾਊਨਲੋਡ ਕੀਤੀ ਫ਼ਾਈਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੈਅ ਨਹੀਂ ਕਰਦੀ ਕਿ ਟਨਲ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਟ੍ਰੈਫ਼ਿਕ ਕਿੱਥੇ ਜਾਵੇਗਾ। ਜਦੋਂ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਜਨਤਕ ਸਾਈਟਾਂ ਨਹੀਂ, ਤਦ ਸਪਲਿਟ-ਟਨਲ ਨੀਤੀ ਉਹੀ ਕਰ ਰਹੀ ਹੈ ਜਿਸ ਲਈ ਬਣੀ ਸੀ, ਅਸਫਲ ਨਹੀਂ ਹੋ ਰਹੀ।

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

ਅਸਮਰਥਿਤ ਵਿਕਲਪ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਦਾ ਸਵਾਲ ਹਨ

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

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

ਕਿਸੇ ਵੀ ਬਦਲੀ ਤੋਂ ਬਾਅਦ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪ ਕਿਹੜੀ ਪ੍ਰੋਫ਼ਾਈਲ ਐਂਟਰੀ ਵਰਤ ਰਹੀ ਹੈ, ਕਿਉਂਕਿ ਨਵੀਂ ਫ਼ਾਈਲ ਆਯਾਤ ਕਰਨ ਨਾਲ ਪੁਰਾਣੀ ਹਮੇਸ਼ਾ ਨਹੀਂ ਲਿਖੀ ਜਾਂਦੀ।