Почему Android отказывается разрешать записи DNS, указывающие на внутренние IP-адреса?

У меня очень странное поведение на устройстве Android (Nexus 7) при попытке доступа к локальным сетевым приложениям. Вместо получения фактического IP-адреса машины в локальной сети устройство Android получает общедоступный IP-адрес, а это означает, что Chrome, Firefox или любой другой браузер просто показывает веб-страницу маршрутизатора.

У меня есть внутренний DNS-сервер, который обрабатывает локальные сети. Выполнение pingс ПК работает корректно:

$ ping s.pelicandd.com

PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=0.524 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=0.578 ms
^C

На устройстве HTC One (доступ с помощью adb shell) это тоже работает хорошо:

shell@m7:/ $ ping s.pelicandd.com

PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=27.8 ms
^C

Однако вот что я получаю, когда делаю то же самое pingс Nexus 7:

shell@flo:/ $ ping s.pelicandd.com

PING pelicandd.com (90.78.26.42) 56(84) bytes of data.
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=2 ttl=64 time=8.63 ms
^C

Вместо разрешения на внутренний IP-адрес он разрешается на общедоступный.

Конфигурация сети — за исключением IP-адреса устройства — абсолютно одинакова на обоих устройствах: настройки IP установлены на Static , а DNS-серверы — внутренние. Оба Android-устройства подключены через Wi-Fi (в отличие от ПК). Однако основное отличие заключается в том, что Nexus 7 использует Android 6.0.1, а HTC One — Android 5.0.2.

Нет nm-tool, digили nslookupна Nexus 7. Устройство не рутировано.

Проблема существовала с тех пор, как я купил устройство несколько недель назад, так что вряд ли проблема в кеше DNS.

Что я могу сделать для дальнейшего изучения этой проблемы?

Прежде всего Вы должны, конечно же, осмотреть проблему. Поэтому, пожалуйста, установите IP Tools из Play Store, сделайте несколько nslookup и так далее, и тогда мы узнаем больше. Особенно использование DNS-сервера Nexus, поиск DNS и так далее. Попробуйте это IP-инструменты . Это на польском языке, но, конечно, вы можете изменить его. Этот инструмент я использую в случае таких проблем.
Хм. В IP Info отображаются правильные DNS-адреса. При поиске DNS отображается правильный IP-адрес (192.168.1.15). Однако на вкладке Traceroute отображается неправильный общедоступный IP-адрес (90.78.26.42).
Итак, на мой взгляд, что-то не так с внутренней записью DNS для Nexus. Я использую аналогичную конфигурацию, и все работает нормально
Внутренний DNS отлично работает на моем Nexus 6p, Nexus 5, Nexus 10 и т. д. Пробовали ли вы прошивать заводские образы на Nexus 7 (если его загрузчик разблокирован), чтобы убедиться, что на нем работает заведомо исправное программное обеспечение? (Полагаю, вы привыкли, поскольку Nexus 7 — не новое устройство).
Я купил его подержанным, но перед использованием я сделал сброс с последующим обновлением до последней версии Android. Я полагаю, этого достаточно, чтобы убедиться, что на нем не запущено какое-либо специальное программное обеспечение, учитывая, что устройство не рутировано.
Мне пришлось вернуться к использованию c-ares ( c-ares.haxx.se ), созданного для Android, вместо встроенного в Android преобразователя DNS. Используя c-ares, вы даже можете выполнять поиск имен хостов без домена поиска, прикрепленного к локальным сетям. (например, мой компьютер вместо mycomputer.local.tld)

Ответы (3)

Недавно мы столкнулись с этой проблемой и сузили ее до ТОЛЬКО на устройствах под управлением Android v5 и новее. Android v4 и все другие ОС не имеют проблем.

С этим лакомым кусочком мы определили, что Android v5 и новее настаивает на использовании IPv6 для разрешения имен DNS. (Поскольку мы полностью отключили IPv6 в нашей сети, это согласуется с проблемой.) Если Android v5(+) не может получить ответ IPv6 от локального DNS, он обращается к хосту общедоступного имени Google (8.8.8.8). . Следовательно, нет внутреннего DNS, только внешний.

