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