OpenVPN ਵਿੱਚ RADIUS ਜੋੜਨਾ: ਪਲੱਗਇਨ ਜਾਂ ਸਕ੍ਰਿਪਟ ਹੁੱਕ?

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

ਮਿੱਥ: ਪਲੱਗਇਨ ਹੀ ਸਮਰਥਿਤ ਰਾਹ ਹੈ

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

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

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

ਪਲੱਗਇਨ ਨੇ ਕੀ ਬੰਨ੍ਹਿਆ ਸੀ

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

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

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

ਸਕ੍ਰਿਪਟ ਹੁੱਕ ਅਸਲ ਵਿੱਚ ਕਿਸ ਉੱਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ

ਹੁੱਕ auth-user-pass-verify ਅਤੇ ਡਿਲੀਵਰੀ ਮਕੈਨਿਜ਼ਮ ਨਾਲ ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ: ਵਾਤਾਵਰਣ ਚਰ ਜਾਂ ਅਸਥਾਈ ਫਾਈਲ। ਵਾਤਾਵਰਣ ਰੂਪ ਵਿੱਚ OpenVPN ਨੂੰ script-security 3 ਚਾਹੀਦਾ ਹੈ, ਉਹ ਦਸਤਾਵੇਜ਼ੀ ਪੱਧਰ ਜੋ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਪਾਸਵਰਡ ਖੋਲ੍ਹਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਉਹ ਪੱਧਰ ਡਿਫਾਲਟ ਦੀ ਜਾਣ-ਬੁੱਝ ਕੇ ਕਮਜ਼ੋਰੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਕਾਰਨ ਨਾਲ ਜੁੜੀ ਆਗਿਆ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

ਐਗਜ਼ਿਟ ਕੋਡ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਖੁੱਲ੍ਹੇ ਰੂਪ ਵਿੱਚ ਅਸਫਲ ਹੋਵੋਗੇ ਜਾਂ ਨਹੀਂ

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

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

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

ਸਰਟੀਫਿਕੇਟ ਜਾਣ ਉੱਤੇ ਤੁਸੀਂ ਕੀ ਛੱਡਦੇ ਹੋ

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

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