У меня очень странное поведение на устройстве 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 установлены на статический , а DNS-серверы являются внутренними. Оба устройства Android подключены через Wi-Fi (в отличие от ПК). Однако основное отличие заключается в том, что Nexus 7 использует Android 6.0.1, а HTC One использует Android 5.0.2.
Существует нет nm-tool, digилиnslookup на Nexus 7. Устройство не укоренились.
Проблема существовала с тех пор, как я купил устройство несколько недель назад, поэтому вряд ли это может быть проблема с кешем DNS.
Что я могу сделать для дальнейшей проверки этой проблемы?
источник
Ответы:
Мы недавно столкнулись с этой проблемой, и мы сузили ее до ТОЛЬКО на устройствах под управлением 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 с автономным WAP Linksys и отдельным SSID для тестирования, проблема сохраняется.
Различия между офисными и домашними сетями (о которых я могу подумать): - версия Windows - 2012 и 2008 R2 - модель маршрутизатора (Cisco против Linksys) - модель WAP (Dell Aruba Networks против Linksys)
Продолжая любые дальнейшие испытания, я могу придумать, чтобы сузить проблему. Любые предложения или предложения очень ценятся!
=========================================
ПРОБЛЕМА УШЛА (?!)
Наша проблема, казалось, исчезла сама по себе после изменения топологии сети, которое, я не думаю, было связано, но вот информация на всякий случай.
(ОГРОМНЫЕ извинения за эту длинную, затянувшуюся историю, но это когда наши проблемы с Android исчезли, так что постарайтесь решить эту проблему, если можете. Я, вероятно, предоставляю слишком много деталей здесь, но потому что я не вижу прямой связи, Я выкладываю все именно так, как это произошло.)
Наш провайдер - Comcast Business Class - кабельный модем со статическим IP-блоком из пяти адресов (странное число, но именно так Comcast продает их). Кабельный модем Comcast, по сути, представляет собой комбинированный модем / брандмауэр / маршрутизатор / коммутатор, в который удаленно запрограммирован наш статический IP-блок.
Более 10 лет и почти столько же работодателей я всегда строил офисные сети одинаково:
настраивал IP-адрес локальной сети для модема / маршрутизатора ISP, который использует NAT для трафика из Интернета. Не может быть проще, и вот так моя нынешняя офисная сеть была настроена на четыре года.
Недавно наш офис интернет-сервис отключился. Обычно перезапуск модема исправляет это, но когда этого не произошло, мы позвонили в Comcast, который прислал технику, который заменил кабельный модем для восстановления службы.
Несколько дней спустя то же самое произошло снова. Мы позвонили снова, и техник на месте (отличающийся от прежнего) попытался заменить модем снова, на этот раз более новой моделью. Удивительно, но новый кабельный модем не поддерживает изменение адреса подсети LAN. Подсеть по умолчанию - 10.1.10.0/24, и ее нельзя изменить. (Конфигурируемый был только 4-й октет.) Поскольку наша офисная подсеть имеет 192.168.100.0/24, я дал знать специалисту, что мы не можем использовать его, не имея возможности изменить подсеть LAN. Он понимал, но не знал, почему кабельный модем предотвратит изменения. Поэтому он установил заменяющий модем той же модели, что и раньше, который мы настроили идентично, и доступ в Интернет был восстановлен.
Проходит еще один или два дня, и сервис снова выходит из строя. На этот раз, когда я позвонил в Comcast, начальная технология, с которой я говорил, задавала подробные и знающие вопросы о конфигурации нашей сети. Когда я объяснил, что кабельный модем был настроен с IP-адресом локальной сети в нашей подсети, он казался озадаченным этим. Он сказал, что большинство клиентов Comcast подключают маршрутизатор NAT'ing между кабельным модемом и локальной сетью, а не используют NAT кабельного модема. На самом деле он сказал, что не знает, что кабельный модем поддерживает NAT.
Comcast выпустил еще одну технологию с совершенно новым кабельным модемом (последняя модель, которая не поддерживает изменение подсети LAN). Он провел обширное тестирование на существующем модеме и в конце концов определил, что он пропускает только трафик IPv6, но не IPv4. Он также подтвердил то, что сказал технический специалист по телефону - что для NAT'а рекомендуется использовать отдельный маршрутизатор и не менять подсеть ЛВС на кабельном модеме (чего мы сейчас не можем сделать на более новых модемах).
И теперь мы наконец пришли к изменениям сети, которые мы сделали. Я установил простой маршрутизатор LinkSys между кабельным модемом и нашим основным маршрутизатором, настроив статический IP-адрес на модемной стороне и локальный IP-адрес на внутренней стороне. Интернет-сервис был восстановлен и оставался стабильным в течение некоторого времени.
После восстановления интернет-службы я подумал о странной проблеме IPv6 с кабельным модемом, которая, в свою очередь, напомнила мне проблему Android v5. Затем я проверил наши устройства Android в офисе и был ошеломлен, увидев, что проблема с DNS больше не возникает.
Добавление маршрутизатора LinkSys для NAT'ов - ЕДИНСТВЕННОЕ ИЗМЕНЕНИЕ СЕТИ, КОТОРОЕ МЫ СДЕЛАЛИ. Совпадение?? Возможно, но это только показалось немного странным, что оба были связаны с IPv6.
В любом случае, еще раз извините за длинную историю, но наша проблема с Android исчезла. Сделай из этого все, что можешь.
Dimarc67
источник
Я сталкивался с этим сообщением, пытаясь заставить мое устройство 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 только что использовало назначенный DHCP DNS-сервер IPv4. В любом случае, разрешение локального имени хоста работает сейчас.
источник
Наконец-то я смог решить эту проблему, настроив в той же сети сам DHCP-сервер, который настраивает правильный домен поиска для отправки клиентам.
Когда-то у меня был сервер dhcp, в моем случае isc-dhcpd с конфигурацией в dhcp.conf:
Android смог разрешить локальные A-записи, установленные на моем DNS-сервере.
источник