Dlaczego Android odmawia rozpoznania rekordów DNS wskazujących na wewnętrzne adresy IP?

Mam bardzo dziwne zachowanie na urządzeniu z Androidem (Nexus 7) podczas próby uzyskania dostępu do aplikacji sieci lokalnej. Zamiast rzeczywistego adresu IP urządzenia w sieci LAN urządzenie z Androidem otrzymuje publiczny adres IP, co oznacza, że ​​Chrome, Firefox lub dowolna inna przeglądarka po prostu pokazuje stronę internetową routera.

Mam wewnętrzny serwer DNS, który obsługuje sieci lokalne. Wykonanie pingz komputera działa poprawnie:

$ 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

Na urządzeniu HTC One (dostępnym z adb shell) działa również dobrze:

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

Jednak to właśnie otrzymuję, gdy robię to samo pingz Nexusem 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

Zamiast rozstrzygać na wewnętrzny adres IP, zmienia się na publiczny.

Konfiguracja sieci jest - z wyjątkiem adresu IP urządzenia - dokładnie taka sama na obu urządzeniach: ustawienia IP są ustawione na Statyczne , a serwery DNS są wewnętrzne. Oba urządzenia z Androidem są połączone przez Wi-Fi (w przeciwieństwie do komputera). Główną różnicą jest jednak to, że Nexus 7 używa Androida 6.0.1, podczas gdy HTC One używa Androida 5.0.2.

Nie ma nm-tool, digani nslookupna Nexusa 7. Urządzenie nie jest zakorzeniona.

Problem istniał od czasu zakupu urządzenia kilka tygodni temu, więc nie może być problemu z pamięcią podręczną DNS.

Co mogę zrobić, aby dalej sprawdzić ten problem?

Ostatnio napotkaliśmy ten problem i zawęziliśmy go do WYŁĄCZNIE na urządzeniach z Androidem V5 i nowszym. Android v4 i wszystkie inne systemy operacyjne nie mają problemu.

Dzięki tej ciekawostce ustaliliśmy, że system Android w wersji 5 i nowszych nalega na użycie protokołu IPv6 do rozpoznawania nazw DNS. (Ponieważ całkowicie wyłączyliśmy protokół IPv6 w naszej sieci, problem ten się zaciera). Jeśli Android v5 (+) nie może uzyskać odpowiedzi IPv6 z lokalnego DNS, wówczas dociera do hosta nazw publicznych Google (8.8.8.8) . Dlatego nie ma wewnętrznego DNS, tylko zewnętrzny.

Rozwiązaliśmy ten problem, tworząc rekordy DNS na publicznych serwerach DNS dla wybranych nazw wewnętrznych i adresów IP. Po wykonaniu tej czynności publiczny DNS Google może rozwiązać te wewnętrzne nazwy za pomocą wewnętrznych adresów IP, a następnie urządzenia mogą dotrzeć do naszych wewnętrznych hostów.

Kontynuujemy pełne włączenie IPv6 na naszych wewnętrznych serwerach DNS (kontrolerach domeny) jako stałą poprawkę.

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

AKTUALIZACJA - Okazuje się, że może to być całkowity czerwony śledź ... lub nie. Moja sieć domowa to Win2008R2, jednodomenowa z DHCP i DNS i bez powiązania IPv6. Przetestowałem stamtąd urządzenie z Androidem v5 i NIE ZADAŁEM. Problemem jest sieć Office Win2012 (inna niż R2), pojedyncza domena.

Obejście obecnego biura WAP z samodzielnym WAP Linksys i oddzielnym SSID do testowania, problem nadal występuje.

Różnice między sieciami biurowymi i domowymi (o których mogę myśleć): - wersja Windows - 2012 vs. 2008 R2 - model routera (Cisco vs. Linksys) - model WAP (Dell Aruba Networks vs. Linksys)

Kontynuując wszelkie dalsze testy, jakie mogę wymyślić, aby zawęzić problem. Wszelkie sugestie lub uwagi są bardzo mile widziane!

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

PROBLEM POZOSTAŁ (?!)

Wydaje się, że nasz problem zniknął sam po zmianie topologii sieci, o której nie sądzę, żeby był powiązany, ale oto informacje na wszelki wypadek.

(OGROMNE PRZEPROWADZKI za tę długą, wyciągniętą historię, ale wtedy zniknęły nasze problemy z Androidem, więc skorzystaj z niej, jeśli możesz. Prawdopodobnie podaję tutaj zbyt dużo szczegółów, ale ponieważ nie widzę bezpośredniego połączenia, Układam to wszystko dokładnie tak, jak to się stało.)

Nasz dostawca usług internetowych to Comcast Business Class - modem kablowy ze statycznym blokiem adresów IP składającym się z pięciu adresów (dziwna liczba, ale w ten sposób je sprzedaje Comcast). Modem kablowy Comcast jest zasadniczo kombinacją modemu / zapory ogniowej / routera / przełącznika, z naszym statycznym blokiem IP zaprogramowanym w nim zdalnie.

Przez ponad 10 lat i prawie tyle samo pracodawców zawsze budowałem sieci biurowe w ten sam sposób:
Skonfiguruj adres IP sieci LAN dla modemu / routera ISP, który generuje ruch NAT z Internetu. Nie może być prościej i tak właśnie konfiguruję moją obecną sieć biurową od czterech lat.

