У меня очень странное поведение на устройстве 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.
Что я могу сделать для дальнейшего изучения этой проблемы?
Недавно мы столкнулись с этой проблемой и сузили ее до ТОЛЬКО на устройствах под управлением 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
Я наткнулся на этот пост, пытаясь заставить свое устройство 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. В любом случае, разрешение локального имени хоста теперь работает.
В конце концов я смог решить эту проблему, самостоятельно настроив DHCP-сервер в той же сети, который настраивает правильный домен поиска для отправки клиентам.
Когда-то у меня был dhcp-сервер, в моем случае isc-dhcpd с конфигурацией в dhcp.conf:
option domain-name "myrealdomain.tld";
Android смог разрешить локальные A-записи, установленные на моем DNS-сервере.
Маковиакп
Арсений Мурзенко
Маковиакп
Дероберт
Арсений Мурзенко
Майкл