NetGuard ਦਾ SOCKS ਮੋਡ TCP ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਨਹੀਂ

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

ਮੂਲ ਪ੍ਰੋਜੈਕਟ ਦਾ FAQ ਇੱਕ-ਸੇਵਾ ਸੀਮਾ ਅਤੇ SOCKS ਵਿਕਲਪ ਦੋਵੇਂ ਦਰਜ ਕਰਦਾ ਹੈ। ਵਿਕਲਪ ਦਾ ਹੋਣਾ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਹਰ ਮਨਜ਼ੂਰ ਪੈਕਟ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਕਵਰੇਜ ਦੇ ਸਵਾਲ ਠੀਕ ਇਸੇ ਖਾਲੀ ਥਾਂ ਤੋਂ ਉਠਦੇ ਹਨ।

ਇੱਕ ਹੀ ਐਪ ਵਿੱਚ ਦੋ ਫਾਰਵਰਡਿੰਗ ਰਾਹ

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

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

UDP ਦਾ ਇਸ਼ਤਿਹਾਰ ਦੇਣਾ ਉਸਨੂੰ ਲਾਗੂ ਕਰਨਾ ਨਹੀਂ

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

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

DNS ਤੀਜਾ ਰਾਹ ਹੈ, ਵੇਰਵਾ ਨਹੀਂ

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

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

ਪ੍ਰੌਕਸੀ ਆਵਾਜਾਈ ਆਪਣੇ ਆਪ ਨਿੱਜੀ ਨਹੀਂ ਹੁੰਦੀ

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

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

ਸਫ਼ਾ ਲੋਡ ਨਾਲ ਨਹੀਂ, ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਕਵਰੇਜ ਦੀ ਆਡਿਟ ਕਰੋ

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

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