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

ਦੋਵੇਂ ਉਮੀਦਵਾਰ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਦੇ ਮਾਲਕ ਹਨ

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

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

QuestionSupported config sourcePost-generation script
Survives a GUI saveYesOnly if the save does not regenerate the file
Survives a package upgradeUsually, when the field is documentedNo guarantee; the wrapper can be replaced
Supportable by the vendorYesNo
Obvious to the next adminYes, it is in the UINo, it lives in a wrapper

ਉਪਕਰਣ ਕੀ ਮੁੜ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ

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

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

ਸਮਰਥਿਤ ਮਾਲਕ ਨੂੰ ਕੀ ਪ੍ਰਗਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਬ੍ਰਾਂਚ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਇੱਕ ਨਹੀਂ, ਤਿੰਨ ਬਿਆਨ ਚਾਹੀਦੇ ਹਨ। ਕਲਾਇੰਟ ਨੂੰ ਰੂਟ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਰਵਰ ਨੂੰ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਬ੍ਰਾਂਚ ਪਾਸੇ ਨੂੰ ਟ੍ਰੈਫਿਕ ਉਸ ਟਨਲ ਪਤੇ ’ਤੇ ਵਾਪਸ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਦਿੱਤਾ ਗਿਆ। OpenVPN ਸ਼ਬਦਾਂ ਵਿੱਚ ਇਸਦਾ ਅਰਥ ਹੈ ਪੁਸ਼ ਕੀਤਾ route, ਕਲਾਇੰਟ ਨਾਲ ਬੱਧਾ ਮਿਲਦਾ iroute, ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਵਾਪਸੀ ਮਾਰਗ।

ਇੱਥੇ ਹੀ ਉਪਕਰਣ UI ਭਰਮਾਉਂਦੇ ਹਨ। “ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਰਵਰ ਦੇ LAN ਤੱਕ ਪਹੁੰਚ ਦਿਓ” ਲੇਬਲ ਵਾਲਾ ਚੈਕਬਾਕਸ ਸਰਵਰ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਵੱਲ ਟ੍ਰੈਫਿਕ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ ਬ੍ਰਾਂਚ ਉਲਟ ਦਿਸ਼ਾ ਹੈ: ਇੱਕ ਕਲਾਇੰਟ ਪਿੱਛੇ ਦਾ ਨੈੱਟਵਰਕ, ਸਰਵਰ ਪਾਸਿਓਂ ਪਹੁੰਚਯੋਗ। ਉਹੀ ਲੇਬਲ ਇਸਦੇ ਲਈ ਸਮਰਥਨ ਨਹੀਂ ਦਰਸਾਉਂਦਾ, ਅਤੇ ਫਾਈਲ ਵਿੱਚ ਵੈਧ ਹਦਾਇਤ ਇਹ ਵਾਅਦਾ ਨਹੀਂ ਕਿ ਪੈਕੇਜ ਇਸਨੂੰ ਸੰਭਾਲੇਗਾ।

ਜਦੋਂ ਕੋਈ ਸਮਰਥਿਤ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੁੰਦਾ

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

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

ਇਰਾਦੇ ਨੂੰ ਆਡਿਟਯੋਗ ਬਣਾਓ

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

ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ ਤਾਂ ਬਣੇ ਨਤੀਜੇ ਦੀ ਉਸ ਰਿਕਾਰਡ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਬਿਨਾਂ ਸਮਝਾਈ ਲਾਈਨ ਬਹਾਲ ਕਰਕੇ ਆਸ ਰੱਖਣ ਦੀ ਥਾਂ।OpenVPN 2.6 ਹਵਾਲਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ UI ਨਾਲ ਬਹਿਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ route ਅਤੇ iroute ਦੇ ਆਪਸੀ ਵਿਵਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਅਗਲੀ ਤਬਦੀਲੀ ਲਈ ਚੈੱਕਲਿਸਟ: ਮਾਲਕ ਦਾ ਨਾਮ ਦਿਓ, ਤਿੰਨ-ਹਿੱਸਿਆਂ ਵਾਲਾ ਸਮਝੌਤਾ ਦੱਸੋ, ਇਰਾਦਾ ਨਿਰਯਾਤ ਕਰੋ, ਅਤੇ ਆਪਣੀ ਸੋਧ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਉਪਕਰਣ ਦੇ ਆਪਣੇ ਜੀਵਨ ਚੱਕਰ ਦੀਆਂ ਘਟਨਾਵਾਂ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਪਰਖੋ।

ਸੰਬੰਧਿਤ ਲੇਖ