Android VpnService ਕੁਝ ਟ੍ਰੈਫਿਕ ਹੀ ਕਿਉਂ ਫੜਦਾ ਹੈ, ਸਭ ਕਿਉਂ ਨਹੀਂ

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

ਰੂਟ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿਹੜੇ ਪੈਕਟ ਆਉਂਦੇ ਹਨ

Builder.addRoute(prefix, prefixLength) VPN ਨੈੱਟਵਰਕ ਦੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਪ੍ਰੀਫਿਕਸ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਸਿਸਟਮ ਉਸ ਨੈੱਟਵਰਕ ਨੂੰ ਘੇਰੇ ਦੀਆਂ ਐਪਾਂ ਲਈ ਡਿਫਾਲਟ ਮੰਨਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਦੀਆਂ ਐਂਟਰੀਆਂ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਦੇ ਡਿਫਾਲਟ ਰੂਟ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਮੇਲ ਖਾਂਦਾ ਪ੍ਰੀਫਿਕਸ ਪ੍ਰਵਾਹ ਮੋੜਨ ਲਈ ਕਾਫੀ ਹੈ। ਇਸ ਲਈ 0.0.0.0/0 ਲਈ ਰੂਟ IPv4 ਪੂਰਾ ਲੈਂਦਾ ਹੈ, ਪ੍ਰਿੰਟਰ, cast ਟਾਰਗਿਟ ਅਤੇ ਰਾਊਟਰ ਦਾ ਐਡਮਿਨ ਪੇਜ ਸਮੇਤ।

ਭੌਤਿਕ ਡਿਫਾਲਟ ਐਂਟਰੀ ਹਟਾਏ ਬਿਨਾਂ ਉਹ ਕਵਰੇਜ ਚਾਹੁੰਦੇ ਕਲਾਇੰਟ ਇਸ ਦੀ ਥਾਂ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਜੋੜੀ ਵਰਤਦੇ ਹਨ। ਦੋ ਵਧੇਰੇ ਖਾਸ ਰੂਟ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਹਰਾਉਂਦੇ ਹਨ, ਇਕੱਠੇ ਉਹ ਪੂਰਾ ਪਤਾ ਖੇਤਰ ਢਕਦੇ ਹਨ, ਅਤੇ ਫੋਨ ਦੀ ਆਪਣੀ ਡਿਫਾਲਟ ਐਂਟਰੀ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਨਾਲ ਬੱਝੇ ਸਾਕਟਾਂ ਲਈ ਟੇਬਲ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।

ਪਤੇ ਅਤੇ DNS ਐਂਟਰੀਆਂ ਉਸੇ ਬਿਲਡਰ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। addAddress ਇੰਟਰਫੇਸ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਲੰਬਾਈ ਨਾਲ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ addDnsServer ਉਹ ਹੱਲ ਕਰਨ ਵਾਲਾ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਘੇਰੇ ਦੀਆਂ ਐਪਾਂ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਪੁੱਛਣਗੀਆਂ। ਦੋਵੇਂ ਪਰਿਵਾਰ ਇੱਕ ਇੰਟਰਫੇਸ ਉੱਤੇ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ IPv6 ਪਤੇ ਦੇ ਕੋਲ ਸਿਰਫ IPv4 ਰੂਟਾਂ ਦਾ ਸਮੂਹ ਐਸੀ ਸੰਰਚਨਾ ਹੈ ਜੋ ਸਹੀ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਲੀਕ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਹ ਪਰਿਵਾਰ ਰੂਟ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਇੰਟਰਫੇਸ ਦਾ ਪਤਾ ਨਹੀਂ, ਤਾਂ ਕਰਨਲ ਕੋਲ ਉਨ੍ਹਾਂ ਪੈਕਟਾਂ ਲਈ ਸਰੋਤ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਉਹ ਡਿਸਕ੍ਰਿਪਟਰ ਉੱਤੇ ਕਦੇ ਨਹੀਂ ਦਿਸਦੇ।

establish() ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ

