Android DNS ਸਹੀ ਪੜ੍ਹੋ: ਨੈੱਟਵਰਕ ਅਨੁਸਾਰ, resolv.conf ਵਿੱਚ ਨਹੀਂ

ਤੁਹਾਡੀ Android ਐਪ ਹਰ ਨੈੱਟਵਰਕ ਦੇ resolver ਰਾਹੀਂ ਹੱਲ ਕਰਦੀ ਹੈ, ਉਸ resolv.conf ਰਾਹੀਂ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਪੜ੍ਹਿਆ। ਪਹਿਲਾਂ LinkProperties, socket ਬਾਈਂਡਿੰਗਾਂ ਅਤੇ Private DNS ਵੇਖੋ।

ਤੁਸੀਂ ਡਿਵਾਈਸ 'ਤੇ shell ਲੈਂਦੇ ਹੋ, /etc/resolv.conf ਪੜ੍ਹਦੇ ਹੋ ਜਾਂ ਪੁਰਾਣਾ net.dns1 ਮੁੱਲ ਪੁੱਟ ਕੇ ਕੱਢਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਪਤਾ ਮਿਲਦਾ ਹੈ। ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੀ ਐਪ ਬਿਲਕੁਲ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਰਾਹੀਂ ਹੱਲ ਕਰਦੀ ਹੈ। ਮੌਜੂਦਾ Android ਰੀਲੀਜ਼ ਵਿੱਚ resolver ਨੈੱਟਵਰਕ ਅਨੁਸਾਰ ਹੈ: ਸਿਸਟਮ ਹਰ Network ਲਈ ਨੀਤੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਉਸ socket 'ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜਿਸ ਨੇ ਬੇਨਤੀ ਭੇਜੀ। ਫ਼ਾਈਲ ਅਤੇ ਪੁਰਾਣਾ ਗੁਣ ਬਚੇ ਹੋਏ ਹਿੱਸੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਹ ਰਾਹ ਨਹੀਂ ਦੱਸਦਾ ਜੋ ਤੁਹਾਡੀ ਕਵੈਰੀ ਨੇ ਅਸਲ ਵਿੱਚ ਲਿਆ।

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

resolver ਨੈੱਟਵਰਕ ਦਾ ਹੁੰਦਾ ਹੈ, ਡਿਵਾਈਸ ਦਾ ਨਹੀਂ

Android 9 ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨਾਵਾਂ ਦਾ ਹੱਲ ਸਿਸਟਮ resolver ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਜੋ ਉਸ Network 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਜਿਸ ਨਾਲ socket ਬੱਝਾ ਹੈ। ਹਰ ਨੈੱਟਵਰਕ ਆਪਣੀ LinkProperties ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇਹ ਗੁਣ ਸਿਰਫ਼ ਉਸੇ ਨੈੱਟਵਰਕ ਲਈ DNS ਸਰਵਰਾਂ ਦੀ ਸੂਚੀ, ਖੋਜ ਡੋਮੇਨ ਅਤੇ Private DNS ਸਥਿਤੀ ਰੱਖਦੇ ਹਨ। ਉਸ ਮਾਡਲ ਵਿੱਚ ਫ਼ਾਈਲ ਤੋਂ ਪੜ੍ਹੀ ਜਾ ਸਕਣ ਵਾਲੀ ਇੱਕੋ ਡਿਵਾਈਸ-ਵਿਆਪੀ ਸੂਚੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਕੁਝ ਨਹੀਂ।

VPN ਇਸ ਵੰਡ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਟਨਲ ਉੱਤੇ ਆਉਣ 'ਤੇ VPN ਐਪ VPN ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ 'ਤੇ ਦਰਜ DNS ਸਰਵਰ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਉਸ ਰਾਹੀਂ ਰੂਟ ਹੋਣ ਵਾਲੀਆਂ ਐਪਾਂ ਉਹਨਾਂ ਸਰਵਰਾਂ 'ਤੇ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਜਦਕਿ ਬਾਹਰ ਰੱਖੀਆਂ ਐਪਾਂ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਵਰਤਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਡਿਵਾਈਸ, ਦੋ ਜਵਾਬ ਰਾਹ, ਕੋਈ ਟਕਰਾਅ ਨਹੀਂ।

ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਭਾਵਿਤ ਐਪ ਦੇ ਅੰਦਰੋਂ ਪੜ੍ਹੋ

