ਹੌਟਸਪੌਟ ਕਲਾਇੰਟਾਂ ਲਈ ਸਪਲਿਟ ਟਨਲਿੰਗ ਪ੍ਰਤੀ-ਐਪ ਬਾਹਰ ਕੱਢਣਾ ਨਹੀਂ ਹੈ
ਕਿਸੇ ਐਪ ਨੂੰ VPN ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਸਿਰਫ਼ ਫ਼ੋਨ ਬਦਲਦਾ ਹੈ। ਟੈਥਰ ਕੀਤੇ ਲੈਪਟਾਪ ਨੂੰ ਆਪਣਾ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਸਰੋਤ, ਮੰਜ਼ਿਲ ਅਤੇ NAT ’ਤੇ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕੋ ਜਿਹੀਆਂ ਸੁਣਾਈ ਦੇਣ ਵਾਲੀਆਂ ਦੋ ਲੋੜਾਂ ਇੱਕੋ ਨਹੀਂ ਹਨ: «ਇਸ ਐਪ ਨੂੰ VPN ਤੋਂ ਬਾਹਰ ਰੱਖੋ» ਅਤੇ «ਇਸ ਇੱਕ ਮੰਜ਼ਿਲ ਨੂੰ ਮੇਰੇ ਹੌਟਸਪੌਟ ਵਾਲੇ ਲੈਪਟਾਪ ਲਈ VPN ਤੋਂ ਬਾਹਰ ਭੇਜੋ»। ਪਹਿਲੀ ਬਦਲਦੀ ਹੈ ਕਿ ਫ਼ੋਨ ’ਤੇ ਸਾਕਟ ਨੈੱਟਵਰਕ ਕਿਵੇਂ ਚੁਣਦਾ ਹੈ। ਦੂਜੀ ਨੇ ਉਸ ਪੈਕਟ ਲਈ ਫਾਰਵਰਡਿੰਗ ਫ਼ੈਸਲਾ ਬਦਲਣਾ ਹੁੰਦਾ ਹੈ ਜੋ ਫ਼ੋਨ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਤੋਂ ਆਇਆ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਰਲਾਉਣਾ ਹੀ ਉਹ ਕਾਰਨ ਹੈ ਜਿਸ ਕਰਕੇ ਹੌਟਸਪੌਟ ਕਲਾਇੰਟ ਕੋਲ ਐਸਾ ਅਪਵਾਦ ਰਹਿ ਜਾਂਦਾ ਹੈ ਜੋ ਹਮੇਸ਼ਾ ਸਿਰਫ਼ ਫ਼ੋਨ ਦੇ ਆਪਣੇ ਬ੍ਰਾਊਜ਼ਰ ’ਤੇ ਹੀ ਲਾਗੂ ਹੁੰਦਾ ਸੀ।
ਦੋ ਸਵਾਲਾਂ ਦੇ ਮਾਲਕ ਦੋ ਵੱਖਰੇ ਉਪਪ੍ਰਣਾਲੀਆਂ ਹਨ
Android ਐਪ ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਟੈਥਰਿੰਗ ਨੂੰ ਵੱਖਰਾ ਰੱਖਦਾ ਹੈ। ਐਪਾਂ ਦੇ ਸਾਕਟ ਨੂੰ ਕਨੈਕਟੀਵਿਟੀ ਸਟੈਕ ਨੈੱਟਵਰਕ ਨਾਲ ਨਿਯੁਕਤ ਕਰਦਾ ਹੈ, ਅਤੇ VPN ਐਪ ਫ਼ੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਉਸ ਦੇ ਆਪਣੇ ਕਿਹੜੇ ਸਾਕਟ ਟਨਲ ਵਿੱਚ ਜਾਣਗੇ। ਟੈਥਰ ਕੀਤੇ ਕਲਾਇੰਟ ਤੋਂ ਫਾਰਵਰਡ ਕੀਤੇ ਪੈਕਟ ਟੈਥਰਿੰਗ ਉਪਪ੍ਰਣਾਲੀ ਸੰਭਾਲਦੀ ਹੈ, ਜੋ netd ਤੋਂ ਰਸਤੇ, ਨੀਤੀ ਨਿਯਮ ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਅਨੁਵਾਦ ਮੰਗਦੀ ਹੈ।
ਪ੍ਰਤੀ-ਐਪ ਬਾਹਰ ਕੱਢਣ ਦਾ ਮੁਲਾਂਕਣ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਐਪ ਸਾਕਟ ਖੋਲ੍ਹਦੀ ਹੈ। ਫਾਰਵਰਡ ਕੀਤਾ ਪੈਕਟ ਉਸ ਜਾਂਚ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਕਿਉਂਕਿ ਇਹ ਇਸ ਡਿਵਾਈਸ ਦੇ ਐਪ ਸਾਕਟ ਤੋਂ ਪੈਦਾ ਨਹੀਂ ਹੋਇਆ। ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਇੱਕ ਦੂਜੇ ਦੀ ਥਾਂ ਨਾ ਲੈ ਸਕਣ ਦਾ ਪੂਰਾ ਕਾਰਨ ਇਹੀ ਹੈ, ਅਤੇ ਇਹ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਵੀ ਬੱਗ ਨਹੀਂ ਹੈ।
ਪ੍ਰਤੀ-ਐਪ ਬਾਹਰ ਕੱਢਣਾ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ
VpnService ਦਾ ਬਿਲਡਰ addDisallowedApplication ਨਾਲ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰਹਿਣ ਵਾਲੇ ਪੈਕੇਜਾਂ ਦੇ ਨਾਮ ਦੇ ਸਕਦਾ ਹੈ, ਜਾਂ addAllowedApplication ਨਾਲ ਅੰਦਰ ਮਨਜ਼ੂਰ ਇਕੱਲੇ ਪੈਕੇਜਾਂ ਦੇ ਨਾਮ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਐਪਾਂ ਫਿਰ ਅਧੀਨ ਨੈੱਟਵਰਕ ’ਤੇ ਸਾਕਟ ਖੋਲ੍ਹਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ VPN ਬਾਕੀ ਸਭ ਲਈ ਡਿਫ਼ਾਲਟ ਰਸਤੇ ਦਾ ਮਾਲਕ ਰਹਿੰਦਾ ਹੈ।
ਘੇਰਾ ਸਹੀ ਹੈ: ਪੈਕੇਜ ਦੇ ਆਪਣੇ ਸਾਕਟ, ਇਸ ਡਿਵਾਈਸ ’ਤੇ, ਜਿੰਨਾ ਚਿਰ ਟਨਲ ਚਾਲੂ ਹੈ। ਇਹ ਫਾਰਵਰਡ ਕੀਤੇ ਟਰੈਫ਼ਿਕ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਦੂਜੇ ਡਿਵਾਈਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ, ਅਤੇ ਸਿਸਟਮ ਵੱਲੋਂ ਟੈਥਰਿੰਗ ਵੱਲੋਂ ਭੇਜੇ ਪੈਕਟਾਂ ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ।
ਇਹ ਮੰਜ਼ਿਲ ਨਿਯੰਤਰਣ ਵੀ ਨਹੀਂ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਬਾਹਰ ਕੱਢਣ ਨਾਲ ਉਹ ਹਰ ਪਤਾ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਬ੍ਰਾਊਜ਼ਰ ਪਹੁੰਚਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਟਨਲ ਦੇ ਅੰਦਰ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਜਦੋਂ ਲੋੜ ਐਪ ਦੀ ਥਾਂ ਮੰਜ਼ਿਲ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਤਦ ਐਪ ਚੋਣਕਰਤਾ ਬਣਾਵਟ ਨਾਲ ਹੀ ਗਲਤ ਸੰਦ ਹੈ।
ਫ਼ੋਨ ਲਈ ਟੈਥਰ ਕੀਤਾ ਪੈਕਟ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ
ਕਲਾਇੰਟ ਦਾ ਪੈਕਟ ਹੌਟਸਪੌਟ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਫ਼ੋਨ ਵੱਲੋਂ ਦਿੱਤੇ ਨਿੱਜੀ ਸਰੋਤ ਪਤੇ ਨਾਲ, ਮੰਨ ਲਓ 192.168.43.20, ਅਤੇ ਜਨਤਕ ਮੰਜ਼ਿਲ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਫ਼ੋਨ ਨੂੰ ਉੱਪਰਲੇ ਲਿੰਕ ਵੱਲ ਰਸਤਾ ਅਤੇ ਅਨੁਵਾਦ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਜਵਾਬ ਵਾਪਸੀ ਦਾ ਰਾਹ ਲੱਭ ਸਕਣ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਦਾ ਨਿੱਜੀ ਪਤਾ ਸੈਲੂਲਰ ਨੈੱਟਵਰਕ ’ਤੇ ਅਰਥਹੀਣ ਹੈ।
Android ਇਸਨੂੰ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਚੁਣਨ ਵਾਲੇ ਨੀਤੀ ਨਿਯਮਾਂ ਨਾਲ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਤੇ VPN ਬਦਲਣ ’ਤੇ netd ਸੰਬੰਧਿਤ ਸਾਰਣੀਆਂ ਅਤੇ ਨਿਯਮ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਫੋਰਮ ਪੋਸਟ ਜਾਂ ਉਸੇ ਮਾਡਲ ਦੇ ਪੁਰਾਣੇ ਰਿਲੀਜ਼ ਤੋਂ ਨਕਲ ਕੀਤਾ ਸਾਰਣੀ ਨੰਬਰ, ਨਿਯਮ ਤਰਜੀਹ ਜਾਂ ਇੰਟਰਫ਼ੇਸ ਨਾਮ ਟਿਕਾਊ ਮਾਲਕੀ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦਾ। ਇਹੀ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਉਸ ਦਾ ਵੀ ਕਾਰਨ ਹੈ ਕਿ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਨਿਯਮ ਇੱਕ ਘੰਟਾ ਕੰਮ ਕਰਕੇ ਅਗਲੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਰੁਕ ਸਕਦਾ ਹੈ।
ਹੌਟਸਪੌਟ ਅਪਵਾਦ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ
ਕਿਸੇ ਨਿਯਮ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ੈਸਲੇ ਨੂੰ ਸਰੋਤ, ਮੰਜ਼ਿਲ ਅਤੇ ਇੱਛਤ ਰਸਤੇ ਵਜੋਂ ਲਿਖੋ। ਇੱਕ ਮਨਜ਼ੂਰ ਮੰਜ਼ਿਲ ਲਈ ਘੱਟੋ-ਘੱਟ ਰੂਪ ਇਵੇਂ ਦਿਸਦਾ ਹੈ:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਪੂਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਿੱਧੀ ਸ਼ਾਖਾ ਨੂੰ ਮੌਜੂਦਾ ਸੈਲੂਲਰ ਉੱਪਰਲੇ ਲਿੰਕ ਰਾਹੀਂ ਵਰਤੋਂਯੋਗ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ; VPN ਸ਼ਾਖਾ ਨੂੰ ਟਨਲ ਰਸਤਾ ਅਤੇ ਫਾਰਵਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ। ਕੋਈ ਵੀ ਸਰੋਤ ਅਨੁਵਾਦ ਤੁਹਾਡੇ ਚੁਣੇ ਨਿਕਾਸ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਲਾਗੂ NAT ਟਨਲ ਦਾ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਸੈਲੂਲਰ ਦਾ ਨਹੀਂ, ਅਤੇ ਤਦ ਵਾਪਸੀ ਰਸਤਾ ਜਾਣ ਵਾਲੇ ਰਸਤੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਜਵਾਬਾਂ ਨੂੰ ਟਰੈਕ ਕੀਤੀ ਸਥਿਤੀ ਜਾਂ ਸਪਸ਼ਟ ਰਸਤੇ ਰਾਹੀਂ ਉਸੇ ਡਾਊਨਸਟ੍ਰੀਮ ਕਲਾਇੰਟ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਪੈਕਟਾਂ ਦਾ ਕਾਊਂਟਰ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸਿੱਧ ਨਹੀਂ ਕਰਦਾ। VPN ਦੀ ਆਪਣੀ ਬਾਹਰੀ ਢੁਆਈ ਨੂੰ ਵੀ ਅਪਵਾਦ ਦੇ ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਟਨਲ ਦੇ ਵਾਹਕ ਪੈਕਟ ਕਿਸੇ ਕਲਾਇੰਟ ਦੀ ਵੈੱਬ ਬੇਨਤੀ ਲਈ ਲਿਖੀ ਨੀਤੀ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾ ਲੈਣਗੇ।
ਫੜਿਆ ਇੱਕ ਪਤਾ ਮੰਜ਼ਿਲ ਨਹੀਂ ਹੈ
ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਪੜ੍ਹਿਆ ਇੱਕੋ IPv4 ਪਤਾ ਇੱਕ ਪਲ ਦੀ ਤਸਵੀਰ ਹੈ। ਵੱਡੀਆਂ ਸੇਵਾਵਾਂ anycast ਜਾਂ ਘੁੰਮਦੇ ਕਿਨਾਰੇ ਪਤਿਆਂ ਦੇ ਸਮੂਹ ਤੋਂ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਦੋਹਰੀ-ਸਟੈਕ ਹਨ, ਅਤੇ ਲੌਗਇਨ ਪ੍ਰਵਾਹ ਉਹ ਪ੍ਰਮਾਣਿਕਤਾ ਤੇ ਟੈਲੀਮੈਟਰੀ ਹੋਸਟ ਛੂਹ ਸਕਦਾ ਹੈ ਜੋ ਪੇਜ ਕਦੇ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਤੁਸੀਂ ਸੰਜੋਗ ਨਾਲ ਦੇਖੇ ਪਤੇ ਦੁਆਲੇ ਬਣਾਇਆ ਅਪਵਾਦ ਅਗਲੀ ਵਾਰ ਸੇਵਾ ਭਾਰ ਸੰਤੁਲਿਤ ਕਰਦਿਆਂ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਸੇਵਾ ਦੇ ਮਾਲਕ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਪਤੇ, ਜਾਂ ਉਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਉਹ ਰੇਂਜ ਵਰਤੋ, ਅਤੇ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਗਿਣੋ। ਜੇ ਲੋੜ ਨੂੰ ਸਥਿਰ ਸਮੂਹ ਵਜੋਂ ਪ੍ਰਗਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਇਹ ਸੰਭਵ ਤੌਰ ’ਤੇ ਸੇਵਾ ਲਈ ਨੀਤੀ ਦਾ ਸਵਾਲ ਹੈ, ਫ਼ੋਨ ’ਤੇ ਰਾਊਟਿੰਗ ਦੀ ਚਾਲ ਨਹੀਂ।
ਡਾਊਨਸਟ੍ਰੀਮ ਪਾਸੇ ਤੋਂ ਤਸਦੀਕ ਕਰੋ
ਤਿੰਨ ਜਾਂਚਾਂ, ਇਸ ਕ੍ਰਮ ਵਿੱਚ: ਲੈਪਟਾਪ ਤੋਂ ਚੁਣੀ ਸੇਵਾ, ਇੱਕ ਆਮ ਮੰਜ਼ਿਲ ਜੋ VPN ਦੇ ਅੰਦਰ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਫ਼ੋਨ ਐਪ ਜੋ ਅਛੂਤ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਫਿਰ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਉੱਪਰਲਾ ਲਿੰਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਤਦ ਹੀ ਨੀਤੀ ਸਾਰਣੀਆਂ ਦੁਬਾਰਾ ਬਣਦੀਆਂ ਹਨ।
ਜੇ ਫ਼ੋਨ ਦਾ ਸਾਂਝਾ ਕਰਨ ਦਾ ਅਮਲ ਦੁਬਾਰਾ ਜੁੜਨ ਦੌਰਾਨ ਉਹ ਇਕਰਾਰ ਨਹੀਂ ਰੱਖ ਸਕਦਾ, ਤਾਂ ਹੈਂਡਸੈਟ ’ਤੇ root ਨਿਯਮ ਇਕੱਠੇ ਕਰਨ ਦੀ ਥਾਂ ਚੋਣਵੀਂ ਨੀਤੀ ਨੂੰ ਸਮਰਥਿਤ ਡਾਊਨਸਟ੍ਰੀਮ ਰਾਊਟਰ ’ਤੇ ਲੈ ਜਾਓ। ਰਾਊਟਰ ਸਥਿਰ ਮਾਲਕ ਨਾਲ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਮਿਲਾਨ ਪ੍ਰਗਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਟੈਥਰਿੰਗ ਮਾਡਿਊਲ ਦਾ ਦਸਤਾਵੇਜ਼ ਇਸ ਗੱਲ ਦਾ ਸਹੀ ਹਵਾਲਾ ਹੈ ਕਿ ਫ਼ੋਨ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ।