Access Server ਤੋਂ Community OpenVPN ਤੱਕ: ਕੀ ਮੁੜ ਬਣਾਉਣਾ ਪਵੇਗਾ
Access Server ਨੀਤੀ ਸੰਭਾਲਦਾ ਹੈ; Community OpenVPN ਤੁਹਾਨੂੰ ਇਹ ਲਿਖਣ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਇੱਕ ਵੀ ਸਰਟੀਫਿਕੇਟ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ, ਰੂਟ ਅਤੇ ਰੱਦ ਕਰਨ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ।
Access Server ਅਤੇ Community OpenVPN ਇੱਕੋ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਲਗਭਗ ਕੁਝ ਵੀ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ। ਹੈਂਡਸ਼ੇਕ, ਸਾਈਫਰ ਗੱਲਬਾਤ ਅਤੇ ਟਨਲ ਦਾ ਡੇਟਾ ਪੱਧਰ ਅਨੁਕੂਲ ਹਨ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਅਕਸਰ ਆਪਣੀ ਪ੍ਰੋਫਾਈਲ ਬਦਲੇ ਬਿਨਾਂ ਦੋਵਾਂ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ: ਇੱਕ ਉਤਪਾਦ ਨੀਤੀ ਲਿਖਣ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਪ੍ਰਬੰਧਨ ਪਰਤ ਲਿਆਉਂਦਾ ਹੈ, ਦੂਜਾ ਤੁਹਾਨੂੰ ਕਨਫਿਗ ਫਾਈਲ ਅਤੇ ਕੁਝ ਹੁੱਕ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋਗੇ।
ਉਹੀ ਫਰਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ ਹੈ। ਪੁਰਾਣੇ ਉਤਪਾਦ ਨੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਜੋ ਵੀ ਫੈਸਲਾ ਕੀਤਾ, ਉਹ ਨਵੀਂ ਤੈਨਾਤੀ ਵਿੱਚ ਕਿਤੇ ਸਪੱਸ਼ਟ ਫੈਸਲਾ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜਿੱਥੇ ਦੋਵੇਂ ਤੈਨਾਤੀਆਂ ਆਪਸ ਵਿੱਚ ਬਦਲਣਯੋਗ ਨਹੀਂ ਰਹਿੰਦੀਆਂ
Access Server ਵਿੱਚ, ਵੈੱਬ ਪ੍ਰਸ਼ਾਸਨ ਇੰਟਰਫੇਸ਼ ਉਪਭੋਗਤਾਵਾਂ, ਸਮੂਹਾਂ, ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਅਨੁਮਤੀਆਂ, ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਅਤੇ ਉਸ ਪ੍ਰੋਫਾਈਲ ਬੰਡਲ ਦਾ ਮਾਲਕ ਹੈ ਜੋ ਕੋਈ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ ਦਾ ਡੈਮਨ ਉਸੇ ਪਰਤ ਦੁਆਰਾ ਕਨਫਿਗਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਚੱਲ ਰਹੀ ਸੇਵਾ ਹੱਥ ਨਾਲ ਘੱਟ ਹੀ ਸੰਪਾਦਿਤ ਕੀਤੀ ਜਾਂਦੀ ਸੰਭਾਲੀ ਸਥਿਤੀ ਦਾ ਨਤੀਜਾ ਹੈ। Community OpenVPN ਵਿੱਚ ਕਨਫਿਗ ਫਾਈਲ ਹੀ ਸਥਿਤੀ ਹੈ: ਇਹ ਸੁਣਨ ਵਾਲੇ, ਸਰਟੀਫਿਕੇਟ ਅਧਿਕਾਰੀ, ਪ੍ਰਮਾਣਿਕਤਾ ਹੁੱਕ ਅਤੇ ਹਰ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਵੱਲੋਂ ਇਸਨੂੰ ਮੁੜ ਨਹੀਂ ਲਿਖਦਾ। ਇਸ ਲਈ ਉਹੀ TLS ਮਸ਼ੀਨ ਦੋ ਬਹੁਤ ਵੱਖਰੇ ਮਾਲਕੀ ਮਾਡਲਾਂ ਹੇਠ ਹੈ।
ਛੋਟਾ ਨਕਸ਼ਾ ਖੱਡ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਅਤੇ ਸਮੂਹ ਸਿਰਫ਼ ਪੁਰਾਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਪ੍ਰੋਫਾਈਲ ਬੰਡਲ ਕਨਫਿਗ ਫਾਈਲ ਅਤੇ ਉਹ ਸਰਟੀਫਿਕੇਟ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਖੁਦ ਵੰਡਦੇ ਹੋ। ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਅਨੁਮਤੀਆਂ client-config-dir ਅੰਦਰ ਨਿਰਦੇਸ਼ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਪ੍ਰਸ਼ਾਸਨ ਇੰਟਰਫੇਸ਼ ਉਹ ਪ੍ਰਕਿਰਿਆ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਅਤੇ ਫਾਈਲਾਂ ਸੰਪਾਦਿਤ ਕਰਨ ਲਈ ਚੁਣਦੇ ਹੋ।
ਸਰਵਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਨਕਸ਼ਾ ਲਿਖੋ। ਹਰ ਕਤਾਰ ਜੋ ਤੁਸੀਂ ਭਰ ਨਹੀਂ ਸਕਦੇ, ਇੱਕ ਸੁਵਿਧਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੁਣ ਗੁਆਉਣ ਵਾਲੇ ਹੋ, ਅਤੇ ਚੁੱਪਚਾਪ ਗੁਆਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੋ ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਪਛਾਣ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲਾਂ ਨਾਲ ਤਬਦੀਲ ਨਹੀਂ ਹੁੰਦੀ
ਪੁਰਾਣੇ ਅਧਿਕਾਰੀ ਦੇ ਸਰਟੀਫਿਕੇਟ ਨਵੀਂ ਸੇਵਾ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਪਾਰਸ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਪਛਾਣ ਹੋ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਉਤਪਾਦ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਅਜਿਹੀ ਖਾਤਾ ਸਥਿਤੀ ਨਾਲ ਜੋੜਿਆ ਸੀ ਜੋ ਨਵੀਂ ਨਹੀਂ ਦੇਖ ਸਕਦੀ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਨਵੀਂ ਤੈਨਾਤੀ ਸਿਰਫ਼ ਸਰਟੀਫਿਕੇਟ ਨਾਲ, PAM ਜਾਂ RADIUS ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਪਲੱਗਇਨ ਨਾਲ, ਜਾਂ ਸੰਜੋਗ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਹਰ ਵਿਕਲਪ ਲੋੜੀਂਦੇ ਗੁਣ ਬਚਾਉਂਦਾ ਹੈ। ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਪਛਾਣ ਤੋਂ ਬਿਨਾਂ ਸਾਂਝਾ ਸਰਟੀਫਿਕੇਟ ਇਸ ਨੂੰ ਰੱਖਣ ਵਾਲਿਆਂ ਸਾਰਿਆਂ ਲਈ ਇੱਕੋ ਪਹਿਚਾਣ ਹੈ। ਰੱਦ ਕਰਨਾ ਵੀ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਦਾ Community OpenVPN ਵਿੱਚ ਅਰਥ crl-verify ਦੁਆਰਾ ਹਵਾਲਾ ਦਿੱਤੀ CRL ਫਾਈਲ ਅਤੇ ਉਸਨੂੰ ਮੁੜ ਬਣਾਉਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।
ਕਟਓਵਰ ਤੋਂ ਪਹਿਲਾਂ ਦਾਖਲੇ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ। ਨਵੇਂ ਸਰਟੀਫਿਕੇਟ, ਪਰਖਿਆ ਹੋਇਆ ਰੱਦ ਕਰਨ ਦਾ ਰਾਹ ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਅਸਮਰੱਥ ਕਰਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਤਰੀਕਾ ਪੂਰਵ ਸ਼ਰਤਾਂ ਹਨ, ਬਾਅਦ ਦਾ ਕੰਮ ਨਹੀਂ। ਜੇ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਪੁਰਾਣੇ ਉਤਪਾਦ ਦੇ ਏਕੀਕਰਨ ਤੋਂ ਆਈ ਸੀ, ਤਾਂ ਬਦਲ ਦਾ ਸਪੱਸ਼ਟ ਨਾਮ ਦਿਓ, ਕਿਉਂਕਿ ਸਥਾਪਿਤ ਨਾ ਕੀਤਾ ਪਲੱਗਇਨ ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ ਵਿੱਚ ਬੰਦ ਹੋ ਕੇ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਰੂਟਿੰਗ ਅਤੇ ਨਾਮ ਹੱਲ ਕਨਫਿਗ ਲਿਖਣ ਵਾਲੇ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ
ਰੂਟ, DNS ਸੈਟਿੰਗਾਂ ਅਤੇ ਪੂਰੇ ਟਨਲ ਦਾ ਵਿਵਹਾਰ ਦੋਵਾਂ ਉਤਪਾਦਾਂ ਵਿੱਚ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ ਹਨ, ਪਰ ਤੁਹਾਡੇ ਲਈ ਉਹਨਾਂ ਦੀ ਗਣਨਾ ਸਿਰਫ਼ ਇੱਕ ਕਰਦਾ ਹੈ। Community OpenVPN ਵਿੱਚ ਤੁਸੀਂ ਖੁਦ push ਨਿਰਦੇਸ਼ ਲਿਖਦੇ ਹੋ, ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ redirect-gateway ਸਰਵਰ ਦਾ ਹੈ ਜਾਂ ਕਲਾਇੰਟ ਦਾ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ ਕਿ ਹੋਸਟ ਉੱਤੇ ਫਾਰਵਰਡਿੰਗ ਅਤੇ NAT ਮੌਜੂਦ ਹਨ। ਮੁਕੰਮਲ ਹੈਂਡਸ਼ੇਕ ਫਾਰਵਰਡਿੰਗ, ਪਤਾ ਅਨੁਵਾਦ ਜਾਂ ਉਹਨਾਂ ਰੂਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮਿਲੇ।
ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਵਿਵਹਾਰ ਲਈ client-config-dir ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਸਰਟੀਫਿਕੇਟ ਦੇ common name ਅਨੁਸਾਰ ਨਾਮਿਤ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਜੋੜੀ ਲਈ ਇਸ ਦੇ ਪਿੱਛੇ ਦੇ ਪ੍ਰੀਫਿਕਸਾਂ ਲਈ iroute ਐਂਟਰੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਨਾਮ ਗਲਤ ਹੋਵੇ ਤਾਂ ਵਿਕਲਪ ਬਿਨਾਂ ਗਲਤੀ ਦੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਗੈਰ-ਉਤਪਾਦਨ ਕਲਾਇੰਟ ਨਾਲ ਉਸਦੇ ਆਪਣੇ ਪਤਾ ਪੂਲ ਵਿੱਚ ਪਰਖੋ, ਫਿਰ ਉਸਨੂੰ ਦਿੱਤਾ ਪਤਾ, ਮਿਲੇ ਰੂਟ ਅਤੇ ਉਹ ਰਿਜ਼ੋਲਵਰ ਸੈਟਿੰਗਾਂ ਪੜ੍ਹੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਹ ਅੰਤ ਹੋਇਆ।
ਕਟਓਵਰ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕ੍ਰਮਬੱਧ ਕਰੋ ਕਿ ਪੁਰਾਣੀ ਸੇਵਾ ਵਾਪਸ ਆ ਸਕੇ
ਨਵਾਂ ਸੁਣਨ ਵਾਲਾ ਕਿਸੇ ਹੋਰ ਪੋਰਟ ਜਾਂ ਪਤੇ ਉੱਤੇ ਚਲਾਓ, ਅਤੇ ਬਦਲ ਸਾਬਤ ਕਰਦਿਆਂ ਪੁਰਾਣੇ ਨੂੰ ਟ੍ਰੈਫਿਕ ਸੇਵਾ ਕਰਨ ਦਿਓ। ਇੱਕ ਸਾਕਟ ਉੱਤੇ ਦੋ ਡੈਮਨ ਵਾਪਸੀ ਯੋਜਨਾ ਨਹੀਂ ਹੈ।
ਇੱਕ ਸਮੇਂ ਇੱਕ ਸਮੂਹ ਭੇਜੋ, ਉਸਦੇ ਸਰਟੀਫਿਕੇਟ, ਪੂਲ ਅਤੇ ਰੂਟਾਂ ਸਮੇਤ, ਅਤੇ ਘਟਨਾ ਦੇ ਦੌਰਾਨ ਲੱਭਣ ਦੀ ਬਜਾਏ ਵਾਪਸੀ ਦੇ ਰਾਹ ਦਾ ਅਭਿਆਸ ਕਰੋ। ਜੋ ਵਾਪਸੀ ਸਿਰਫ਼ ਤਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜੇ ਨਵੀਂ ਸੇਵਾ ਪਹਿਲਾਂ ਰੋਕੀ ਜਾਵੇ, ਉਹ ਵੀ ਵਾਪਸੀ ਹੈ, ਪਰ ਇਸਦੀ ਪਰਖ ਉਦੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਨਹੀਂ ਸੜ ਰਿਹਾ।
ਅੰਤ ਵਿੱਚ, ਉਹ ਸੁਵਿਧਾਵਾਂ ਸੂਚੀਬੱਧ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦਾ ਸਿੱਧਾ ਸਮਾਨ ਨਹੀਂ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਕਿਸਮਤ ਲਿਖਤੀ ਤੌਰ ਤੇ ਤੈਅ ਕਰੋ: ਸਵੈ-ਸੇਵਾ ਪ੍ਰੋਫਾਈਲ ਡਾਊਨਲੋਡ, ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਅਨੁਮਤੀ ਝੰਡੇ, ਪ੍ਰਸ਼ਾਸਨ ਇੰਟਰਫੇਸ਼ ਖੁਦ, ਲਾਈਵ ਕਨੈਕਸ਼ਨ ਰਿਪੋਰਟਿੰਗ। ਉਨ੍ਹਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਮੈਨੁਅਲ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਬਦਲਣਾ ਜਾਇਜ਼ ਜਵਾਬ ਹੈ। ਕਤਾਰ ਖਾਲੀ ਛੱਡਣਾ ਨਹੀਂ।
ਕੰਮ ਉਦੋਂ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਉਪਭੋਗਤਾ ਜਿਸਨੇ ਪੁਰਾਣਾ ਪੋਰਟਲ ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ, ਦਾਖਲਾ ਕਰ ਸਕੇ, ਜੁੜ ਸਕੇ, ਲੋੜੀਂਦੇ ਅੰਦਰੂਨੀ ਪਤੇ ਤੱਕ ਪਹੁੰਚ ਸਕੇ ਅਤੇ ਸਾਫ਼-ਸੁਥਰੇ ਢੰਗ ਨਾਲ ਰੱਦ ਹੋ ਸਕੇ। ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਭ ਤਿਆਰੀ ਹੈ।