establish() ParcelFileDescriptor ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜਾਂ null ਜਦੋਂ ਐਪ ਅਧਿਕਾਰਤ ਨਹੀਂ। null ਨੈੱਟਵਰਕ ਗਲਤੀ ਨਹੀਂ ਸਗੋਂ ਸਹਿਮਤੀ ਦੀ ਹਾਲਤ ਹੈ: VpnService.prepare() ਪਹਿਲਾਂ ਹੀ null ਵਾਪਸ ਕਰ ਚੁੱਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਵਰਤੋਂਕਾਰ ਨੇ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਸਿਸਟਮ ਸੰਵਾਦ ਮਨਜ਼ੂਰ ਕੀਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੇਵਾ ਚੱਲਦਿਆਂ ਸਹਿਮਤੀ ਵਾਪਸ ਲਈ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੰਟਰਫੇਸ ਤੁਹਾਡੇ ਪੜ੍ਹਨ ਲੂਪ ਵਿੱਚ ਕਿਸੇ ਕਾਲਬੈਕ ਤੋਂ ਬਿਨਾਂ ਤੁਹਾਡੇ ਪੈਰਾਂ ਹੇਠ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ।

ਤੁਸੀਂ ਹੋਰ ਨਾ ਕਹੋ ਤਾਂ ਡਿਸਕ੍ਰਿਪਟਰ ਬਲਾਕ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਪੜ੍ਹਤ ਥ੍ਰੈਡ ਰੋਕਣ ਦੀ ਥਾਂ ਬਿਨਾਂ ਡੇਟਾ ਤੁਰੰਤ ਵਾਪਸ ਆਉਂਦੀ ਹੈ। ਬਲਾਕਿੰਗ ਸਾਕਟ ਲਈ ਲਿਖਿਆ ਲੂਪ ਇੱਕ ਕੋਰ ਸਾੜਦਾ ਹੈ, ਅਤੇ ਖਾਲੀ ਪੜ੍ਹਤ ਨੂੰ ਘਾਤਕ ਮੰਨਣ ਵਾਲਾ ਲੂਪ ਨਿਸ਼ਕਿਰਿਆ ਸਕਿੰਟ ਵਿੱਚ ਟਨਲ ਪਾੜ ਦਿੰਦਾ ਹੈ। Builder.setBlocking(true) ਉਹ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਕੀਮਤ ਪੜ੍ਹਤ ਦੇ ਅੰਦਰ ਉਡੀਕਦਾ ਥ੍ਰੈਡ ਹੈ।

ਰੂਟ ਅਤੇ ਪਤਾ ਆਰਗਿਊਮੈਂਟ LinkAddress ਮੁੱਲਾਂ ਵਜੋਂ ਜਾਂਚੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ 224.0.0.0/4 ਵਰਗੇ ਮਲਟੀਕਾਸਟ ਟਾਰਗਿਟ ਸਿੱਧੇ ਰੱਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ tun ਇੰਟਰਫੇਸ ਵਿੱਚ ਵੀ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਇਸ ਰਾਹੀਂ ਮਲਟੀਕਾਸਟ ਖੋਜ ਲਈ ਹੋਰ ਇੱਕ ਰੂਟ ਨਹੀਂ ਸਗੋਂ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਲੋੜੀਂਦਾ ਹੈ। ਜਾਂਚਣ ਵਾਲੀ ਸੂਚੀ VpnService.Builder ਹੈ, ਕੋਈ ਕਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋਇਆ ਦਾ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ।

ਐਪ-ਵਾਰ ਘੇਰਾ ਸਮੂਹ ਨੂੰ ਤੰਗ ਕਰਦਾ ਹੈ, ਟਨਲ ਨੂੰ ਨਹੀਂ

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

ਘੇਰਾ ਜੋ ਵੀ ਹੋਵੇ, ਤੁਹਾਡੀ ਐਪ VPN ਸਰਵਰ ਵੱਲ ਜੋ ਸਾਕਟ ਖੋਲ੍ਹਦੀ ਹੈ ਉਹ ਆਪਣੀ ਬਣਾਈ ਟਨਲ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਣਾ ਚਾਹੀਦਾ। VpnService.protect(socket) ਉਸ ਸਾਕਟ ਨੂੰ ਹੇਠਲੇ ਨੈੱਟਵਰਕ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ ਤਾਂ ਜੋ ਉਸ ਦੇ ਪੈਕਟ tun ਡਿਵਾਈਸ ਛੱਡ ਜਾਣ। ਕਾਲ ਛੱਡ ਦਿਓ ਤਾਂ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਉਹ ਇੰਟਰਫੇਸ ਨਿਗਲ ਜਾਂਦਾ ਹੈ ਜਿਸਨੇ ਉਹ ਉਠਾਉਣਾ ਸੀ।

VpnService.setUnderlyingNetworks ਸਿਸਟਮ ਨੂੰ ਦੱਸ ਕੇ ਲੂਪ ਬੰਦ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਟਨਲ ਢੋਂਦਾ ਹੈ। ਉਹ ਮੁੱਲ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ VPN ਹੋਰ ਐਪਾਂ ਨੂੰ ਕਨੈਕਟੀਵਿਟੀ ਕਿਵੇਂ ਦੱਸਦਾ ਹੈ, ਅਤੇ null ਜਾਂ ਪੁਰਾਣਾ ਮੁੱਲ ਫੋਨ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਵੱਲੋਂ ਆਫਲਾਈਨ ਮੰਨੇ ਜਾਂਦੇ ਜੁੜੇ ਟਨਲ ਦਾ ਆਮ ਕਾਰਨ ਹੈ। ਇਸਨੂੰ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਬਦਲਣ ਉੱਤੇ ਅੱਪਡੇਟ ਕਰੋ, ਸਿਰਫ ਸ਼ੁਰੂਆਤ ਵੇਲੇ ਨਹੀਂ।

ਚੈੱਕਸਮ ਅਤੇ MTU: ਜਿੱਥੇ ਸਹੀ ਰੂਟ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ

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

ਦੂਜੀ ਚੈੱਕਸਮ ਦਾ ਘੇਰਾ ਹੈ। ਜਦੋਂ ਐਪ ਆਪ TCP ਜਾਂ UDP ਪੈਕਟ ਬਣਾਉਂਦੀ ਹੈ, ਚੈੱਕਸਮ ਸਰੋਤ ਪਤਾ, ਟਾਰਗਿਟ ਪਤਾ, ਪ੍ਰੋਟੋਕਾਲ ਨੰਬਰ ਅਤੇ ਆਵਾਜਾਈ ਲੰਬਾਈ ਵਾਲਾ ਸਿਊਡੋ-ਹੈਡਰ ਢਕਦਾ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਛੱਡਣ ਨਾਲ ਆ ਕੇ ਸੁੱਟੇ ਜਾਣ ਵਾਲੇ ਪੈਕਟ ਮਿਲਦੇ ਹਨ। ਉਹ ਅਸਫਲਤਾ ਕਦੇ ਨਾ ਆਉਣ ਵਾਲੇ ਜਵਾਬ ਮਗਰੋਂ ਸਮਾਂ-ਸੀਮਾ ਵਾਂਗ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਇਹ ਵੱਧ ਲੋਕਾਂ ਨੂੰ ਰੂਟਾਂ ਵੱਲ ਮੋੜ ਦਿੰਦੀ ਹੈ। setMtu ਇੰਟਰਫੇਸ ਦਾ MTU ਤੈਅ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਪੜ੍ਹਤ ਠੀਕ ਇੱਕ ਪੂਰਾ IP ਪੈਕਟ ਵਾਪਸ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਬਾਈਟ ਪ੍ਰਵਾਹ ਲਈ ਲਿਖਿਆ ਬਫਰ ਪੈਕਟ ਨਹੀਂ ਸਗੋਂ ਤੁਹਾਡੀ ਪਾਰਸਿੰਗ ਟੁਕੜੇ ਕਰੇਗਾ।

ਪਰਤਾਂ ਵੱਖ ਕਰਨ ਵਾਲਾ ਜਾਂਚ ਦੌਰ

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

ਜੇ ਡਿਸਕ੍ਰਿਪਟਰ ਤੱਕ ਕੁਝ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਸ਼ੱਕੀ ਪੜ੍ਹਨ ਵਾਲਾ ਨਹੀਂ ਸਗੋਂ ਰੂਟਾਂ ਦਾ ਸਮੂਹ ਹੈ: ਪ੍ਰੀਫਿਕਸ ਪੱਕੇ ਕਰੋ, ਉਸੇ ਪਰਿਵਾਰ ਵਿੱਚ ਪਤਾ ਹੈ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਐਪ ਤੁਹਾਡੇ ਤੈਅ ਘੇਰੇ ਅੰਦਰ ਹੈ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਪੈਕਟ ਡਿਸਕ੍ਰਿਪਟਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਪਰ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਮੁੜ ਰੂਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ protect() ਅਤੇ ਹੇਠਲੇ ਨੈੱਟਵਰਕ ਦਾ ਮੁੱਲ ਜਾਂਚੋ। ਜੇ ਦੂਰ ਦਾ ਸਿਰਾ ਵਿਗੜੇ ਪੈਕਟ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਚੈੱਕਸਮ ਅਤੇ MTU ਵੇਖਣ ਦੀਆਂ ਥਾਵਾਂ ਹਨ। ਹਰ ਪਰਤ ਉੱਤੇ ਇੱਕ ਜਾਂਚ ਅੱਧਾ ਦਿਨ ਅੰਦਾਜ਼ਾ ਬਚਾਉਂਦੀ ਹੈ।