Android VPN ਰਾਊਟਿੰਗ: main ਟੇਬਲ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ-ਨਿਯਮ
Android ਕਿਸੇ ਵੀ ਮੰਜ਼ਿਲ ਖੋਜ ਤੋਂ ਪਹਿਲਾਂ uid ਅਤੇ ਨਿਸ਼ਾਨ ਨਿਯਮਾਂ ਨਾਲ ਰਾਊਟਿੰਗ ਟੇਬਲ ਚੁਣਦਾ ਹੈ, ਇਸ ਲਈ main ਵਿੱਚ ਜੋੜਿਆ ਰੂਟ ਕਦੇ ਵੀ ਜਾਂਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।
Android 'ਤੇ main ਟੇਬਲ ਵਿੱਚ ਜੋੜਿਆ ਰੂਟ ਹਰ ਸੂਚੀ ਵਿੱਚ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਢੋਂਦਾ। ਕਾਰਨ ਇਹ ਹੈ ਕਿ main ਟੇਬਲ ਕਈ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਪਹਿਲਾਂ ਨਹੀਂ ਪੁੱਛਿਆ ਜਾਂਦਾ। Android ਦੀ ਨੈੱਟਵਰਕਿੰਗ ਸੇਵਾ ਅਜਿਹੇ ਨੀਤੀ-ਨਿਯਮ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਰਾਊਟਿੰਗ ਟੇਬਲ ਨੂੰ ਉਸ ਜਾਣਕਾਰੀ ਨਾਲ ਚੁਣਦੇ ਹਨ ਜੋ ਮੰਜ਼ਿਲ ਪਤੇ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੀ — ਐਪ ਦਾ uid, ਪੈਕੇਟ ਉੱਤੇ ਨਿਸ਼ਾਨ, ਜਿਸ ਇੰਟਰਫੇਸ ਤੋਂ ਇਹ ਆਇਆ — ਅਤੇ ਮੰਜ਼ਿਲ ਦੀ ਖੋਜ ਉਸ ਤੋਂ ਬਾਅਦ, ਉਸ ਟੇਬਲ ਦੇ ਅੰਦਰ ਹੁੰਦੀ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਨਿਯਮਾਂ ਨੇ ਚੁਣਿਆ।
ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਤਿੰਨ ਫੈਸਲੇ
ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕੇਟ ਤਿੰਨ ਵੱਖਰੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ। ਪਹਿਲਾ, ਇੱਕ ਨੀਤੀ-ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਰਾਊਟਿੰਗ ਟੇਬਲ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਦੂਜਾ, ਉਸ ਟੇਬਲ ਦੇ ਅੰਦਰਲਾ ਰੂਟ ਅਗਲਾ ਹੌਪ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਇੰਟਰਫੇਸ ਤੈਅ ਕਰਦਾ ਹੈ। ਤੀਜਾ, netfilter ਹੁੱਕ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਪੈਕੇਟ ਬਚੇਗਾ, ਬਦਲੇਗਾ ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਹੋਵੇਗਾ।
ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਪੜਾਅ ਸਿਰਫ਼ ਆਪਣੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। ਪੈਕੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਟੇਬਲ ਨਹੀਂ ਚੁਣਦਾ, ਅਤੇ ਜਿਸ ਟੇਬਲ ਨੂੰ ਕੋਈ ਨਿਯਮ ਨਹੀਂ ਚੁਣਦਾ ਉਸ ਵਿੱਚ ਜੋੜਿਆ ਰੂਟ ਨਿਸ਼ਕਿਰਿਆ ਰਹਿੰਦਾ ਹੈ। Android VPN ਬਾਰੇ ਬਹੁਤੀ ਉਲਝਣ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੁਧਾਰ ਕੇ ਕੋਈ ਬਦਲਾਅ ਨਾ ਦਿਸਣ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਖਰਾਬੀ ਕਿਸੇ ਹੋਰ ਵਿੱਚ ਸੀ।
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
ਨਿਸ਼ਾਨ ਪੈਕ ਕੀਤੇ ਖੇਤਰ ਹਨ, ਤੁਹਾਡਾ ਆਪਣਾ ਲੇਬਲ ਨਹੀਂ
Android ਕਈ ਤੱਥ ਇੱਕੋ ਨਿਸ਼ਾਨ ਮੁੱਲ ਵਿੱਚ ਪੈਕ ਕਰਦਾ ਹੈ: ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਚੁਣਿਆ ਗਿਆ, ਕੀ ਕਿਸੇ ਐਪ ਨੇ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਨੈੱਟਵਰਕ ਚੁਣਿਆ, ਕੀ ਸਾਕਟ VPN ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ, ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਬਿੱਟ। AOSP ਦਾ fwmark ਹੈਡਰ ਮੌਜੂਦਾ ਰੁੱਖ ਲਈ ਉਹ ਲੇਆਉਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੇਆਉਟ ਪਲੇਟਫਾਰਮ ਦੀ ਅੰਦਰੂਨੀ ਗੱਲ ਹੈ ਜੋ ਰਿਲੀਜ਼ਾਂ ਵਿਚਕਾਰ ਬਦਲਦੀ ਹੈ।
ਇਸ ਲਈ Android 'ਤੇ iptables -j MARK --set-mark ਨਾਲ ਪੂਰਾ ਨਿਸ਼ਾਨ ਮੁੱਲ ਲਿਖਣਾ ਖ਼ਤਰਨਾਕ ਹੈ। ਇਹ ਟੈਗ ਨਹੀਂ ਜੋੜਦਾ; ਇਹ ਉਸ ਨੈੱਟਵਰਕ ਚੋਣ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਪਹਿਲਾਂ ਹੀ ਕਰ ਚੁੱਕਾ ਹੈ। ਫਿਰ ਪੈਕੇਟ ਹੋਰ ਨਿਯਮਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਜੋ ਕਿਹੜੇ ਬਿੱਟ ਮੁੜ ਲਿਖੇ ਗਏ ਇਸ ਆਧਾਰ ਤੇ VPN ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਜਾਂ ਕਿਸੇ ਅਸੰਬੰਧਿਤ ਐਪ ਦਾ ਕਨੈਕਸ਼ਨ ਜਾਣ ਵਰਗਾ ਦਿਸ ਸਕਦਾ ਹੈ।
ਜੇ ਨਿਸ਼ਾਨਾਂ ਨੂੰ ਛੂਹਣਾ ਹੀ ਪਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਮੁੱਲ ਪੜ੍ਹੋ ਅਤੇ ਮਾਸਕ ਵਰਤੋ ਤਾਂ ਜੋ ਸਿਰਫ਼ ਉਹ ਬਿੱਟ ਬਦਲਣ ਜੋ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11ਕਨੈਕਸ਼ਨ ਨਿਸ਼ਾਨ ਪੈਕੇਟ ਨਿਸ਼ਾਨ ਤੋਂ ਵੱਖਰੀ ਵਸਤੂ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਰੂਟ ਨਹੀਂ। ਜਵਾਬ ਪੈਕੇਟਾਂ ਤੇ ਨਿਸ਼ਾਨ ਬਹਾਲ ਕਰਨਾ ਬਾਹਰ ਜਾਣ ਵੇਲੇ ਟੇਬਲ ਚੁਣਨ ਤੋਂ ਵੱਖਰਾ ਕਦਮ ਹੈ, ਇਸ ਲਈ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਸੁਧਾਰ ਉਹ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਖੁੱਲ੍ਹਦੇ ਹਨ ਅਤੇ ਫਿਰ ਅਟਕ ਜਾਂਦੇ ਹਨ।
ਨਿਯਮਾਂ ਅਤੇ ਟੇਬਲਾਂ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ
Android ਦੀ ਨੈੱਟਵਰਕ ਸੇਵਾ, netd, ਨਿਯਮ ਅਤੇ ਹਰ ਨੈੱਟਵਰਕ ਦੇ ਟੇਬਲ ਬਣਾਉਂਦੀ ਹੈ। AOSP RouteController ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ VPN, ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਅਤੇ uid ਰੇਂਜਾਂ ਲਈ ਉਹ ਨਿਯਮ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਸਦਾ ਜੀਵਨ ਚੱਕਰ ਕਾਨਫਿਗ ਫਾਈਲ ਨਾਲ ਨਹੀਂ ਸਗੋਂ ਨੈੱਟਵਰਕ ਘਟਨਾਵਾਂ ਨਾਲ ਜੁੜਿਆ ਹੈ।
ਦੋ ਨਤੀਜੇ ਆਉਂਦੇ ਹਨ। ਪਹਿਲਾ, ਇੱਕ ਹੈਂਡਸੈੱਟ ਤੇ ਮਿਲਣ ਵਾਲੀਆਂ ਤਰਜੀਹਾਂ ਅਤੇ ਟੇਬਲ ਨੰਬਰ ਬਿਲਡ ਦੀਆਂ ਅੰਦਰੂਨੀ ਗੱਲਾਂ ਹਨ, ਇੰਟਰਫੇਸ ਨਹੀਂ: ਕਿਸੇ ਹੋਰ Android ਸੰਸਕਰਣ ਤੇ ਇੱਕੋ ਜਿਹੇ ਦਿਸਣ ਵਾਲੇ ਨੰਬਰ ਬਿਲਕੁਲ ਹੋਰ ਅਰਥ ਰੱਖ ਸਕਦੇ ਹਨ। ਦੂਜਾ, ਨੈੱਟਵਰਕ ਬਦਲਣ ਤੇ ਸਥਿਤੀ ਮੁੜ ਬਣਦੀ ਹੈ, ਇਸ ਲਈ ਅੱਜ root ਸ਼ੈੱਲ ਤੋਂ ਪਾਇਆ ਨਿਯਮ ਅਗਲੀ Wi-Fi ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਗਾਇਬ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸ ਗਾਇਬੀ ਨੂੰ ਅਕਸਰ ਸਿਸਟਮ ਰੂਟ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਰਿਹਾ ਹੈ ਵਜੋਂ ਰਿਪੋਰਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਹੋਇਆ ਇਹ ਹੈ ਕਿ ਜਿਸ ਨਿਯਮ ਨੇ ਟੇਬਲ ਚੁਣਿਆ ਸੀ ਉਹ ਹੁਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਟੇਬਲ ਦੇ ਅੰਦਰਲਾ ਰੂਟ ਹੁਣ ਪੈਕੇਟ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ। ਜਦੋਂ ਕੰਮ ਕਰਦਾ ਸੰਰਚਨਾ ਮੁੜ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰੇ, ਤਾਂ ਰੂਟ ਸੂਚੀ ਨਹੀਂ, ਨਿਯਮ ਸੂਚੀ ਵੇਖੋ।
ਹੁੱਕ ਕ੍ਰਮ ਦੇ ਸਵਾਲਾਂ ਦਾ ਸਰਬਵਿਆਪੀ ਜਵਾਬ ਨਹੀਂ
ਕੀ iptables VPN ਰਾਊਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ, ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਪੈਕੇਟ ਦਾ ਰਾਹ ਦੱਸੇ ਬਿਨਾਂ ਨਹੀਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ। ਸਥਾਨਕ ਤੌਰ ਤੇ ਬਣਿਆ ਪੈਕੇਟ output ਹੁੱਕ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਜਿੱਥੇ ਨਿਸ਼ਾਨ ਦਾ ਬਦਲਾਅ ਮੁੜ-ਰਾਊਟਿੰਗ ਜਾਂਚ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ — ਇਹ ਦੂਜੀ ਖੋਜ ਹੈ, ਪਹਿਲੀ ਦਾ ਪਿਛਲਾ ਸੋਧ ਨਹੀਂ। tether ਕੀਤੇ ਕਲਾਇੰਟ ਤੋਂ ਆਉਣ ਵਾਲਾ ਪੈਕੇਟ prerouting ਰਾਹ ਲੰਘਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਬਜਾਏ ਅੱਗੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਵੇਖਣ ਵਾਲੀਆਂ ਚੇਨਾਂ ਹੋਰ ਹਨ।
ਇਸ ਲਈ ਇੱਕੋ ਨਿਯਮ ਇੱਕ ਐਪ ਦੇ ਟ੍ਰੈਫਿਕ ਲਈ ਪ੍ਰਭਾਵੀ ਅਤੇ tether ਟ੍ਰੈਫਿਕ ਲਈ ਅਦ੍ਰਿਸ਼ਟ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਫ਼ਰ ਤੇ ਰਹਿਣ ਵਾਲਾ ਕਾਊਂਟਰ ਦੱਸਦਾ ਹੈ ਕਿ ਪੈਕੇਟ ਨੇ ਕਿਹੜਾ ਰਾਹ ਲਿਆ, ਨਿਯਮ ਗ਼ਲਤ ਹੈ ਕਿ ਨਹੀਂ ਨਹੀਂ। ਕੋਈ ਵੀ ਮੇਲ ਸ਼ਰਤ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਊਂਟਰਾਂ ਨਾਲ ਰਾਹ ਤੈਅ ਕਰੋ।
ਨੀਤੀ-ਰਾਊਟਿੰਗ ਦੀ ਗਲਤੀ ਵੇਖਣੀ ਔਖੀ ਹੋਣ ਵਾਲਾ ਪੜਾਅ ਵੀ ਇਹੀ ਹੈ। ਮੌਜੂਦ ਪਰ ਮੰਜ਼ਿਲ ਤੋਂ ਬਿਨਾਂ ਟੇਬਲ ਵਿੱਚ ਰਾਊਟ ਕਰਨ ਨਾਲ ਨੈੱਟਵਰਕ ਅਪਹੁੰਚ ਆਉਂਦਾ ਹੈ ਜੋ ਫਾਇਰਵਾਲ ਡ੍ਰੌਪ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਜਦਕਿ ਫਾਇਰਵਾਲ ਡ੍ਰੌਪ ਰਾਊਟਿੰਗ ਬਲੈਕ ਹੋਲ ਵਰਗਾ ਲੱਗਣ ਵਾਲਾ ਟਾਈਮਆਊਟ ਦਿੰਦਾ ਹੈ।
ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਨਿਦਾਨ ਕਰੋ, ਜਾਂ ਇਸਨੂੰ ਛੱਡ ਦਿਓ
ਅਧਿਕਾਰਤ ਸਮੀਖਿਆ ਲਈ, ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਤੱਥ ਤੈਅ ਕਰੋ: ਐਪ ਦਾ uid ਅਤੇ ਪ੍ਰੋਫਾਈਲ, Android ਨੇ ਇਸ ਲਈ ਕਿਹੜਾ ਨੈੱਟਵਰਕ ਚੁਣਿਆ, ਕੀ VPN ਉਸ ਐਪ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਸਮੱਸਿਆ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰਾਂ ਵਿੱਚ ਹੈ। ਪ੍ਰਤੀ-ਐਪ ਬਹਿਸ਼ਕਾਰ ਕਿਸੇ ਰਾਊਟਿੰਗ ਖਰਾਬੀ ਤੋਂ ਬਿਨਾਂ VPN ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਵਾਲੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
ਫਿਰ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਨਿਯਮ, ਮਾਸਕ ਅਤੇ ਟੇਬਲ ਪੜ੍ਹੋ, ਅਤੇ ਨਿਰੀਖਣ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਨੈੱਟਵਰਕ ਤਬਦੀਲੀ ਰੱਖੋ। ਜੇ ਮੁੜ ਜੁੜਨ ਦੌਰਾਨ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਬੰਧਿਤ ਜੀਵਨ ਚੱਕਰ ਵੇਖ ਰਹੇ ਹੋ, ਗੁੰਮ ਰੂਟ ਨਹੀਂ।
ਆਮ ਲੋੜਾਂ ਲਈ ਸਮਰਥਿਤ ਕੰਟਰੋਲ ਵਰਤੋ: ਪ੍ਰਤੀ-ਐਪ ਸ਼ਾਮਲ ਅਤੇ ਬਹਿਸ਼ਕਾਰ VPN ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ, ਅਤੇ ਖਾਸ ਰਾਹ ਚਾਹੁਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਲਈ ਪਲੇਟਫਾਰਮ ਦੀ ਆਪਣੀ ਨੈੱਟਵਰਕ ਚੋਣ। ਜੇ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਏਕੀਕਰਨ ਨੂੰ ਸੱਚਮੁੱਚ ਰਾਊਟਿੰਗ ਮਸ਼ੀਨਰੀ ਨਾਲ ਸਹਿਯੋਗ ਕਰਨਾ ਪਵੇ, ਤਾਂ ਤੁਸੀਂ ਸਮਰਥਨ ਦਿੰਦੇ ਹੋ ਉਸੇ ਸਹੀ Android ਸੰਸਕਰਣ ਦੇ ਅਮਲ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਓ ਅਤੇ ਉਸਦੇ ਮਾਲਕ ਹਿੱਸੇ ਰਾਹੀਂ ਇਸਦਾ ਜੀਵਨ ਚੱਕਰ ਕਾਇਮ ਰੱਖੋ। ਪਲੇਟਫਾਰਮ ਚੇਨਾਂ ਫਲਸ਼ ਕਰਨਾ ਜਾਂ ਉੱਚ ਤਰਜੀਹ ਵਾਲਾ ਨਿਯਮ ਪਾਉਣਾ ਨਿਦਾਨ ਨੂੰ ਦੂਜੇ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫ਼ੋਨ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰੇਗਾ।