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

ਇੱਥੇ ਟਾਰਗਿਟ Linux ਲਈ OpenVPN 2.6 ਕਮਾਂਡ-ਲਾਈਨ ਕਲਾਇੰਟ ਹੈ, UDP ਉੱਤੇ TUN ਰੂਟ ਕੀਤਾ, ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਨਾਲ।

ਸਿਰਫ਼ ਕਲਾਇੰਟ-ਪਾਸੇ ਦੀਆਂ ਫਾਈਲਾਂ ਇਕੱਠੀਆਂ ਕਰੋ

ਸੁਰੱਖਿਅਤ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੰਮ ਕਰੋ ਅਤੇ ਮਨਜ਼ੂਰ CA ਭਰੋਸਾ ਸਮੱਗਰੀ, ਤੁਹਾਨੂੰ ਜਾਰੀ ਕੀਤਾ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਇਸ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਇਕੱਠੀ ਕਰੋ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਨਾਂ ca.crt, laptop-a.crt ਅਤੇ laptop-a.key ਹਨ। ਫਾਈਲ ਨਾਂ ਸਿਰਫ਼ ਲੇਬਲ ਹਨ; ਉਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਹਰ ਫਾਈਲ ਵਿੱਚ ਕੀ ਹੈ।

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

CA ਦੀ ਪ੍ਰਾਈਵੇਟ ਸਾਈਨਿੰਗ ਕੁੰਜੀ, ਸਰਵਰ ਦੀ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਅਤੇ DH ਪੈਰਾਮੀਟਰ ਇਸ ਪੈਕੇਜ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਜੋੜੋ

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

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

remote ਲਾਈਨ ਨੈੱਟਵਰਕ ਐਂਡਪੌਇੰਟ ਚੁਣਦੀ ਹੈ। remote-cert-tls server ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਹਮਣਾ ਧਿਰ ਸਰਵਰ-ਭੂਮਿਕਾ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰੇ। verify-x509-name ਉਮੀਦ ਕੀਤਾ ਨਾਂ ਪਿੰਨ ਕਰਦਾ ਹੈ, ਇੱਥੇ vpn-gateway ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੇ Common Name ਵਜੋਂ OpenVPN ਦੇ ਡਿਫਾਲਟ ਨਾਂ ਖੇਤਰ ਨਾਲ। ਇਹ ਮੁੱਲ DNS ਹੋਸਟਨਾਂ ਤੋਂ ਨਹੀਂ ਲਿਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਓਪਰੇਟਰ ਵੱਲੋਂ ਦਿੱਤੀ ਪਛਾਣ ਸਕੀਮ ਵਰਤੋ।

ਸਿਰਫ਼ ਇਸ ਲਈ ਉਹ ਜਾਂਚਾਂ ਨਾ ਛੱਡੋ ਕਿ ਕੋਈ ਟੈਸਟ ਐਂਡਪੌਇੰਟ ਵੱਖਰਾ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਂਦਾ ਹੈ।

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

ਕੰਮਕਾਜੀ ਡਾਇਰੈਕਟਰੀ ਸਪੱਸ਼ਟ ਕਰੋ

ਸਾਪੇਖ ਮਾਰਗ ਪ੍ਰਕਿਰਿਆ ਦੀ ਕੰਮਕਾਜੀ ਡਾਇਰੈਕਟਰੀ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, .ovpn ਫਾਈਲ ਦੀ ਥਾਂ ਦੀ ਨਹੀਂ।

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

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

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

ਕੁੰਜੀ ਨੂੰ ਸਿਰਫ਼ ਇੱਛਤ ਵਰਤੋਂਕਾਰ ਜਾਂ ਸੇਵਾ ਪਛਾਣ ਲਈ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ।

ਫਾਈਲ ਨਾਂ ਨਹੀਂ, ਹਸਤਾਂਤਰਣ ਜਾਂਚੋ

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

ਜੇ ਪਾਸਫ੍ਰੇਜ਼ ਪ੍ਰੋਂਪਟ ਦਿਖੇ, ਤਾਂ ਉਹ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਦਾ ਹੈ, VPN ਖਾਤੇ ਦਾ ਨਹੀਂ।

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

ਸੰਬੰਧਿਤ ਲੇਖ