ਰਨਬੁੱਕ: ਦੋ OpenVPN ਗਾਹਕਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਆਨਬੋਰਡ ਕਰਨਾ

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

ਹਰ ਗਾਹਕ ਲਈ ਪੂਰਾ ਸਰੋਤ ਕਾਰਡ ਨਿਰਧਾਰਤ ਕਰੋ

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

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

ਭਰੋਸਾ ਸਮੱਗਰੀ ਨੂੰ ਹਰ ਗਾਹਕ ਦੇ ਅੰਦਰ ਰੱਖੋ

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

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

ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਾਂਗ ਨੈੱਟਵਰਕ ਵੀ ਵੱਖ ਕਰੋ

ਦੋ ਪੋਰਟਾਂ ਉੱਤੇ ਦੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵੱਖ ਨਾ ਕਰਨ ਤੱਕ ਅਜੇ ਵੀ ਇੱਕ ਹੋਸਟ ਅਤੇ ਇੱਕ ਰਾਊਟਿੰਗ ਟੇਬਲ ਸਾਂਝੇ ਕਰਦੀਆਂ ਹਨ। ਡਿਜ਼ਾਈਨ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਸੁਣ ਰਿਹਾ ਹੈ।

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

ਹਸਤਾਂਤਰਣ ਤੋਂ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ ਦੀ ਸੂਚਨਾ ਪਹੁੰਚਾਓ

ਰੱਦ ਕਰਨ ਦਾ ਡਿਲਿਵਰੀ ਪਾਥ ਨਾ ਹੋਣ ਤੱਕ ਪ੍ਰਮਾਣ ਪੱਤਰ ਤੈਨਾਤੀ ਅਧੂਰੀ ਹੈ। ਆਨਬੋਰਡਿੰਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ CRL ਦੇ ਜਾਰੀ ਕਰਨ ਵਾਲੇ ਅਤੇ ਵੈਧਤਾ ਵਿੰਡੋ ਦੀ ਜਾਂਚ ਕਰੋ।

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

ਫਿਰ ਸਵੀਕ੍ਰਿਤੀ ਜੋੜੀ ਚਲਾਓ: ਮਨਜ਼ੂਰ ਕਲਾਇੰਟ ਆਪਣੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ A ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ B ਦੇ ਲਿਸਨਰ ਦੁਆਰਾ ਰੱਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਸੀਮਾ ਹੈ, ਟੈਸਟ ਵਜੋਂ ਪ੍ਰਗਟ।