Android VpnService ਦੀ ਆਗਿਆ-ਸੂਚੀ: ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪੇਜ ਅਜੇ ਵੀ ਕਿਉਂ ਅਟਕਦੇ ਹਨ

ਤੁਹਾਡੀ ਆਗਿਆ-ਸੂਚੀ ਸ਼ਾਇਦ ਠੀਕ ਹੈ। ਪੇਜ DNS ਜਵਾਬ, ਰੂਟ ਸਾਰਣੀ, ਰੈਜ਼ੋਲਵਰ ਸਾਕਟ ਜਾਂ MTU ਕਾਰਨ ਅਟਕਦੇ ਹਨ। ਜਾਂਚ ਦਾ ਕ੍ਰਮ ਇਹ ਹੈ।

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

ਮਿਲਾਉਣ ਵਾਲਾ ਹੀ ਘੱਟ ਹੀ ਦੋਸ਼ੀ ਹੁੰਦਾ ਹੈ

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

ਖਾਲੀ A ਰਿਕਾਰਡ ਆਮ ਗਲਤੀ ਹੈ। ਜ਼ੀਰੋ ਜਵਾਬਾਂ ਨਾਲ NOERROR ਭੇਜਣਾ ਜਾਇਜ਼ ਜਵਾਬ ਵਾਂਗ ਲੱਗਦਾ ਹੈ, ਇਸ ਲਈ stub ਰੈਜ਼ੋਲਵਰ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, AAAA ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਹੋਰ ਰੈਜ਼ੋਲਵਰ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਬਾਅਦ ਹਾਰ ਮੰਨਦਾ ਹੈ। ਪ੍ਰਸ਼ਨ ਭਾਗ ਦੁਹਰਾ ਕੇ ਅਤੇ ਲੈਣ-ਦੇਣ ID ਨਕਲ ਕਰਕੇ ਦਿੱਤਾ ਜਵਾਬ ਕੋਡ 3, ਯਾਨੀ NXDOMAIN, ਗੱਲਬਾਤ ਤੁਰੰਤ ਖਤਮ ਕਰਦਾ ਹੈ। ਹਰ ਉਸ ਨਾਮ ਲਈ ਇਹ ਵਰਤੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੱਦ ਕਰਦੇ ਹੋ।

IPv6 ਵੀ ਡਿਫਾਲਟ ਦੀ ਥਾਂ ਉਹੀ ਫੈਸਲਾ ਹੱਕਦਾਰ ਹੈ। ਜੇ ਤੁਸੀਂ A ਲਈ NXDOMAIN ਜਵਾਬ ਦਿਓ ਅਤੇ AAAA ਲੰਘਣ ਦਿਓ, ਤਾਂ ਕਲਾਇੰਟ IPv6 ਰਾਹੀਂ ਬਲਾਕ ਕੀਤੇ ਨਾਮ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਲਟਰ ਲੀਕ ਹੁੰਦਾ ਹੈ। ਕੁਝ ਲਾਗੂਕਰਨ ਬਲਾਕ ਕੀਤੀਆਂ AAAA ਕਿਊਰੀਆਂ ਨੂੰ loopback ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਕਨੈਕਸ਼ਨ ਬਦਲਵੇਂ ਰਾਹ 'ਤੇ ਜਾਣ ਦੀ ਥਾਂ ਤੁਰੰਤ ਫੇਲ ਹੋਵੇ। ਇੱਕ ਨੀਤੀ ਚੁਣੋ, ਇਸਨੂੰ ਦੋਵਾਂ ਰਿਕਾਰਡ ਕਿਸਮਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਦੋਵੇਂ ਲਾਗ ਕਰੋ।

ਸਭ ਕੁਝ ਫੜਨ ਵਾਲਾ ਰੂਟ ਸਭ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ

ਸਿਰਫ਼ DNS ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਕਦੇ addRoute("0.0.0.0", 0) ਨਹੀਂ ਜੋੜਦਾ, ਇਸ ਲਈ TUN ਇੰਟਰਫੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਕਿਊਰੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਬਾਕੀ ਸਭ ਹੇਠਲੇ ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਇਹੀ ਸੁਰੱਖਿਅਤ ਰੂਪ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕੁਝ ਆਗਿਆ-ਸੂਚੀਆਂ Wi-Fi 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਅਤੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ 'ਤੇ ਫੇਲ ਕਿਉਂ ਹੁੰਦੀਆਂ ਦਿਸਦੀਆਂ ਹਨ।

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

ਰੈਜ਼ੋਲਵਰ ਸਾਕਟ ਨੂੰ ਸੁਰੰਗ ਤੋਂ ਬਾਹਰ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਆਕਾਰ ਅਤੇ ਚੈੱਕਸਮ ਬਿਨਾਂ ਸੁਨੇਹੇ ਫੇਲ ਹੁੰਦੇ ਹਨ

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

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

VpnService ਤੁਹਾਡੇ ਲਈ ਕੀ ਨਹੀਂ ਕਰੇਗਾ