Мы решили эту проблему, создав DNS-записи на наших общедоступных DNS-серверах для некоторых внутренних имен и IP-адресов. После этого общедоступный DNS Google сможет разрешить эти внутренние имена с внутренними IP-адресами, и устройства смогут получить доступ к нашим внутренним хостам.

Мы продолжаем полностью включать IPv6 на наших внутренних DNS-серверах (контроллерах домена) в качестве постоянного исправления.

=========================================

ОБНОВЛЕНИЕ. Оказывается, это может быть отвлекающим маневром... или нет. Моя домашняя сеть — Win2008R2, однодоменная с DHCP и DNS и без привязки IPv6. Оттуда протестировано устройство Android v5, и у него НЕТ ПРОБЛЕМ. Офисная сеть с проблемой — Win2012 (не R2), однодоменная.

Обход текущих офисных WAP с автономным Linksys WAP и отдельным SSID для тестирования, проблема не устранена.

Различия между офисными и домашними сетями (насколько я могу вспомнить): - версия Windows - 2012 и 2008 R2 - модель маршрутизатора (Cisco и Linksys) - модель WAP (Aruba Networks под брендом Dell и Linksys)

Приступая к любым дальнейшим испытаниям, которые я могу придумать, чтобы сузить проблему. Любые предложения или вход очень ценятся!

=========================================

ПРОБЛЕМА УШЛА (?!)

Наша проблема, казалось, исчезла сама по себе после изменения топологии сети, которое, я бы не подумал, было связано, но вот информация на всякий случай.

(ОГРОМНЫЕ ИЗВИНЕНИЯ за эту длинную и затянутую историю, но именно тогда наши проблемы с Android исчезли, так что смиритесь с этим, если можете. Я, вероятно, предоставляю здесь ОЧЕНЬ много подробностей, но поскольку я не вижу прямой связи, Я излагаю все так, как это было.)

Наш интернет-провайдер — Comcast Business Class — кабельный модем со статическим блоком IP из пяти адресов (странное число, но именно так их продает Comcast). Кабельный модем Comcast, по сути, является комбинацией модем/брандмауэр/маршрутизатор/коммутатор, в которую удаленно запрограммирован наш статический IP-блок.

В течение 10 с лишним лет и почти столько же работодателей я всегда строил офисные сети одним и тем же образом:
настраивал IP-адрес в локальной сети для модема/маршрутизатора интернет-провайдера, через который проходит NAT-трафик из Интернета. Проще и быть не может, и именно так устроена моя текущая офисная сеть уже четыре года.

Недавно в нашем офисе отключился интернет. Обычно это исправляет перезагрузка модема, но когда этого не произошло, мы позвонили в Comcast, который прислал техника, который заменил кабельный модем для восстановления обслуживания.

Через несколько дней повторилось то же самое. Мы снова позвонили, и местный техник (другой техник, чем раньше) снова попытался заменить модем, на этот раз более новой моделью. Удивительно, но новый кабельный модем не поддерживал изменение адреса подсети LAN. Подсеть по умолчанию — 10.1.10.0/24, и ее нельзя изменить. (Только 4-й октет можно было настроить.) Поскольку подсеть нашего офиса — 192.168.100.0/24, я сообщил техническому специалисту, что мы не можем использовать ее, не имея возможности изменить подсеть LAN. Он понял, но не знал, почему кабельный модем помешает изменению. Поэтому он установил сменный модем той же модели, что и раньше, который мы настроили идентично, и доступ в Интернет был восстановлен.

Проходит еще день или два, и сервис снова падает. На этот раз, когда я позвонил в Comcast, первый технический специалист, с которым я разговаривал, задал подробные и знающие вопросы о конфигурации нашей сети. Когда я объяснил, что кабельный модем был сконфигурирован с IP-адресом локальной сети в нашей подсети, он, похоже, был озадачен этим. Он сказал, что большинство клиентов Comcast подключают NAT-маршрутизатор между кабельным модемом и локальной сетью, а не используют NAT кабельного модема. На самом деле, он сказал, что не знал, что кабельный модем поддерживает NAT.

