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

ਦੋ ਮਸ਼ੀਨਾਂ, ਪਹਿਲਾਂ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਦੋ ਸਵਾਲ

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

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

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

ਸਰਵਰ ਪਾਸੇ ਦਾ ਵਿਕਲਪ: ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਇੱਕ ਘਟਨਾ

client-connect ਸਕ੍ਰਿਪਟ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਦੇ ਜੁੜਨ ’ਤੇ ਸਰਵਰ ਦੀ ਪ੍ਰੋਸੈਸ ਸੰਦਰਭ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਅਤੇ common name ਤੇ ਨਿਰਧਾਰਿਤ ਪਤਾ ਵਰਗੇ ਦਸਤਾਵੇਜ਼ੀ ਕਨੈਕਸ਼ਨ ਵੇਰਵੇ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। ਹਰ ਕਲਾਇੰਟ ਲਈ ਕਾਨਫਿਗਰੇਸ਼ਨ ਟੁਕੜਾ ਲਿਖਣ, ਨੀਤੀ ਫੈਸਲਾ ਲਾਗੂ ਕਰਨ ਜਾਂ ਸਰਵਰ ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਸਥਿਤੀ ਦਰਜ ਕਰਨ ਲਈ ਇਹ ਸਹੀ ਥਾਂ ਹੈ।

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

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

ਕਲਾਇੰਟ ਪਾਸੇ ਦਾ ਵਿਕਲਪ: ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਚੱਲਣ ਵਾਲਾ ਕੰਮ

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

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

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

ਚੱਲਣਯੋਗ ਕੋਡ push ਕਰਨਾ ਵਿਕਲਪਾਂ ਵਿੱਚ ਕਿਉਂ ਨਹੀਂ

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

ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣਾ ਸਮਰੱਥ ਕਰਨ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ। ਤੁਹਾਡੀ script-security ਸੈਟਿੰਗ ਤੁਹਾਡੇ ਚੁਣੇ ਸਥਾਨਕ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀ ਹੈ; ਇਹ ਸਰਵਰ ਨੂੰ ਨਵੇਂ ਦੇਣ ਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦੀ।

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

ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਹੁੱਕ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

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

ਜੋ ਖਾਤਾ ਸੱਚਮੁੱਚ ਇਸ ਨੂੰ ਚਲਾਏਗਾ ਉਸ ਅਧੀਨ, ਉਸੇ ਪਲ ਜਾਂਚੋ ਜਦੋਂ ਇਹ ਸੱਚਮੁੱਚ ਚੱਲੇਗਾ। openvpn(8) ਮੈਨੁਅਲ ਦੋਵੇਂ ਹੁੱਕ ਪਰਿਵਾਰਾਂ ਅਤੇ push ਸੀਮਾਵਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ; ਤੁਸੀਂ ਜਿਸ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਤੈਨਾਤ ਕਰ ਰਹੇ ਹੋ ਉਹ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਨੂੰ ਬਿਲਕੁਲ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੰਟਰਐਕਟਿਵ ਪ੍ਰਬੰਧਕ ਟਰਮੀਨਲ ਵਿੱਚ ਸਫਲ ਹੋਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਇੱਕ ਧਾਰਨਾ ਹੈ, ਪੜਤਾਲ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