Чому 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 встановлені на статичні , а сервери 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 vs. Linksys) - модель WAP (Dell фірми Aruba Networks vs. 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, я дав технічним знанням, що ми не можемо використовувати її без можливості змінити підмережу локальної мережі. Він розумів, але не мав інформації, чому кабельний модем перешкоджає зміні. Тож він встановив модем заміни тієї самої моделі, що і раніше, який ми налаштували однаково, і відновлено доступ до Інтернету.

Ще день-два проходить, і служба знову знижується. Цього разу, коли я зателефонував до Comcast, початковий технік, з яким я розмовляв, задавав детальні та знаючі запитання щодо нашої конфігурації мережі. Коли я пояснив, що кабельний модем налаштований з локальною IP-адресою в нашій підмережі, він здавався цим спантеличеним. Він сказав, що більшість клієнтів Comcast підключають NAT'ing-маршрутизатор між кабельним модемом та локальною мережею, а не використовують NAT'ing кабельного модему. Насправді він сказав, що не знає, що кабельний модем підтримує NAT'ing.

Comcast надіслав ще одну техніку з абсолютно новим кабельним модемом (остання модель, яка не підтримує зміну підмережі LAN). Він провів обширну перевірку існуючого модему і нарешті визначив, що він передає лише трафік IPv6 - немає IPv4. Він також підтвердив те, що сказав телефонний телефон - що рекомендується використовувати окремий маршрутизатор для NAT'ing, а також не змінювати підмережу локальної мережі на кабельному модемі (чого ми не можемо робити на нових модемах зараз).

І ось ми нарешті прийшли до зміни мережі, яку ми зробили. Я встановив простий маршрутизатор LinkSys між кабельним модемом та нашим основним маршрутизатором, налаштованим на нашому статичному IP-адресі на стороні модема та локальній IP-адресі з внутрішньої сторони. Потім послуга Інтернету була відновлена ​​і деякий час залишається стабільною.

Після відновлення послуги в Інтернеті я подумав про дивацтво випуску IPv6 з кабельним модемом, що в свою чергу нагадало мені про проблему Android v5. Потім я перевірив наші пристрої Android в офісі і був приголомшений тим, що проблема з DNS більше не виникає.

Додавання маршрутизатора LinkSys для NAT'ing - це ТІЛЬКА ЗМІНА МЕРЕЖІ, яку ми зробили. Збіг ?? Можливо, але це виглядало трохи незвично, що обидва були пов'язані з 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 (порт 53 TCP / UDP) на мій локальний сервер DNS. Це було раніше, ніж вимкнути рекламу маршрутизатора на серверах DNS IPv6, тому я не знаю, чи повертається Android 5.0+ на сервери DNS Google (як стверджується в попередній відповіді), і я зрозумів їх своїм правилом DNAT або чи мій Android Пристрій 6.0 щойно використав DHCP, призначений сервером DNS IPv4. Так чи інакше, локальна роздільна здатність імені хоста працює зараз.

Нарешті мені вдалося вирішити це, встановивши сервер DHCP в тій самій мережі, яка налаштовує правильний пошуковий домен для надсилання клієнтам.

Як тільки у мене був сервер dhcp, у моєму випадку isc-dhcpd з конфігурацією в dhcp.conf:

option domain-name "myrealdomain.tld";

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