ਐਪ ਨੂੰ ਹੀ ਪੁੱਛੋ। ਜਿਸ ਮੈਥਡ ਕੋਲ Context ਅਤੇ ਆਮ android.permission.ACCESS_NETWORK_STATE ਇਜਾਜ਼ਤ ਹੈ, ਉਹ ਸਿਸਟਮ ਗੁਣਾਂ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਸਨੈਪਸ਼ਾਟ ਪੜ੍ਹ ਸਕਦਾ ਹੈ:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਹੈ, ਡਿਵਾਈਸ ਦਾ ਇਕੱਲਾ ਨੈੱਟਵਰਕ ਨਹੀਂ, ਅਤੇ null ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਾਲਰ ਕੋਲ ਵਰਤਣਯੋਗ ਡਿਫ਼ਾਲਟ ਨਾ ਹੋਵੇ। ਰੋਕਿਆ ਡਿਫ਼ਾਲਟ VPN ਆਮ ਕਾਰਨ ਹੈ। isPrivateDnsActive ਦੱਸਦਾ ਹੈ ਕਿ ਉਸ ਨੈੱਟਵਰਕ ਦੀਆਂ ਕਵੈਰੀਆਂ TLS ਰਾਹੀਂ ਨਾਮਿਤ resolver ਤੱਕ ਜਾਂਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ, ਜੋ ਬਦਲਦਾ ਹੈ ਕਿ ਸਾਧਾਰਨ UDP 53 ਜਾਂਚ ਤੁਹਾਨੂੰ ਕੀ ਦਿਖਾਏਗੀ। API ਸਤਹ LinkProperties ਹੇਠ ਦਸਤਾਵੇਜ਼ੀ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਹਰ ਮੁੱਲ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦਾ ਸਨੈਪਸ਼ਾਟ ਹੈ, ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਕੋਈ ਖ਼ਾਸ ਕਵੈਰੀ ਕਿਸੇ ਖ਼ਾਸ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚੀ।

ਜਦੋਂ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨੈੱਟਵਰਕ ਨਾ ਹੋਵੇ

ਸਨੈਪਸ਼ਾਟ ਸਿਰਫ਼ ਡਿਫ਼ਾਲਟ ਲਈ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਐਪ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਇੱਕ socket ਨੂੰ ਕਿਸੇ ਹੋਰ ਨੈੱਟਵਰਕ ਨਾਲ ਬੰਨ੍ਹ ਸਕਦੀ ਹੈ, ਫਿਰ ਹੱਲ ਉਸ ਚੋਣ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਜਦਕਿ ਤੁਹਾਡੀ ਡਾਇਗਨੋਸਟਿਕ ਅਜੇ ਵੀ ਡਿਫ਼ਾਲਟ ਦੱਸਦੀ ਹੈ। ਆਪਣਾ DNS-over-HTTPS resolver ਲਿਆਉਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਸਿਸਟਮ ਸੂਚੀ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਪੁੱਛਦਾ, ਇਸ ਲਈ ਉਸ ਦੇ ਜਵਾਬ ਬਾਕੀ ਡਿਵਾਈਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੇ। ਵਰਕ ਪ੍ਰੋਫ਼ਾਈਲ ਐਪ ਆਪਣੀ ਨੀਤੀ ਨਾਲ ਵੱਖਰੇ ਵਰਤੋਂਕਾਰ ਹੇਠ ਚੱਲਦੀ ਹੈ। ਸਰਵਰਾਂ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਬਾਈਂਡਿੰਗ ਵੇਖੋ।

