OpenVPN ਪ੍ਰੋਫਾਈਲ ਦੇ ਸਰਵਰ ਨੂੰ ਆਯਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਵੇਂ ਜਾਂਚੀਏ

ਕੋਈ ਤੁਹਾਨੂੰ ਪ੍ਰੋਫਾਈਲ ਭੇਜਦਾ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਆਯਾਤ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੀਹ ਸਕਿੰਟ ਬਾਅਦ ਕੋਈ ਕਲਾਇੰਟ ਉਸ ਮੰਜ਼ਿਲ ਵੱਲ ਡਾਇਲ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਨਹੀਂ ਜਾਂਚਿਆ। ਪਹਿਲਾਂ ਫਾਈਲ ਨੂੰ ਟੈਕਸਟ ਐਡੀਟਰ ਵਿੱਚ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਮਹੱਤਵਪੂਰਨ ਸਭ ਕੁਝ ਮੁੱਠੀ ਭਰ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: remote, proto, port, ca, cert, tls-crypt ਅਤੇ verify-x509-name। ਬਾਕੀ ਸਭ ਡਿਫਾਲਟ ਹਨ, ਅਤੇ ਹੈਰਾਨੀਆਂ ਡਿਫਾਲਟ ਵਿੱਚ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ।

ਫਾਈਲ ਜੋ ਵੀ ਐਂਡਪੌਇੰਟ ਵਰਤ ਸਕਦੀ ਹੈ, ਸਭ ਦੀ ਸੂਚੀ ਬਣਾਓ

ਐਂਡਪੌਇੰਟਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕਈ ਹੋ ਸਕਦੇ ਹਨ। grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn ਹਰ ਉਮੀਦਵਾਰ ਨੂੰ ਫਾਈਲ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਛਾਪਦਾ ਹੈ, ਇਨਲਾਈਨ <connection> ਬਲਾਕਾਂ ਵਿੱਚ ਨੈਸਟ ਕੀਤੇ ਵੀ ਸ਼ਾਮਲ।

ਜਦੋਂ ਨਿਰਦੇਸ਼ ਪੋਰਟ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਕਲਾਇੰਟ ਸੁਣਨ ਵਾਲੇ ਦੇ ਡਿਫਾਲਟ ਉੱਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇਕੱਲਾ remote vpn.example.com ਪੋਰਟ 1194 ਦਾ ਅਰਥ ਹੈ, ਫਾਈਲ ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਵੀ proto ਆਵੇ। ਕਈ ਸਾਧਾਰਨ remote ਲਾਈਨਾਂ ਬਦਲ ਹਨ: ਕਲਾਇੰਟ ਉਨ੍ਹਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਜਦ ਤੱਕ remote-random ਉਨ੍ਹਾਂ ਨੂੰ ਨਾ ਮਿਲਾਵੇ, ਅਤੇ ਇਹ ਕਦੇ ਚੁੱਪਚਾਪ ਕਿਸੇ ਹੋਰ ਆਪਰੇਟਰ ਦਾ ਹੋਸਟ ਨਹੀਂ ਬਦਲਦਾ। ਅਸੰਬੰਧਿਤ ਡੋਮੇਨਾਂ ਉੱਤੇ ਦੋ remote ਲਾਈਨਾਂ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਰੁਕ ਕੇ ਪੁੱਛਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਮਤਲਬ ਸੀ।

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

ਪਹਿਲਾਂ ਨਾਮ, ਫਿਰ ਪੋਰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

dig +short vpn.example.com ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਨਾਮ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕਿਹੜੇ ਪਤੇ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਹੁ-ਪਤਾ ਜਾਂ ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ ਦਾ ਐਂਡਪੌਇੰਟ ਕਾਨੂੰਨੀ ਤੌਰ ਉੱਤੇ ਕਈ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਨਾਮ ਦਾ ਹੱਲ ਹੋਣਾ ਪੂਰਵ ਸ਼ਰਤ ਹੈ, ਮਾਲਕੀ ਦਾ ਸਬੂਤ ਨਹੀਂ; ਕੋਈ ਵੀ ਨਾਮ ਨੂੰ ਕਿਸੇ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਪਤਾ ਕਈ ਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ।

ਫਿਰ ਜੋ ਪੋਰਟ ਤੁਸੀਂ ਲੱਭਿਆ ਉਸ ਉੱਤੇ ਸੁਣਨ ਵਾਲੇ ਦੀ ਜਾਂਚ ਕਰੋ, ਟਰਾਂਸਪੋਰਟ ਨਾਲ ਮਿਲਾਉਂਦੇ ਹੋਏ। TCP ਉੱਤੇ openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ਸਰਵਰ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੀ ਚੇਨ ਛਾਪਦਾ ਹੈ। UDP ਉੱਤੇ ਤੁਹਾਨੂੰ DTLS ਚਾਹੀਦਾ ਹੈ: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ਡੇਟਾਗ੍ਰਾਮਾਂ ਉੱਤੇ ਉਹੀ ਹੈਂਡਸ਼ੇਕ ਚਲਾਉਂਦਾ ਹੈ। ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕੁਝ ਸੁਣ ਰਿਹਾ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਰੱਖਦਾ ਹੈ, ਜੋ ping ਦਿਖਾਉਂਦਾ ਹੈ ਉਸ ਤੋਂ ਵੱਧ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੀਆਂ ਆਪਣੀਆਂ ਟਰੱਸਟ ਸੈਟਿੰਗਾਂ ਮੰਗਦੀਆਂ ਹਨ ਉਸ ਤੋਂ ਘੱਟ ਹੈ।

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

ਟਰੱਸਟ ਪਿੰਨ ਪਤੇ ਤੋਂ ਵੱਖ ਪੜ੍ਹੋ

ਪਤਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਲਾਇੰਟ ਕਿੱਥੇ ਜਾਵੇਗਾ; ਟਰੱਸਟ ਬਲਾਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਪਹੁੰਚਣ ਉੱਤੇ ਉਹ ਕਿਸ ਉੱਤੇ ਭਰੋਸਾ ਕਰੇਗਾ। verify-x509-name "vpn.example.com" name ਵਿਸ਼ੇ ਦਾ ਆਮ ਨਾਮ ਪਿੰਨ ਕਰਦਾ ਹੈ, ਅਤੇ remote-cert-tls server ਸਰਵਰ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਵਿਸਤ੍ਰਿਤ ਕੁੰਜੀ ਵਰਤੋਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਆਪਰੇਟਰ ਵੱਲੋਂ ਦਿੱਤੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਦੋਵੇਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ca, ਇੱਕ ਇਨਲਾਈਨ <ca> ਬਲਾਕ, ਅਤੇ tls-crypt ਜਾਂ tls-auth ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਲੱਭੋ। tls-auth ਵਰਤਣ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਕਲਾਇੰਟ ਉੱਤੇ key-direction 1 ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰ ਪਾਸਾ ਦਿਸ਼ਾ 0 ਵਰਤਦਾ ਹੈ, ਅਤੇ ਬੇਮੇਲ ਹੈਂਡਸ਼ੇਕ ਨੂੰ TLS ਗਲਤੀ ਨਾਲ ਫੇਲ੍ਹ ਕਰਦਾ ਹੈ ਜੋ ਸਰਟੀਫਿਕੇਟ ਦੀ ਖਰਾਬੀ ਵਾਂਗ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। ਇਨਲਾਈਨ CA ਜੋ ਉਸ ਆਪਰੇਟਰ ਦਾ ਨਹੀਂ ਜਿਸਦਾ ਨਾਮ ਤੁਸੀਂ ਹੁਣੇ ਹੱਲ ਕੀਤਾ, ਦਾ ਮਤਲਬ ਫਾਈਲ ਦੋ ਸਰੋਤਾਂ ਤੋਂ ਜੋੜੀ ਗਈ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਸਥਿਤੀ ਹੈ ਜਿਸਨੂੰ ਸਿੱਧਾ ਨਾਮਨਜ਼ੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

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

ਉਹ ਵਿਕਲਪ ਜਾਂਚੋ ਜੋ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ

OpenVPN 2.6 data-ciphers ਰਾਹੀਂ ਸਾਈਫਰਾਂ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਪੁਰਾਣੀ cipher AES-256-CBC ਲਾਈਨ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਕੰਟਰੋਲ ਚੈਨਲ ਪੂਰਾ ਕਰਕੇ ਫਿਰ ਡੇਟਾ ਉੱਤੇ ਅਟਕ ਸਕਦੀ ਹੈ। ਉਹ ਮੁੱਲ ਪੜ੍ਹਨ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਫਾਈਲ ਤੁਸੀਂ ਜੁੜ ਰਹੇ ਸਰਵਰ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਹੈ ਜਾਂ ਨਹੀਂ; 2.6 ਦਾ ਮੈਨੁਅਲ ਪੰਨਾ ਗੱਲਬਾਤ ਦਾ ਕ੍ਰਮ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜੇ ਆਪਰੇਟਰ ਨੂੰ ਹਵਾਲਾ ਦੇਣਾ ਹੋਵੇ।

ਫਾਈਲਨਾਮ ਤੋਂ ਬਿਨਾਂ auth-user-pass ਦਾ ਮਤਲਬ ਹੈ ਕਲਾਇੰਟ ਪੁੱਛੇਗਾ, ਇਸ ਲਈ ਆਪਣੇ ਆਪ ਨੂੰ ਪੂਰੀ ਦਿਸਣ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਵੀ ਪ੍ਰਮਾਣਪੱਤਰ ਚਾਹੀਦੇ ਹਨ। auth-user-pass credentials.txt ਦਾ ਮਤਲਬ ਹੈ ਇਹ ਉਸ ਫਾਈਲ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ ਜੋ ਸ਼ਾਇਦ ਤੁਹਾਨੂੰ ਭੇਜੀ ਨਹੀਂ ਗਈ। nobind ਅਤੇ resolv-retry infinite ਆਮ ਅਤੇ ਨੁਕਸਾਨ ਰਹਿਤ ਹਨ, ਜਦੋਂ ਕਿ explicit-exit-notify ਸਿਰਫ਼ UDP ਲਈ ਹੈ ਅਤੇ TCP ਉੱਤੇ ਬੇਕਾਰ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਪ੍ਰੋਫਾਈਲ ਕਿੱਥੇ ਜੁੜਦੀ ਹੈ, ਪਰ ਹਰ ਇੱਕ ਬਦਲਦਾ ਹੈ ਕਿ ਇਹ ਜੁੜਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਦੇ ਆਯਾਤ ਸੰਵਾਦ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ।

ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਜੋ ਫੈਸਲਾ ਕੀਤਾ ਉਹ ਦਰਜ ਕਰੋ

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

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

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

ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਆਯਾਤ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ --verb 3 ਨਾਲ ਚਲਾਓ ਅਤੇ ਪਹਿਲੀਆਂ ਦਸ ਲਾਈਨਾਂ ਪੜ੍ਹੋ: ਹੱਲ ਕੀਤਾ remote ਪਤਾ, ਗੱਲਬਾਤ ਕੀਤਾ proto ਅਤੇ TLS ਗਲਤੀ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਉੱਪਰਲੀਆਂ ਕਿਹੜੀ ਜਾਂਚ ਤੁਸੀਂ ਛੱਡੀ।