Ostatnio nasz serwis internetowy do pracy uległ awarii. Zwykle restart modemu naprawia to, ale kiedy nie zadzwoniliśmy do Comcast, który wysłał technika, który zastąpił modem kablowy, aby przywrócić usługę.

Kilka dni później to samo się powtórzyło. Zadzwoniliśmy ponownie, a technika na miejscu (inna technika niż wcześniej) próbowała ponownie wymienić modem, tym razem na nowszy model. Co zaskakujące, nowszy modem kablowy nie obsługiwał zmiany adresu podsieci LAN. Domyślna podsieć to 10.1.10.0/24 i nie można jej zmienić. (Tylko czwarty oktet był konfigurowalny.) Ponieważ nasza podsieć biurowa to 192.168.100.0/24, poinformowałem technologię, że nie możemy jej użyć bez możliwości zmiany podsieci LAN. Rozumiał, ale nie miał informacji, dlaczego modem kablowy miałby zapobiec tej zmianie. Zainstalował więc modem zastępczy tego samego modelu co poprzednio, który skonfigurowaliśmy identycznie i przywrócono dostęp do Internetu.

Kolejny dzień lub dwa mija, a usługa znów spada. Tym razem, gdy zadzwoniłem do Comcast, początkowa technologia, z którą rozmawiałem, zadała szczegółowe i kompetentne pytania dotyczące konfiguracji naszej sieci. Kiedy wyjaśniłem, że modem kablowy został skonfigurowany z adresem IP w sieci LAN w naszej podsieci, wydawało się to zaskoczone. Powiedział, że większość klientów Comcast łączy modem NAT pomiędzy modemem kablowym a siecią LAN, zamiast używać NAT'owania modemu kablowego. W rzeczywistości powiedział, że nie był świadomy, że modem kablowy obsługuje NAT.

Comcast wysłał kolejną technologię z zupełnie nowym modemem kablowym (najnowszy model, który nie obsługuje zmiany podsieci LAN). Przeprowadził szeroko zakrojone testy istniejącego modemu i ostatecznie stwierdził, że przepuszcza on tylko ruch IPv6 - bez IPv4. Potwierdził także to, co powiedział technik telefoniczny - że zaleca się używanie oddzielnego routera do NAT i nie zmieniać podsieci LAN w modemie kablowym (czego nie możemy teraz zrobić w nowszych modemach).

A teraz w końcu dochodzimy do dokonanej przez nas zmiany sieci. Zainstalowałem prosty router LinkSys między modemem kablowym a naszym routerem rdzeniowym, skonfigurowany z naszym statycznym adresem IP po stronie modemu i adresem IP sieci LAN wewnątrz. Serwis internetowy został przywrócony i od pewnego czasu pozostaje stabilny.

Po przywróceniu usługi internetowej pomyślałem o dziwności problemu IPv6 z modemem kablowym, co z kolei przypomniało mi problem z Androidem v5. Następnie przetestowałem nasze urządzenia z Androidem w biurze i byłem zaskoczony, widząc, że problem z DNSem już nie występuje.

Dodanie routera LinkSys do NAT jest JEDYNĄ ZMIANĄ SIECI. Zbieg okoliczności?? Być może, ale wydawało się to trochę dziwne, że oba były związane z IPv6.

W każdym razie przepraszam za długą historię, ale nasz problem z Androidem zniknął. Zrób z tego, co możesz.

Dimarc67

Natrafiłem na ten post, próbując przekonać moje urządzenie z Androidem 6.0 do używania lokalnie skonfigurowanego serwera DNS do rozpoznawania lokalnych nazw hostów. Jedna odpowiedź powyżej wskazuje, że Android 5.0 i nowsze wersje nalegają na używanie serwerów DNS IPv6. To była wskazówka, która doprowadziła mnie do mojego rozwiązania.

Mój router reklamował serwery DNS IPv6 dostarczone przez mojego dostawcę usług internetowych za pomocą DHCP-PD. Ponownie skonfigurowałem router, aby przestał reklamować serwery DNS IPv6, a teraz urządzenie z Androidem 6.0 rozwiązuje lokalną nazwę hosta za pomocą serwera DNS IPv4 dostarczonego przez DHCP (IPv4).

Mam również DNAT do przekierowania wszystkich zapytań DNS (port TCP / UDP 53) na mój lokalny serwer DNS. Miało to miejsce przed wyłączeniem reklamy routera z serwerami DNS IPv6, więc nie wiem, czy Android 5.0+ wraca do serwerów Google DNS (jak twierdzono w poprzedniej odpowiedzi) i złapałem je za pomocą mojej reguły DNAT lub czy mój Android Urządzenie 6.0 właśnie korzystało z przydzielonego DHCP serwera DNS IPv4. Tak czy inaczej, lokalne rozpoznawanie nazw hostów działa teraz.

W końcu udało mi się to rozwiązać, sam konfigurując serwer DHCP w tej samej sieci, który konfiguruje prawidłową domenę wyszukiwania do wysyłania do klientów.

Kiedyś miałem serwer dhcp, w moim przypadku isc-dhcpd z konfiguracją w dhcp.conf:

option domain-name "myrealdomain.tld";

Android był w stanie rozwiązać lokalne rekordy A ustawione na moim serwerze DNS.