VPN ਚਾਲੂ ਹੋਣ ਵੇਲੇ Android ਫਾਇਰਵਾਲ ਨਿਯਮ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ
ਸਿਰਫ਼ ਇੱਕ VpnService ਸਰਗਰਮ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਫਾਇਰਵਾਲ ਐਪ ਅਤੇ VPN ਐਪ ਇੱਕ ਦੂਜੇ ਤੇ ਨਹੀਂ ਚੜ੍ਹਦੇ। ਇੱਕ ਕੰਮ ਦੀ ਬੇਨਤੀ ਦਾ ਪਿੱਛਾ ਕਰੋ ਅਤੇ ਹਰ ਨਿਯਮ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੋਂ ਉਸ ਦਾ ਟ੍ਰੈਫਿਕ ਸੱਚਮੁੱਚ ਲੰਘਦਾ ਹੈ।
ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵਾਕ ਦੀ ਨੀਤੀ ਹੈ: ਇਹ ਐਪ ਕੰਮ ਦੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ, ਹੋਰ ਕਿਤੇ ਨਹੀਂ। ਅਗਲਾ ਸਵਾਲ ਉਤਪਾਦ ਚੋਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਥਾਂ ਦਾ ਸਵਾਲ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਸੰਭਾਵੀ ਲਾਗੂ ਕਰਨ ਵਾਲਾ ਬਿੰਦੂ ਫੋਨ ਦੇ ਟ੍ਰੈਫਿਕ ਦਾ ਵੱਖਰਾ ਹਿੱਸਾ ਦੇਖਦਾ ਹੈ। ਗੇਟਵੇ ਸਿਰਫ਼ ਉਹ ਦੇਖਦਾ ਹੈ ਜੋ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ। ਫੋਨ ਵਾਲੇ ਪਾਸੇ ਦਾ ਫਿਲਟਰ ਸਿਰਫ਼ ਉਹ ਦੇਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਇੱਕ ਬੇਨਤੀ ਦੋਹਾਂ ਵਿੱਚੋਂ ਲੰਘਾਉਣ ਨਾਲ ਜਵਾਬ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਉਤਪਾਦ ਨਾਲ ਨਹੀਂ, ਵਾਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਕੁਝ ਵੀ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਨੂੰ ਫੈਲਾਓ। ਇਸ ਦਾ ਮਤਲਬ ਪੈਕੇਜ ਅਤੇ ਉਹ ਪ੍ਰੋਫਾਈਲ ਜਿਸ ਵਿੱਚ ਇਹ ਚੱਲਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੰਮ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਦੀ ਐਪ ਨਿੱਜੀ ਪ੍ਰੋਫਾਈਲ ਦੀ ਉਸੇ ਐਪ ਤੋਂ ਵੱਖਰਾ ਵਰਤੋਂਕਾਰ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਮੰਜ਼ਿਲ ਹੈ: ਹੋਸਟ, ਪੋਰਟ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ, ਸੇਵਾ ਦਾ ਨਾਮ ਨਹੀਂ। ਇਸ ਦਾ ਮਤਲਬ ਉਹ DNS ਰਾਹ ਹੈ ਜੋ ਉਸ ਨਾਮ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਕਿ ਸੁਰੰਗ ਨਾ ਹੋਣ ਵੇਲੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਉਦਾਹਰਨ ਦੀ ਨੀਤੀ ਚਾਰ ਲਾਈਨਾਂ ਹੈ: ਕੰਮ ਵਾਲੀ ਐਪ ਕੰਮ ਦੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ; ਹੋਰ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ; ਹੋਰ ਐਪਾਂ ਬਦਲੀਆਂ ਨਹੀਂ ਰਹਿੰਦੀਆਂ; ਸੁਰੰਗ ਨਾ ਹੋਣ ਵੇਲੇ ਕੰਮ ਵਾਲੀ ਐਪ ਸਿੱਧੇ ਰਾਹ ਤੇ ਡਿੱਗਣ ਦੀ ਬਜਾਏ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਹਰ ਲਾਈਨ ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਸਾਰੇ ਇੱਕੋ ਮਾਲਕ ਨਹੀਂ।
ਕਦਮ 1: ਫੋਨ ਖੁਦ ਕੀ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ
ਰੂਟ ਤੋਂ ਬਿਨਾਂ Android ਫਾਇਰਵਾਲ ਇੱਕ VpnService ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ਤੇ ਫੜਦਾ ਹੈ, ਭਾਵੇਂ ਪਿੱਛੇ ਦੂਰ ਦੀ ਸੁਰੰਗ ਨਾ ਹੋਵੇ। Android ਹਰ ਵਰਤੋਂਕਾਰ ਪ੍ਰੋਫਾਈਲ ਲਈ ਇੱਕ ਸਰਗਰਮ VPN ਸੇਵਾ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੂਜੀ ਫਾਇਰਵਾਲ ਐਪ ਪਹਿਲੀ ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਜੁੜਦੀ। ਇਹ ਉਸ ਦੀ ਥਾਂ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਐਪ ਵੱਲੋਂ ਫਿਲਟਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਇੰਟਰਫੇਸ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ VPN ਕਲਾਇੰਟ ਦੇ ਨਾਲ ਫਾਇਰਵਾਲ ਲਗਾਉਣ ਤੇ ਲੋਕਾਂ ਦੀ ਆਸ ਵਾਲਾ ਮੇਲ ਘੱਟ ਹੀ ਮਿਲਦਾ ਹੈ। ਜੇ ਫਾਇਰਵਾਲ ਸ਼ੁਰੂ ਹੋਵੇ ਅਤੇ VPN ਕੱਟ ਜਾਵੇ, ਤਾਂ ਕੁਝ ਵੀ ਨਹੀਂ ਜੁੜਿਆ; ਦੋਵਾਂ ਨੇ ਥਾਂ ਬਦਲ ਲਈ। ਇੰਟਰਫੇਸ ਬਦਲਣਾ ਸਹਿਯੋਗ ਨਹੀਂ ਹੈ, ਅਤੇ ਲੱਛਣ ਉਹ ਸੁਰੰਗ ਹੈ ਜੋ ਦੂਜੀ ਐਪ ਖੁੱਲ੍ਹਣ ਤੇ ਵਾਰ-ਵਾਰ ਡਿੱਗਦੀ ਹੈ।
ਸਮਰਥਿਤ ਬੰਦੋਬਸਤ ਹਨ: ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਚਲਾ ਰਹੇ VPN ਕਲਾਇੰਟ ਵਿੱਚ ਸ਼ਾਮਲ ਫਿਲਟਰਿੰਗ, ਡਿਵਾਈਸ ਨੀਤੀ ਨਿਯੰਤਰਕ ਜਾਂ ਕੰਮ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਪਲੇਟਫਾਰਮ ਨਿਯੰਤਰਣ, ਜਾਂ ਨਿਰਮਾਤਾ ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ਬੱਧ ਢਾਂਚਾ। ਬਾਕੀ ਸਭ ਕੁਝ ਇੱਕ ਪ੍ਰਯੋਗ ਹੈ ਜੋ ਹਰ ਐਪ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚਣਾ ਪੈਂਦਾ ਹੈ।
ਕਦਮ 2: ਗੇਟਵੇ ਕੀ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ
ਦੂਰਲੇ ਸਿਰੇ ਤੇ ਟ੍ਰੈਫਿਕ ਡੀਕ੍ਰਿਪਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਗੇਟਵੇ ਅੱਗੇ ਭੇਜੇ ਜਾਣ ਵਾਲੇ ਪੈਕਟਾਂ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪਤਿਆਂ, ਸੇਵਾਵਾਂ ਜਾਂ ਪ੍ਰਮਾਣਿਤ VPN ਪਛਾਣਾਂ ਤੱਕ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਉੱਥੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਲਈ ਅਸਲ ਲਾਗੂਕਰਨ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚ ਸੀਮਤ ਕਰਨ ਦੀ ਸਹੀ ਥਾਂ ਇਹੀ ਹੈ।
ਜੋ ਇਸ ਨੂੰ ਨਹੀਂ ਮਿਲਦਾ ਉਹ ਹੈ ਹਰ ਆਮ IP ਪੈਕਟ ਨਾਲ ਜੁੜੀ ਫੋਨ ਦੀ ਐਪ ਪਛਾਣ। ਇੱਕ ਸੁਰੰਗ ਪਤਾ ਸਾਂਝਾ ਕਰਨ ਵਾਲੀਆਂ ਕਈ ਐਪਾਂ ਗੇਟਵੇ ਲਈ ਇੱਕ ਵਿਸ਼ਾ ਹਨ, ਜਦ ਤੱਕ ਡਿਜ਼ਾਈਨ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਪਤੇ ਜਾਂ ਵੱਖਰੀਆਂ ਪ੍ਰਮਾਣਿਤ ਪਛਾਣਾਂ ਨਾ ਦੇਵੇ। ਇਸ ਲਈ ਗੇਟਵੇ ਤੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਨਿਯਮ ਫੋਨ ਤੇ ਪ੍ਰਤੀ-ਐਪ ਨਿਯਮ ਨਹੀਂ ਹੈ, ਪ੍ਰਬੰਧਨ ਕੰਸੋਲ ਕੁਝ ਵੀ ਕਹੇ।
ਕਦਮ 3: ਜੋ ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ ਉਸ ਦੀ ਸੂਚੀ ਬਣਾਓ
VPN ਤੋਂ ਬਾਹਰ ਰੱਖੀ ਐਪ ਨੇੜਲੇ ਯੰਤਰ ਨਾਲ ਸੰਪਰਕ ਕਰਦੀ ਹੈ ਤਾਂ ਗੇਟਵੇ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਇਸ ਲਈ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਉਹ ਪੈਕਟ ਰੱਦ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਉਸ ਨੂੰ ਕਦੇ ਮਿਲਦਾ ਹੀ ਨਹੀਂ। ਇਹੀ ਗੱਲ ਰੁਕਾਵਟ ਵੇਲੇ ਅਣਚਾਹੇ ਸਿੱਧੇ ਰਾਹ ਅਤੇ ਸਥਾਨਕ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਤੇ ਆਉਂਦੇ ਸੰਪਰਕ ਲਈ ਵੀ ਲਾਗੂ ਹੈ। ਇਹ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ ਸਥਾਨਕ ਸੀਮਾਵਾਂ ਹਨ।
ਉਲਟਾ ਵੀ ਸੱਚ ਹੈ: ਕਨੈਕਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਸਥਾਨਕ ਨਿਯਮ ਗੇਟਵੇ ਦੇ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ACL ਰਾਹੀਂ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦਾ। ਇੱਕ ਬੇਨਤੀ ਦੋਵੇਂ ਸੀਮਾਵਾਂ ਅਧੀਨ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਪੂਰਾ ਕਰਨ ਨਾਲ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ।
ਕਦਮ 4: ਹਰ ਨਿਯਮ ਨੂੰ ਇੱਕ ਰਾਹ ਦਿਓ
ਕੁਝ ਵੀ ਸੰਰਚਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਸਾਰਣੀ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਖਾਲੀ ਖਾਨੇ ਹੀ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਡਿਜ਼ਾਈਨ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ।
| ਰਾਹ | ਕੌਣ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ | ਅੰਨ੍ਹਾ ਬਿੰਦੂ |
|---|---|---|
| ਕੰਮ ਵਾਲੀ ਐਪ ਤੋਂ ਕੰਮ ਦੀ ਸੇਵਾ ਤੱਕ, ਸੁਰੰਗ ਖੁੱਲ੍ਹੀ | ਪਤੇ ਅਤੇ ਸੇਵਾ ਤੇ ਗੇਟਵੇ ACL, ਨਾਲ ਹੀ ਹੋਰ ਰਾਹਾਂ ਤੇ ਸਥਾਨਕ ਰੋਕ | ਗੇਟਵੇ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਕਿ ਕਿਹੜੀ ਐਪ ਨੇ ਪੈਕਟ ਭੇਜਿਆ |
| ਕੰਮ ਵਾਲੀ ਐਪ ਤੋਂ ਹੋਰ ਮੰਜ਼ਿਲਾਂ ਤੱਕ, ਸੁਰੰਗ ਖੁੱਲ੍ਹੀ | ਐਪ ਨੂੰ ਜਾਣਨ ਵਾਲਾ ਸਥਾਨਕ ਫਿਲਟਰ, ਜਾਂ ਗੇਟਵੇ ਜੇ ਉਹ ਮੰਜ਼ਿਲਾਂ ਉੱਥੇ ਪਤੇਬੱਧ ਹਨ | ਸਥਾਨਕ ਫਿਲਟਰ ਹੀ ਸਰਗਰਮ VpnService ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ |
| ਸੁਰੰਗ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਵਾਲੀ ਐਪ | ਸਥਾਨਕ ਰੱਦ, ਤਾਂ ਜੋ ਐਪ ਸਿੱਧਾ ਰਾਹ ਨਾ ਲੈ ਸਕੇ | ਸੁਰੰਗ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ ਫਿਲਟਰ ਟਿਕਣਾ ਚਾਹੀਦਾ ਹੈ |
| ਨੇੜਲਾ LAN ਯੰਤਰ | ਸਿਰਫ਼ ਸਥਾਨਕ ਨੀਤੀ | ਗੇਟਵੇ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ |
ਜੋ ਰੂਪ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਦੋ ਕੰਮਾਂ ਵਾਲੀਆਂ ਦੋ ਸੀਮਾਵਾਂ ਹਨ। ਐਪ ਨੂੰ ਜਾਣਨ ਵਾਲੀ ਸਥਾਨਕ ਸੀਮਾ ਫੋਨ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ, ਸਿੱਧੇ ਡਿੱਗਣ ਸਮੇਤ, ਅਤੇ ਗੇਟਵੇ ਦੀ ਸੀਮਾ ਦੂਰਲੇ ਸਰੋਤਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ। ਗੇਟਵੇ ਵਾਲਾ ਪਾਸਾ ਕੰਮ ਦੀ ਸੇਵਾ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਹੋਰ ਹਰ ਨਿੱਜੀ ਸਬਨੈੱਟ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ, ਜਦ ਕਿ ਫੋਨ ਵਾਲੇ ਪਾਸੇ ਦੀ ਨੀਤੀ ਉਸ ਸਿੱਧੇ ਰਾਹ ਬਾਰੇ ਖੁਦ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਜੋ ਐਪ ਲੈ ਸਕਦੀ ਸੀ।
ਕਦਮ 5: ਆਵਾਜਾਈ ਨੂੰ ਜੀਵਿਤ ਰੱਖੋ, ਫਿਰ ਜਾਂਚੋ
ਤੁਸੀਂ ਕੋਈ ਵੀ ਸਥਾਨਕ ਨੀਤੀ ਚੁਣੋ, ਉਸ ਨੂੰ ਉਹ ਆਵਾਜਾਈ ਮਨਜ਼ੂਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ VPN ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕਾਇਮ ਰੱਖਦੀ ਹੈ। ਉਸ ਆਵਾਜਾਈ ਨੂੰ ਬਲਾਕ ਕਰਨ ਨਾਲ ਫੋਨ ਸੁਰੰਗ ਅਤੇ ਨੀਤੀ ਦੋਹਾਂ ਤੋਂ ਬਿਨਾਂ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਜੋ ਕੁਝ ਵੀ ਇਕਸਾਰ ਤੌਰ ਤੇ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਨਿਦਾਨ ਕਰਨਾ ਔਖਾ ਹੈ, ਕਿਉਂਕਿ ਐਪ ਕੋਲ ਨੈੱਟਵਰਕ ਹੀ ਨਹੀਂ ਹੁੰਦਾ।
ਫਿਰ ਸਮੁੱਚੀ ਧਾਰਨਾ ਦੀ ਥਾਂ ਮੂਲ ਵਾਕ ਦੀ ਹਰ ਲਾਈਨ ਜਾਂਚੋ: ਕੰਮ ਵਾਲੀ ਐਪ ਕੰਮ ਦੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਉਹੀ ਐਪ ਹੋਰ ਮੰਜ਼ਿਲ ਤੇ ਰੱਦ ਹੁੰਦੀ ਹੈ, ਕੰਮ ਵਾਲੀ ਨਾ ਹੋਣ ਵਾਲੀ ਐਪ ਪਹਿਲਾਂ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਬੰਦ ਹੋਣ ਤੇ ਕੰਮ ਵਾਲੀ ਐਪ ਸਿੱਧੇ ਕਨੈਕਸ਼ਨ ਤੇ ਨਹੀਂ ਡਿੱਗਦੀ। DNS ਰਾਹ ਵੱਖਰੇ ਤੌਰ ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਨਿੱਜੀ DNS ਜਾਂ ਐਨਕ੍ਰਿਪਟਿਡ ਰਿਜ਼ੌਲਵਰ ਸਿਰਫ਼ ਪਤੇ ਜਾਂਚਣ ਵਾਲੇ ਫਿਲਟਰ ਨੂੰ ਟਪਾ ਸਕਦਾ ਹੈ।
ਜੇ ਇਹਨਾਂ ਕਦਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਫੋਨ ਤੇ ਪੂਰਾ ਨਾ ਹੋ ਸਕੇ, ਤਾਂ ਲੋੜ ਢਾਂਚੇ ਦਾ ਸਵਾਲ ਹੈ, ਫਾਇਰਵਾਲ ਦੀ ਸੈਟਿੰਗ ਨਹੀਂ। ਨੀਤੀ ਨੂੰ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਾਲੇ ਯੰਤਰ ਅਤੇ ਗੇਟਵੇ ਵਿਚਕਾਰ ਵੰਡਣਾ ਆਮ ਤੌਰ ਤੇ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹੈ, ਅਤੇ Android VPN ਕਨੈਕਟੀਵਿਟੀ ਦਸਤਾਵੇਜ਼ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ ਕਿ ਪਲੇਟਫਾਰਮ ਇੱਕ ਸੇਵਾ ਨੂੰ ਕੀ ਮਨਜ਼ੂਰ ਕਰੇਗਾ ਅਤੇ ਕੀ ਨਹੀਂ।