VPN ਏਕੀਕਰਨ ਦੂਜਾ ਅੱਧ ਹੈ। dhcp-option DNS ਲਾਈਨ OpenVPN ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਤੇ ਉਸ ਪਤੇ ਨੂੰ Android VPN ਨੈੱਟਵਰਕ 'ਤੇ ਦਰਜ ਕਰਨਾ ਦੋ ਵੱਖਰੇ ਕਦਮ ਹਨ, ਅਤੇ ਸਰਵਰ ਤੱਕ ਗੁੰਮ ਰਾਹ ਗਲਤ ਪਤੇ ਵਾਂਗ ਹੀ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਡਿਵੈਲਪਮੈਂਟ ਮਸ਼ੀਨ ਤੋਂ adb shell dumpsys connectivity ਉਹੀ ਲਿੰਕ ਗੁਣ ਪ੍ਰਤੀ ਨੈੱਟਵਰਕ ਛਾਪਦਾ ਹੈ ਜਦੋਂ build ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ ਕੋਡ ਲਿਖੇ ਬਿਨਾਂ ਸੂਚੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।

ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦੀ ਤੁਲਨਾ ਇੱਕ ਅਜਿਹੇ ਹੱਲ ਨਾਲ ਕਰੋ ਜਿਸ ਦੀ ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਹੈ

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

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

ਜਿਸ ਪਰਤ ਦਾ ਇਹ ਅਸੰਗਤੀ ਹੈ ਉਸ ਨੂੰ ਠੀਕ ਕਰੋ

ਗਲੋਬਲ ਸਥਿਤੀ ਸੋਧਣ ਦੀ ਥਾਂ ਉੱਪਰ ਵੱਲ ਕੰਮ ਕਰੋ। ਜੇ ਐਪ ਗਲਤ ਨੈੱਟਵਰਕ ਨਾਲ ਬੱਝੀ ਹੈ ਤਾਂ ਬਾਈਂਡਿੰਗ ਠੀਕ ਕਰੋ। ਜੇ ਪ੍ਰੋਫ਼ਾਈਲ ਗਲਤ DNS ਚੋਣ ਦਿੰਦਾ ਹੈ ਤਾਂ ਪ੍ਰੋਫ਼ਾਈਲ ਠੀਕ ਕਰੋ। ਜੇ Private DNS ਉਸ ਨੈੱਟਵਰਕ 'ਤੇ ਸਖ਼ਤ ਹੈ ਜਿਸ ਦਾ resolver ਤੁਹਾਡੇ ਨਿੱਜੀ ਜ਼ੋਨ ਦੀ ਸੇਵਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਇਹ ਡਿਵਾਈਸ ਪ੍ਰਬੰਧਨ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਹਰ ਥਾਂ ਸੁਵਿਧਾ ਬੰਦ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ।

ਜਨਤਕ resolverਾਂ ਨੂੰ DHCP ਹੁੱਕ ਜਾਂ ਸਿਸਟਮ ਗੁਣ ਵਿੱਚ ਧੱਕਣਾ ਉਹ ਮੁਰੰਮਤ ਹੈ ਜੋ ਲਗਾਤਾਰ ਘਟਨਾਵਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ: ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਬਦੀਲੀ VPN ਸੈਸ਼ਨ ਤੋਂ ਅੱਗੇ ਟਿਕਦੀ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ 'ਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਬਿਨਾਂ ਮਾਲਕ ਵਾਲਾ ਪੁਰਾਣਾ ਪਤਾ ਲੱਭਦਾ ਹੈ। ਤਬਦੀਲੀ ਨੂੰ VPN, ਐਪ ਜਾਂ ਉਸ ਪ੍ਰਬੰਧਨ ਪਰਤ ਦੇ ਅੰਦਰ ਰੱਖੋ ਜਿਸ ਦੀ ਇਹ ਅਸੰਗਤੀ ਹੈ, ਫਿਰ ਸਨੈਪਸ਼ਾਟ ਦੁਬਾਰਾ ਪੜ੍ਹ ਕੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਵਰ ਸੂਚੀ ਸੱਚਮੁੱਚ ਬਦਲੀ ਹੈ।

ਅੰਤ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਨੈੱਟਵਰਕ, resolver ਸੂਚੀ ਅਤੇ Private DNS ਸਥਿਤੀ ਨਾਲ ਬੱਝੀ ਇੱਕ ਐਪ ਬੇਨਤੀ ਚਾਹੁੰਦੇ ਹੋ। ਇਹ ਜ਼ੰਜੀਰ ਦਿਖਾ ਸਕਣ 'ਤੇ ਫ਼ਾਈਲ ਵਿੱਚਲਾ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਪਤਾ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਬੂਤ ਨਹੀਂ ਰਹਿੰਦਾ।

ਸੰਬੰਧਿਤ ਲੇਖ