ਇਸ ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਸੀਮਾਵਾਂ ਜਾਣਨਾ ਲਾਹੇਵੰਦ ਹੈ। ਕੋਈ ਆਮ ਐਪ Wi-Fi ਤੋਂ ਬਾਹਰ ਸਿਸਟਮ-ਵਿਆਪੀ ਪ੍ਰੌਕਸੀ ਜਾਂ PAC ਫਾਈਲ ਇੰਸਟਾਲ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਅਤੇ ਉਹ ਹਿੱਸਾ ਬਦਲਿਆ ਨਹੀਂ। ਪ੍ਰਤੀ-ਐਪ ਰਾਹ ਬਦਲਿਆ ਹੈ: API 29 ਤੋਂ ਪਹਿਲਾਂ VpnService.Builder ਪ੍ਰੌਕਸੀ ਬਿਲਕੁਲ ਨਹੀਂ ਲੈ ਜਾ ਸਕਦਾ ਸੀ, ਅਤੇ API 29 ਤੋਂ setHttpProxy(ProxyInfo.buildPacProxy(uri)) ਪਲੇਟਫਾਰਮ ਨੂੰ VPN ਨੈੱਟਵਰਕ ਲਈ ਮੁਲਾਂਕਣ ਵਾਸਤੇ PAC ਸਕ੍ਰਿਪਟ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਪੁਰਾਣੇ API ਨਿਸ਼ਾਨਾ ਬਣਾਓ ਜਾਂ PAC ਮਾਡਲ ਨਿਯਮ ਪ੍ਰਗਟ ਨਾ ਕਰ ਸਕੇ ਤਾਂ ਨਿਯਮ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰੋ। UDP ਵੀ ਮੁਫ਼ਤ ਨਹੀਂ: ਬ੍ਰਾਊਜ਼ਰ SOCKS ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਸਿਰਫ਼ TCP ਭੇਜਦੇ ਹਨ, ਅਤੇ ਬਹੁਤੇ SOCKS5 ਕਲਾਇੰਟ ਕਦੇ UDP ASSOCIATE ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਪ੍ਰੌਕਸੀ-ਆਧਾਰਿਤ ਡਿਜ਼ਾਈਨ TCP ਸਿਹਤਮੰਦ ਦਿਸਦਿਆਂ UDP ਸੁੱਟਦਾ ਜਾਂ ਲੀਕ ਕਰਦਾ ਹੈ।

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

ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ

ਸੂਚੀ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਫੇਲ ਹੋਣ ਵਾਲੇ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਪਿਛਲਾ ਟਿਕੇ ਬਿਨਾਂ ਹਰ ਅਗਲੀ ਜਾਂਚ ਸ਼ੋਰ ਹੈ।

  1. ਲਗਾਏ ਰੂਟ ਸੂਚੀਬੱਧ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਗੈਰ-DNS ਪੈਕਟ TUN ਇੰਟਰਫੇਸ ਵਿੱਚ ਆਉਂਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
  2. ਇੱਕ ਬਲਾਕ ਕੀਤੇ ਅਤੇ ਇੱਕ ਮਨਜ਼ੂਰ ਨਾਮ ਲਈ ਕਿਊਰੀ ਨਾਮ, ਫੈਸਲਾ ਅਤੇ ਜਵਾਬ ਕੋਡ ਲਾਗ ਕਰੋ।
  3. ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੈਜ਼ੋਲਵਰ ਸਾਕਟ ਸੁਰੱਖਿਅਤ ਹੈ ਅਤੇ ਚੁਣਿਆ ਰੈਜ਼ੋਲਵਰ ਸੁਰੰਗ ਦੇ ਅੰਦਰੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
  4. ਇੰਟਰਫੇਸ MTU ਅਤੇ ਹੱਥ ਨਾਲ ਬਣਾਏ ਇੱਕ ਜਵਾਬ ਦਾ ਚੈੱਕਸਮ ਪੁਸ਼ਟੀ ਕਰੋ।
  5. ਉਹੀ ਪੇਜ Wi-Fi ਅਤੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ 'ਤੇ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਕੈਰੀਅਰ ਰੈਜ਼ੋਲਵਰ ਅਤੇ ਰਾਹ MTU ਵੱਖਰੇ ਹਨ।

ਪੰਜੇ ਟਿਕੇ ਅਤੇ ਪੇਜ ਅਜੇ ਵੀ ਅਟਕਿਆ, ਤਾਂ ਅਗਲਾ ਸ਼ੱਕੀ ਫਾਰਵਰਡਰ ਆਪ ਹੈ: ਫੜੀ ਬੇਨਤੀ ਦੀ ਫੜੇ ਜਵਾਬ ਨਾਲ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਗੁੰਮ ਬਾਈਟ ਗਿਣਤੀ ਜਾਂ ਅੱਧ-ਬੰਦ ਸਾਕਟ ਲੱਭੋ। VpnService.Builder ਹਵਾਲਾ ਰੂਟ, DNS ਅਤੇ MTU ਸਮਝੌਤੇ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ protect() builder ਵਿਕਲਪ ਨਹੀਂ ਬਲਕਿ ਵੱਖਰੀ VpnService ਕਾਲ ਹੈ; ਜੁੜਿਆ ਇੰਟਰਫੇਸ ਸਿਰਫ਼ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲਾ ਸਮਝੌਤਾ ਪੂਰਾ ਹੋਇਆ।

ਸੰਬੰਧਿਤ ਲੇਖ