Android ਇਮੂਲੇਟਰ ਅਤੇ ਹੋਸਟ VPN: DNS ਸਨੈਪਸ਼ਾਟ ਅਤੇ NAT ਦੀ ਵਿਆਖਿਆ
ਗੈਸਟ ਇਮੂਲੇਟਰ ਦੇ NAT ਪਿੱਛੇ ਬੈਠਦਾ ਹੈ ਅਤੇ boot ਵੇਲੇ ਕਾਪੀ ਕੀਤੀ DNS ਸੂਚੀ ਰੱਖਦਾ ਹੈ। boot ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਜੋੜੋ, ਫਿਰ ਗੈਸਟ ਦੇ ਅੰਦਰੋਂ ਰਿਜ਼ੌਲਿਊਸ਼ਨ ਜਾਂਚੋ।
ਜਦੋਂ ਇਮੂਲੇਟਰ ਉਸ build ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਪਾਉਂਦਾ ਜੋ ਹੋਸਟ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਠੀਕ ਖੁੱਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਕੰਮ ਦਾ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ VPN ਕੰਮ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਗੈਸਟ ਨੂੰ ਦੋ ਵਿੱਚੋਂ ਕਿਹੜੀ ਮਕੈਨਿਜ਼ਮ ਦੀ ਘਾਟ ਹੈ। ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਇਮੂਲੇਟਰ ਦੇ NAT ਪਿੱਛੇ ਆਪਣਾ ਨੈੱਟਵਰਕ ਸਟੈਕ ਚਲਾਉਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ boot ਵੇਲੇ ਲਈ ਗਈ ਕਾਪੀ ਹੈ, ਇਸ ਲਈ ਬਾਅਦ ਵਿੱਚ ਉੱਪਰ ਆਇਆ ਟਨਲ ਹੋਸਟ ਦਾ ਰਾਹ ਬਦਲਦਾ ਹੈ ਪਰ ਗੈਸਟ ਜੋ ਪੁੱਛਦਾ ਹੈ ਉਹ ਨਹੀਂ ਬਦਲਦਾ। ਇਹਨਾਂ ਦੋ ਪਰਤਾਂ ਨੂੰ ਸਮਝਣਾ ਇਸ ਸਮੱਸਿਆ ਦੀਆਂ ਲਗਭਗ ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
ਗੈਸਟ ਸਥਿਰ NAT ਪਿੱਛੇ ਇੱਕ ਵੱਖਰਾ ਸਟੈਕ ਹੈ
QEMU ਦੀ user-mode ਨੈੱਟਵਰਕਿੰਗ ਗੈਸਟ ਨੂੰ 10.0.2.15 ਤੇ, ਗੇਟਵੇ ਨੂੰ 10.0.2.2 ਤੇ ਅਤੇ DNS ਸੇਵਾ ਨੂੰ 10.0.2.3 ਤੋਂ 10.0.2.6 ਤੱਕ ਰੱਖਦੀ ਹੈ। ਗੈਸਟ ਦਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਹੋਸਟ ਕਰਨਲ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਹੋਸਟ ਪਾਸੇ ਦੇ ਸਾਕਟਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਹਰ ਗੈਸਟ ਕਨੈਕਸ਼ਨ ਲਈ ਇੱਕ, ਅਤੇ ਉਹ ਸਾਕਟ ਹੋਸਟ ਦੀ ਐਡਰੈਸ ਸਪੇਸ ਤੋਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ ਗੈਸਟ ਕਨੈਕਸ਼ਨ ਬਣਨ ਵੇਲੇ ਹੋਸਟ ਦਾ ਰਾਊਟਿੰਗ ਫੈਸਲਾ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਗੈਸਟ ਦੀ ਰਾਊਟ ਟੇਬਲ ਵਿੱਚ ਤੁਹਾਡੇ ਟਨਲ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਐਂਟਰੀ ਨਹੀਂ ਹੈ।
ਇਹੀ ਮਕੈਨਿਜ਼ਮ ਗੈਸਟ ਨੂੰ ਇੱਕ ਕੰਮ ਦਾ ਨਿਕਲਣ ਦਾ ਰਾਹ ਦਿੰਦਾ ਹੈ। 10.0.2.2 ਹੋਸਟ ਦੇ loopback ਇੰਟਰਫੇਸ ਦਾ ਉਪਨਾਮ ਹੈ, ਇਸ ਲਈ ਲੈਪਟਾਪ ਤੇ 127.0.0.1 ਤੇ ਸੁਣ ਰਹੀ ਸੇਵਾ ਉਸ ਐਡਰੈਸ ਤੇ ਗੈਸਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੈ। ਕਲਾਇੰਟ ਸਿਰਫ਼ loopback ਤੇ ਜੋ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਉਹ ਇਸ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਇਹ ਹੇਠਾਂ ਦੱਸੇ ਗਏ ਪ੍ਰੌਕਸੀ ਸੈਟਅੱਪ ਦਾ ਅਧਾਰ ਹੈ।
ਗੈਸਟ ਜੋ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਹੈ ਹੋਸਟ ਦੇ ਨੈੱਟਵਰਕ ਨੂੰ ਆਪਣੇ namespace ਵਾਂਗ ਦੇਖਣਾ। ਕੋਈ ਬ੍ਰਿਜ ਨਹੀਂ, ਸਾਂਝੀ ਰਾਊਟ ਟੇਬਲ ਨਹੀਂ ਅਤੇ ਕੋਈ ਵਿਰਾਸਤੀ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ; ਸਿਰਫ਼ ਇਸ ਦੇ ਪੈਕਟ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ NAT ਸੇਵਾ ਅਤੇ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਲਾਂਚਰ ਵੱਲੋਂ ਲਿਆ ਸਨੈਪਸ਼ਾਟ।
DNS ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਹੈ, ਜੀਵਤ ਨਜ਼ਾਰਾ ਨਹੀਂ
ਸ਼ੁਰੂ ਵਿੱਚ ਇਮੂਲੇਟਰ ਹੋਸਟ ਦੀ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਗੈਸਟ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਚਾਰ ਸਰਵਰ ਦਿੰਦਾ ਹੈ, ਜੋ 10.0.2.3 ਤੋਂ 10.0.2.6 ਐਡਰੈਸਾਂ ਤੇ ਖੁੱਲ੍ਹਦੇ ਹਨ। ਜੇ ਉਸ ਵੇਲੇ ਟਨਲ ਹੇਠਾਂ ਸੀ ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਵਿੱਚ ਲੈਪਟਾਪ ਵੱਲੋਂ ਵਰਤਿਆ ਕੋਈ ਵੀ ਪਬਲਿਕ ਰਿਜ਼ੌਲਵਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਗੈਸਟ ਆਪਣੀ ਸਾਰੀ ਉਮਰ ਉਸੇ ਨੂੰ ਪੁੱਛਦਾ ਰਹਿੰਦਾ ਹੈ। ਪਬਲਿਕ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਅੰਦਰੂਨੀ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਾਰੇ ਲੱਛਣ VPN ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਅਸਲ ਪੁਰਾਣਾ ਮੁੱਲ ਟਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਕੁਝ ਮਿੰਟ ਪਹਿਲਾਂ ਲਈ ਗਈ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ ਹੈ।
ਇਸ ਲਈ ਕ੍ਰਮ ਸੁਧਾਰਨਾ ਲੋਕ-ਕਥਾ ਨਹੀਂ ਹੈ। ਪਹਿਲਾਂ ਟਨਲ ਜੋੜੋ, ਫਿਰ ਇਮੂਲੇਟਰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਬਹਾਲ ਕਰਨ ਨਾਲੋਂ ਕੋਲਡ ਬੂਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਕਿਉਂਕਿ ਕਵਿੱਕ-ਬੂਟ ਇਮੇਜ ਪਹਿਲਾਂ ਸੰਭਾਲੀ ਰਿਜ਼ੌਲਵਰ ਅਤੇ ਰਾਊਟ ਸਥਿਤੀ ਨਾਲ ਵਾਪਸ ਆ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਗੈਸਟ ਹੁਣ ਕੀ ਵਰਤ ਰਿਹਾ ਹੈ ਤਾਂ ਹੋਸਟ ਨੂੰ ਨਹੀਂ, ਡਿਵਾਈਸ ਨੂੰ ਪੁੱਛੋ:
adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.exampleਇਮੂਲੇਟਰ ਸ਼ੁਰੂ ਵੇਲੇ ਸਪੱਸ਼ਟ ਰਿਜ਼ੌਲਵਰ ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਕੰਮ ਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਗੈਸਟ ਨੂੰ ਕਿਹੜਾ ਸਰਵਰ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਖ਼ਤਰਨਾਕ ਹੈ ਜਦੋਂ ਉਹ ਸਰਵਰ ਪਬਲਿਕ ਹੋਵੇ:
emulator -avd Pixel_API_34 -dns-server 203.0.113.53ਪਬਲਿਕ ਰਿਜ਼ੌਲਵਰ ਕੋਲ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਦੀ ਕਾਪੀ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਇੱਕ ਨੂੰ ਪਿੰਨ ਕਰਨਾ ਕ੍ਰਮ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪੱਕੀ ਅਸਫਲਤਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਜੇ ਪ੍ਰੋਫਾਈਲ ਪ੍ਰਾਈਵੇਟ DNS ਪੁਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਟਨਲ ਨੂੰ ਇਹ ਦੇਣ ਦਿਓ ਅਤੇ ਐਡਰੈਸ ਹਾਰਡ-ਕੋਡ ਕਰਨ ਦੀ ਥਾਂ ਗੈਸਟ ਨੂੰ ਕੋਲਡ ਬੂਟ ਕਰੋ।
ਰਾਊਟਿੰਗ ਕਨੈਕਸ਼ਨ ਵੇਲੇ ਹੋਸਟ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ
ਕਿਉਂਕਿ ਗੈਸਟ ਕਨੈਕਸ਼ਨ ਹੋਸਟ ਸਾਕਟ ਬਣਦੇ ਹਨ, ਰਾਊਟਿੰਗ ਫੈਸਲਾ ਸਾਕਟ ਬਣਨ ਵੇਲੇ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਬੇਨਤੀ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਉੱਪਰ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੇਨਤੀ ਪ੍ਰੋਫਾਈਲ ਦੀਆਂ ਰਾਊਟਾਂ ਦੇ ਅਧੀਨ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ। ਸਿਰਫ਼ ਚੁਣੇ ਪ੍ਰੀਫਿਕਸ ਢੋਣ ਵਾਲਾ ਸਪਲਿਟ-ਟਨਲ ਪ੍ਰੋਫਾਈਲ ਤੁਹਾਡੇ ਪ੍ਰਾਈਵੇਟ ਸਬਨੈੱਟ ਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਬਾਹਰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਗੈਸਟ ਬਾਰੇ ਇੱਕ ਅਨੁਮਾਨ ਹੈ, ਨਤੀਜਾ ਨਹੀਂ। ਮੌਜੂਦਾ ਗੈਸਟ ਕਨੈਕਸ਼ਨ ਉਹੀ ਰਾਹ ਰੱਖਦੇ ਹਨ ਜਿਸ ਨਾਲ ਬਣੇ ਸਨ, ਇਸ ਲਈ ਮੁੜ ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਇਮੂਲੇਟਰ ਵਿੱਚ ਅਟਕੀ ਡਾਊਨਲੋਡ ਨੂੰ ਹਮੇਸ਼ਾ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।
ਜਾਂਚ ਹੋਸਟ ਇੰਟਰਫੇਸ ਤੇ ਹੁੰਦੀ ਹੈ, ਗੈਸਟ ਦੇ ਅੰਕੜਿਆਂ ਵਿੱਚ ਨਹੀਂ:
sudo tcpdump -ni tun0 'host 203.0.113.10'ਜੇ ਗੈਸਟ ਦੀ ਬੇਨਤੀ ਟਨਲ ਇੰਟਰਫੇਸ ਤੇ ਦਿਖਦੀ ਹੈ ਤਾਂ ਰਾਊਟਿੰਗ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਇਸ ਤੋਂ ਉੱਪਰ ਹੈ। ਜੇ ਇਹ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਤੇ ਦਿਖਦੀ ਹੈ ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਉਸ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਨਹੀਂ ਢਕਦਾ, ਅਤੇ ਗੈਸਟ ਪਾਸੇ ਦੀ ਕੋਈ ਵੀ ਮੁੜ-ਸੰਰਚਨਾ ਇਹ ਨਹੀਂ ਬਦਲੇਗੀ।
ਜਦੋਂ ਕਲਾਇੰਟ ਸਿਰਫ਼ loopback ਪ੍ਰੌਕਸੀ ਦਿੰਦਾ ਹੈ
ਕੁਝ ਵਪਾਰਕ ਕਲਾਇੰਟ ਸਿਸਟਮ ਟਨਲ ਬਿਲਕੁਲ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਉਹ 127.0.0.1 ਤੇ HTTP ਜਾਂ SOCKS ਸੁਣਨ ਵਾਲਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਐਪਾਂ ਇਸਨੂੰ ਵਰਤਣਗੀਆਂ। ਗੈਸਟ ਉਹ ਸਾਕਟ ਸਿੱਧਾ ਨਹੀਂ ਦੇਖ ਸਕਦਾ, ਪਰ ਇਮੂਲੇਟਰ ਨੂੰ ਇਸਨੂੰ ਵਰਤਣ ਲਈ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਤਾਂ ਵਿਸਤ੍ਰਿਤ ਕੰਟਰੋਲਾਂ ਰਾਹੀਂ (Settings, ਫਿਰ Proxy, ਮੈਨੁਅਲ ਮੋਡ, ਹੋਸਟ 127.0.0.1 ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਛਾਪਿਆ ਪੋਰਟ) ਜਾਂ ਸ਼ੁਰੂ ਵੇਲੇ:
emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080ਕਲਾਇੰਟ ਵਿੰਡੋ ਤੋਂ ਪੋਰਟ ਕਾਪੀ ਕਰੋ; ਅਨੁਮਾਨਿਤ ਪੋਰਟ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਅਤੇ ਟੁੱਟੇ ਟਨਲ ਵਾਂਗ ਦਿਖਦਾ ਹੈ। ਯਾਦ ਰੱਖੋ ਇਹ ਕੀ ਢਕਦਾ ਹੈ: HTTP ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਨੂੰ ਪ੍ਰੌਕਸੀ ਜਾਣਨ ਵਾਲੀਆਂ ਐਪਾਂ ਮੰਨਦੀਆਂ ਹਨ, ਅਤੇ ਕੱਚੇ ਸਾਕਟ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਜੇ ਕੰਮ ਆਪਣੇ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਵਾਲੀ native binary ਹੈ ਤਾਂ ਪ੍ਰੌਕਸੀ ਦਾ ਰਾਹ ਟਨਲ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ ਅਤੇ ਤੁਲਨਾ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਕਰਨੀ ਪਵੇਗੀ।
ਨਤੀਜਾ ਗੈਸਟ ਦੇ ਅੰਦਰੋਂ ਸਾਬਤ ਕਰੋ
ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ ਦੋ ਟੈਸਟਾਂ ਨਾਲ ਰਿਜ਼ੌਲਿਊਸ਼ਨ ਅਤੇ ਰਾਊਟਿੰਗ ਵੱਖ ਕਰੋ। ਜਦੋਂ ਸੰਖਿਆਤਮਕ ਐਡਰੈਸ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਪਰ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ DNS ਸਨੈਪਸ਼ਾਟ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਹੱਲ ਕ੍ਰਮ ਜਾਂ ਸਪੱਸ਼ਟ ਰਿਜ਼ੌਲਵਰ ਹੈ। ਦੋਵੇਂ ਫੇਲ੍ਹ ਹੋਣ ਤਾਂ ਇਹ ਰਾਊਟਿੰਗ ਜਾਂ ਨੀਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਐਪ ਆਪਣੀਆਂ ਨੈੱਟਵਰਕ ਪਾਬੰਦੀਆਂ ਵਾਲੇ work profile ਅੰਦਰ ਚੱਲ ਰਹੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਆਖ਼ਰ ਵਿੱਚ, ਜਾਣੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਗੈਸਟ ਤੇ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ। ਬਹੁਤ ਪੁਰਾਣੀਆਂ ਇਮੂਲੇਟਰ ਇਮੇਜਾਂ ਗੈਸਟ ਪਾਸੇ ਦੇ VPN ਕਲਾਇੰਟ ਲਈ ਲੋੜੀਂਦੀ tun ਸਹਾਇਤਾ ਤੋਂ ਬਿਨਾਂ ਆਉਂਦੀਆਂ ਸਨ, ਇਸ ਲਈ ਉੱਥੇ ਕੋਈ ਪ੍ਰੋਫਾਈਲ ਕਦੇ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ; ਮੌਜੂਦਾ ਇਮੇਜਾਂ ਵਿੱਚ ਇਹ ਹੈ। ਮੌਜੂਦਾ ਇਮੇਜ ਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਕਲਾਇੰਟ ਕਲਾਇੰਟ ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਹੋਸਟ ਟਨਲ ਮੁੜ ਬਣਾਉਣਾ ਨਤੀਜਾ ਨਹੀਂ ਬਦਲੇਗਾ।