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


14

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?


Przede wszystkim musisz oczywiście sprawdzić problem. Więc zainstaluj narzędzia IP ze Sklepu Play, zrób kilka nslookup i tak dalej, a wtedy dowiemy się więcej. Zwłaszcza korzystanie z serwera DNS, Nexusa, wyszukiwanie DNS i tak dalej. Wypróbuj narzędzia IP . Jest w języku polskim, ale oczywiście możesz to zmienić. Tego narzędzia używam w przypadku takich problemów.
mackowiakp

Hm W informacjach IP wyświetla poprawne adresy DNS. Podczas wyszukiwania DNS wyświetlany jest poprawny adres IP (192.168.1.15). Jednak karta Traceroute pokazuje nieprawidłowy publiczny adres IP (90.78.26.42).
Arseni Mourzenko

Tak więc - moim zdaniem - coś jest nie tak z wewnętrznym wpisem DNS dla Nexusa. Korzystam z podobnej konfiguracji i wszystko działa OK
mackowiakp

Wewnętrzny DNS działa dobrze na moim Nexusie 6p, Nexusie 5, Nexusie 10 itd. Czy próbowałeś flashować obrazy fabryczne na Nexusie 7 (jeśli jego bootloader jest odblokowany), aby upewnić się, że działa na nim znane oprogramowanie? (Zakładam, że go wykorzystałeś, ponieważ Nexus 7 nie jest nowym urządzeniem).
derobert

Kupiłem go z drugiej ręki, ale przed użyciem go zresetowałem, a następnie uaktualnienia do najnowszej wersji Androida. Myślę, że to wystarczy, aby upewnić się, że nie jest uruchomione żadne niestandardowe oprogramowanie, biorąc pod uwagę, że urządzenie nie jest zrootowane.
Arseni Mourzenko

Odpowiedzi:


5

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


Rzeczywiście, powinna to być również przyczyna w moim przypadku, ponieważ podobnie nie używam IPv6 wewnętrznie. Obejrzałem problem DNS, tworząc lokalny serwer VPN i prosząc urządzenie z Androidem o użycie VPN; to działa, ale jest oczywiście zbyt drastyczne.
Arseni Mourzenko

@ArseniMourzenko Czy kiedykolwiek rozwiązałeś ten problem? Dosłownie zmarnowałem dwa dni, nie robiąc nic innego, tylko próbując rozwiązać ten problem, ponieważ dosłownie zepsuł się wiele z tego, co wcześniej działało. I tak, wypróbowałem VPN, ale zmniejszyłem szybkość transferu ze 100 Mb / s do około 20
Michael

@Michael: ponieważ moje lokalne serwery DNS są skonfigurowane do obsługi tylko IPv4, odpowiedź Dimarc67 była dla mnie odpowiednia (dlatego też jest to oznaczone jako odpowiedź zaakceptowana). Stamtąd właśnie skonfigurowałem VPN dla wszystkich urządzeń z Androidem i od tego czasu cieszę się, że mogę z niego korzystać. Nie zauważyłem żadnego zmniejszenia szybkości transferu - nie obchodzi mnie to, biorąc pod uwagę sposób , w jaki korzystam z urządzeń mobilnych. Jeśli chodzi o wartość, używam OpenVPN po stronie serwera Debian, a OpenVPN Connect na urządzeniach z Androidem.
Arseni Mourzenko

2

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.


Wyłączenie IPV6 na moim routerze naprawiło problem na WSZYSTKICH moich urządzeniach z Androidem!
Ken J

2

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.