OpenVPN tls-ciphersuites ਬਨਾਮ tls-version-min: ਹਰ ਇੱਕ ਕੀ ਲਾਗੂ ਕਰਦਾ ਹੈ

TLS 1.3 ਸੂਟ ਸੂਚੀ ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣ ਨੂੰ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ show-tls ਸਿਰਫ਼ ਸਥਾਨਕ ਸਹਾਇਤਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਨੀਤੀ, ਸੂਟ ਅਤੇ ਤੈਅ ਹੋਏ ਨਤੀਜੇ ਵੱਖਰੇ ਜਾਂਚੋ।

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

ਕੋਈ ਵੀ ਸੂਚੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਬਿਲਡ ਦੀ ਜਾਂਚ ਕਰੋ

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

openvpn --version

OpenSSL ਨਾਲ ਲਿੰਕ ਕੀਤਾ 2.6 ਬਿਲਡ tls-cipher ਅਤੇ tls-ciphersuites ਦੋਵੇਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। mbed TLS ਵਾਲੇ ਬਿਲਡ ਵਿੱਚ TLS 1.3 ਸੂਟ ਚੋਣ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ, ਅਤੇ 2.6 ਮੈਨੂਅਲ tls-ciphersuites ਨੂੰ OpenSSL ਵਿਕਲਪ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਕਿਸੇ ਹੋਰ ਬੈਕਐਂਡ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਵੇ, ਤਾਂ ਉਹੀ ਪ੍ਰੋਫਾਈਲ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਇੱਕ ਵੀ ਲਾਈਨ ਬਦਲੇ ਬਿਨਾਂ ਆਪਣਾ ਵਿਵਹਾਰ ਬਦਲ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਹੁੰਦਿਆਂ openvpn --show-tls ਚਲਾਓ ਅਤੇ ਆਉਟਪੁੱਟ ਸੰਭਾਲੋ। ਇਹੀ ਉਹ ਸੂਚੀ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਤੁਲਨਾ ਕਰੋਗੇ, ਅਤੇ ਕਿਸੇ ਦੇ ਪ੍ਰੋਫਾਈਲ ਸੰਪਾਦਿਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੜਨਾ ਸਸਤਾ ਹੈ।

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

ਸੰਸਕਰਣ ਹੱਦਾਂ ਸਾਈਫਰ ਸੂਚੀਆਂ ਤੋਂ ਵੱਖ ਰੱਖੋ

2.6 ਮੈਨੂਅਲ ਵਿੱਚ ਇਹ ਇੱਕ ਨਹੀਂ, ਤਿੰਨ ਨਿਯੰਤਰਣ ਹਨ:

  • tls-cipher TLS 1.2 ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਲਈ ਸਾਈਫਰ ਨੀਤੀ ਤੈਅ ਕਰਦਾ ਹੈ ਅਤੇ OpenSSL ਦੀ ਸਾਈਫਰ ਸੂਚੀ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ;
  • tls-ciphersuites TLS 1.3 ਸੂਟ ਚੁਣਦਾ ਹੈ;
  • tls-version-min ਅਤੇ tls-version-max ਕਨੈਕਸ਼ਨ ਵੱਲੋਂ ਵਰਤੀਆਂ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹਨ।

ਇਸ ਲਈ ਧਿਆਨ ਨਾਲ ਕੱਟੀ TLS 1.3 ਸੂਟ ਸੂਚੀ ਇਸ ਗੱਲ ਦਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਅਜੇ ਵੀ ਮਨਜ਼ੂਰ ਹੈ। ਜੇ ਲੋੜ «ਸਿਰਫ਼ TLS 1.3» ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਸੰਸਕਰਣ ਦੀ ਹੇਠਲੀ ਹੱਦ ਢੋਂਦੀ ਹੈ, ਅਤੇ ਸੂਟ ਸੂਚੀ ਸਿਰਫ਼ ਉਸ ਹੱਦ ਅੰਦਰ ਚੋਣਾਂ ਘਟਾਉਂਦੀ ਹੈ:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

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

ਡਾਟਾ ਚੈਨਲ ਚੌਥਾ ਨਿਯੰਤਰਣ ਹੈ। data-ciphers ਟਨਲ ਅੰਦਰ ਸਮਮਿਤ ਸਾਈਫਰ ’ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਨਤੀਜਾ ਨਿਯੰਤਰਣ ਚੈਨਲ ਦੇ TLS ਸੰਸਕਰਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਸੈਸ਼ਨ ਸਾਰ ਵਿੱਚ AES-256-GCM ਵੇਖਣਾ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ TLS 1.3 ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।

show-tls ਨੂੰ ਸਥਾਨਕ ਸੂਚੀ ਵਜੋਂ ਪੜ੍ਹੋ

--show-tls ਉਹ ਸੂਟ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸਮਰਥਨ ਉਹ ਕ੍ਰਿਪਟੋ ਲਾਇਬ੍ਰੇਰੀ ਕਰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਇਹ ਬਾਈਨਰੀ ਲਿੰਕ ਹੈ, ਤਰਜੀਹ ਕ੍ਰਮ ਵਿੱਚ। ਇਹ ਗੇਟਵੇ ਤੋਂ ਆਈ ਰਿਪੋਰਟ ਨਹੀਂ ਹੈ। ਮੈਨੂਅਲ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸੂਚੀ ਸਥਾਨਕ ਲਾਇਬ੍ਰੇਰੀ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਭਾਵ OpenSSL 3.x ਵਾਲਾ ਲੈਪਟਾਪ ਅਤੇ ਪੁਰਾਣੇ ਬਿਲਡ ਵਾਲਾ ਰਾਊਟਰ ਇੱਕੋ ਸਰਵਰ ਨਾਲ ਗੱਲ ਕਰਦਿਆਂ ਵੱਖਰੀਆਂ ਸੂਚੀਆਂ ਛਾਪਣਗੇ।

EvidenceWhat it actually describes
--show-tls outputCapabilities of this client build and its library
Profile directivesWhat this attempt is allowed to offer
Session log lineWhat this one negotiation selected

ਮੰਨ ਲਓ ਕਿ ਕਲਾਇੰਟ A, B ਅਤੇ C ਸੂਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸੈਸ਼ਨ B ਚੁਣਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਸਥਾਪਿਤ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਸਰਵਰ A ਜਾਂ C ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਜਾਂ B ਹੀ ਇਸ ਦੀ ਇਕੋ-ਇੱਕ ਮਨਜ਼ੂਰ ਚੋਣ ਹੈ। ਤਿੰਨੇ ਲਾਈਨਾਂ ਵੱਖ ਰੱਖੋ, ਅਤੇ ਉਲਝਾਉਣ ਵਾਲੇ ਬਹੁਤੇ TLS ਵਿਸ਼ੇ ਆਪਣੇ ਆਪ ਹੱਲ ਹੋ ਜਾਣਗੇ।

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

ਗੇਟਵੇ ਨੂੰ ਅਜਿਹੀ ਗੱਲ ਪੁੱਛੋ ਜਿਸ ਦਾ ਉਹ ਜਵਾਬ ਦੇ ਸਕੇ

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

ਜੇ ਤੁਸੀਂ ਇਸ ਦਾ ਪ੍ਰਬੰਧਨ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਆਪਰੇਟਰ ਤੋਂ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਲੋੜਾਂ ਜਾਂ ਸੀਮਿਤ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਮੰਗੋ। ਰੱਦ ਕੀਤਾ ਯਤਨ ਆਪਣੇ ਆਪ ਰੱਦ ਕੀਤਾ ਸੂਟ ਨਹੀਂ ਹੁੰਦਾ: ਸੰਸਕਰਣ ਦੀ ਹੇਠਲੀ ਹੱਦ, remote-cert-tls ਵਰਗੀਆਂ ਸਰਟੀਫਿਕੇਟ ਪਛਾਣ ਜਾਂਚਾਂ, ਜਾਂ tls-auth ਅਤੇ tls-crypt ਵਿਚਕਾਰ ਬੇਮੇਲ ਸੂਟ ਚੋਣ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਖ਼ਤਮ ਕਰ ਸਕਦੇ ਹਨ। ਕਲਾਇੰਟ ਦੀ ਸੂਚੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦੀ ਗਲਤੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ «handshake failed» ਚਾਰ ਵੱਖਰੇ ਕਾਰਨ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸਾਈਫਰ ਬੇਮੇਲ ਹੈ।

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

ਦੋ ਨਤੀਜੇ ਦਰਜ ਕਰੋ ਅਤੇ ਉਹ ਵੱਖ ਰੱਖੋ

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

ਫਿਰ ਉਹ ਦੋ ਲਾਈਨਾਂ ਯਾਦਦਾਸ਼ਤ ਤੋਂ ਨਹੀਂ, ਉਸ ਫਾਈਲ ਤੋਂ ਪੜ੍ਹੋ। ਜੋੜੀ ਹੀ ਸਬੂਤ ਹੈ; ਸਿਰਫ਼ ਸੂਟ ਨਾਂ ਤਰਜੀਹ ਹੈ, ਅਤੇ ਸੰਸਕਰਣ ਹੱਦ ਸਰਵਰ ਕੀ ਰੱਦ ਕਰਦਾ ਹੈ ਬਾਰੇ ਵੱਖਰਾ ਬਿਆਨ ਹੈ।

ਜਾਂਚਾਂ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ। --version ਨਾਲ ਬਿਲਡ ਅਤੇ ਬੈਕਐਂਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ --show-tls ਫੜੋ। ਲੋੜੀਂਦੀ ਸੰਸਕਰਣ ਹੇਠਲੀ ਹੱਦ ਸੂਟ ਸੂਚੀ ਤੋਂ ਵੱਖ ਦੱਸੋ। ਚੱਲ ਰਹੇ ਇੰਸਟੈਂਸ ਦੀ ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਇਸ ਦੇ ਮਾਲਕ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਇੱਕ ਮਨਜ਼ੂਰ ਸੈਸ਼ਨ ਅਤੇ, ਜੇ ਯੋਜਨਾ ਮਨਜ਼ੂਰੀ ਦੇਵੇ, ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਵਾਲਾ ਇੱਕ ਰੱਦ ਕੀਤਾ ਯਤਨ ਦੇਖੋ। ਨਿਯੰਤਰਣ ਚੈਨਲ ਅਤੇ ਡਾਟਾ ਚੈਨਲ ਦੇ ਨਤੀਜੇ ਵੱਖਰੇ ਨਿਰੀਖਣ ਵਜੋਂ ਦਰਜ ਕਰੋ।

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

ਸੰਬੰਧਿਤ ਲੇਖ