Comcast разослал еще одну технику с совершенно новым кабельным модемом (последняя модель, которая не поддерживает изменение подсети LAN). Он провел тщательное тестирование существующего модема и, наконец, определил, что он пропускает только трафик IPv6, а не IPv4. Он также подтвердил то, что сказал телефонный техник — рекомендуется использовать отдельный маршрутизатор для NAT и не менять подсеть LAN на кабельном модеме (что мы все равно не можем сделать на более новых модемах сейчас).

И вот мы, наконец, подошли к изменению сети, которое мы сделали. Я установил простой маршрутизатор LinkSys между кабельным модемом и нашим основным маршрутизатором, настроив наш статический IP-адрес на стороне модема и IP-адрес локальной сети внутри. Затем интернет-сервис был восстановлен и некоторое время оставался стабильным.

После того, как интернет-соединение было восстановлено, я подумал о странности проблемы IPv6 с кабельным модемом, что, в свою очередь, напомнило мне о проблеме с Android v5. Затем я проверил наши Android-устройства в офисе и был ошеломлен, увидев, что проблема с DNS больше не возникает.

Добавление маршрутизатора LinkSys для NAT — это ЕДИНСТВЕННОЕ ИЗМЕНЕНИЕ СЕТИ, которое мы сделали. Совпадение?? Возможно, но мне показалось немного странным, что оба были связаны с IPv6.

В любом случае, извините еще раз за длинную историю, но наша проблема с Android исчезла. Сделайте из этого все, что сможете.

Димарк67

На самом деле, это должно быть причиной и в моем случае, так как я не использую IPv6 внутри себя. Я обошел проблему с DNS, создав локальный VPN-сервер и попросив Android-устройство использовать вместо этого VPN; это работает, но это, очевидно, слишком радикально.
@ArseniMourzenko Вы когда-нибудь решали эту проблему? Я буквально потратил два дня, ничего не делая, кроме как пытаясь решить эту проблему, поскольку она буквально сломала многое из того, что раньше работало. И да, я попробовал VPN, но он снизил скорость передачи со 100 Мбит/с+ до примерно 20
@Michael: поскольку мои локальные DNS-серверы настроены на поддержку только IPv4, ответ Dimarc67 был для меня актуален (именно поэтому он помечен как принятый ответ). Оттуда я только что настроил VPN для всех Android-устройств и с тех пор с удовольствием им пользуюсь. Я не заметил какого-либо снижения скорости передачи данных — меня бы это не волновало, учитывая то, как я пользуюсь мобильными устройствами. Что бы это ни стоило, я использую OpenVPN на стороне сервера Debian и OpenVPN Connect на устройствах Android.

Я наткнулся на этот пост, пытаясь заставить свое устройство Android 6.0 использовать локально настроенный DNS-сервер для разрешения локальных имен хостов. В одном ответе выше указано, что Android 5.0 и новее настаивают на использовании DNS-серверов IPv6. Это была подсказка, которая привела меня к моему решению.

Мой маршрутизатор рекламировал DNS-серверы IPv6, предоставленные моим интернет-провайдером, с использованием DHCP-PD. Я перенастроил свой маршрутизатор, чтобы он перестал рекламировать DNS-серверы IPv6, и теперь устройство Android 6.0 разрешает локальное имя хоста, используя DNS-сервер IPv4, предоставленный DHCP (IPv4).

У меня также есть DNAT для перенаправления всех DNS-запросов (TCP/UDP порт 53) на мой локальный DNS-сервер. Это было на месте до отключения рекламы маршрутизатора с DNS-серверами IPv6, поэтому я не знаю, откатывается ли Android 5.0+ к DNS-серверам Google (как утверждалось в предыдущем ответе), и я поймал их с помощью своего правила DNAT или мой Android Устройство 6.0 только что использовало DNS-сервер IPv4, назначенный DHCP. В любом случае, разрешение локального имени хоста теперь работает.

Отключение IPV6 на моем маршрутизаторе устранило проблему на ВСЕХ моих устройствах Android!

В конце концов я смог решить эту проблему, самостоятельно настроив DHCP-сервер в той же сети, который настраивает правильный домен поиска для отправки клиентам.

Когда-то у меня был dhcp-сервер, в моем случае isc-dhcpd с конфигурацией в dhcp.conf:

option domain-name "myrealdomain.tld";

Android смог разрешить локальные A-записи, установленные на моем DNS-сервере.