Ich habe ein sehr seltsames Verhalten auf einem Android-Gerät (Nexus 7), wenn ich versuche, auf lokale Netzwerkanwendungen zuzugreifen. Anstatt die tatsächliche IP der Maschine im LAN zu erhalten, erhält das Android-Gerät die öffentliche IP, was bedeutet, dass Chrome, Firefox oder jeder andere Browser einfach die Webseite des Routers anzeigt.
Ich habe einen internen DNS-Server, der die lokalen Netzwerke verwaltet. Von einem PC pingaus funktioniert es richtig:
$ 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
Auf einem HTC One-Gerät (Zugriff mit adb shell) funktioniert es auch gut:
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
Dies ist jedoch das, was ich bekomme, wenn ich dasselbe pingvon Nexus 7 aus mache:
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
Anstatt zur internen IP aufzulösen, wird zur öffentlichen aufgelöst.
Die Netzwerkkonfiguration ist – bis auf die IP-Adresse des Geräts – auf beiden Geräten exakt gleich: IP-Einstellungen sind auf Statisch eingestellt , DNS-Server sind die internen. Beide Android-Geräte sind (im Gegensatz zum PC) über Wi-Fi verbunden. Ein wesentlicher Unterschied besteht jedoch darin, dass Nexus 7 Android 6.0.1 verwendet, während HTC One Android 5.0.2 verwendet.
Auf Nexus 7 gibt es kein nm-tool, digoder nslookup. Das Gerät ist nicht gerootet.
Das Problem bestand seit ich das Gerät vor ein paar Wochen gekauft habe, also kann es wohl kaum am DNS-Cache liegen.
Was kann ich tun, um dieses Problem weiter zu untersuchen?
Wir sind kürzlich auf dieses Problem gestoßen und haben es auf NUR auf Geräten mit Android v5 und höher eingegrenzt. Android v4 und alle anderen Betriebssysteme haben kein Problem.
Mit diesem Leckerbissen haben wir festgestellt, dass Android v5 und neuer darauf besteht, IPv6 für die DNS-Namensauflösung zu verwenden. (Da wir IPv6 in unserem Netzwerk vollständig deaktiviert haben, stimmt dies mit dem Problem überein.) Wenn Android v5(+) keine IPv6-Antwort vom lokalen DNS erhalten kann, erreicht es den Host mit öffentlichem Namen von Google (8.8.8.8). . Also kein internes DNS, nur extern.
Wir haben das Problem umgangen, indem wir DNS-Einträge auf unseren öffentlich zugänglichen DNS-Servern für ausgewählte interne Namen und IPs erstellt haben. Damit könnte das öffentliche DNS von Google diese internen Namen mit internen IPs auflösen, und die Geräte könnten dann unsere internen Hosts erreichen.
Wir fahren mit der vollständigen Aktivierung von IPv6 auf unseren internen DNS-Servern (Domänencontrollern) als dauerhafte Lösung fort.
=======================================
UPDATE – Nun, es stellt sich heraus, dass dies ein totaler Ablenkungsmanöver sein könnte … oder auch nicht. Mein Heimnetzwerk ist Win2008R2, Einzeldomäne mit DHCP und DNS und ohne IPv6-Bindung. Getestet ein Android v5-Gerät von dort und hatte KEIN PROBLEM. Das Büronetzwerk mit dem Problem ist Win2012 (nicht R2), Einzeldomäne.
Aktuelle Büro-WAPs mit eigenständigem Linksys WAP und separater SSID zum Testen umgangen, Problem bleibt bestehen.
Unterschiede zwischen Büro- und Heimnetzwerken (die mir einfallen): - Windows-Version - 2012 vs. 2008 R2 - Routermodell (Cisco vs. Linksys) - WAP-Modell (Aruba Networks der Marke Dell vs. Linksys)
Fahren Sie mit allen weiteren Tests fort, die mir einfallen, um das Problem einzugrenzen. Alle Vorschläge oder Eingaben werden sehr geschätzt!
=======================================
PROBLEM WEG (?!)
Unser Problem schien nach einer Änderung der Netzwerktopologie von selbst zu verschwinden, von der ich nicht glauben würde, dass sie damit zusammenhängt, aber hier sind die Informationen für den Fall.
(RIESIGE ENTSCHULDIGUNGEN für diese lange, langwierige Geschichte, aber zu diesem Zeitpunkt verschwanden unsere Android-Probleme, also lass das, wenn du kannst. Ich liefere hier wahrscheinlich VIEL zu viele Details, aber da ich keine direkte Verbindung erkennen kann, Ich lege alles genau so dar, wie es passiert ist.)
Unser ISP ist Comcast Business Class – ein Kabelmodem mit einem statischen IP-Block von fünf Adressen (seltsame Zahl, aber so verkauft Comcast sie). Das Kabelmodem von Comcast ist im Wesentlichen eine Kombination aus Modem/Firewall/Router/Switch, in die unser statischer IP-Block fernprogrammiert ist.
Seit mehr als 10 Jahren und fast ebenso vielen Arbeitgebern habe ich Büronetzwerke immer auf die gleiche Weise aufgebaut:
Konfigurieren Sie eine LAN-IP für das ISP-Modem/Router, das den NAT-Datenverkehr aus dem Internet leitet. Einfacher geht es nicht, und so ist mein aktuelles Büronetzwerk seit vier Jahren konfiguriert.
Kürzlich fiel unser Bürointernetdienst aus. Normalerweise wird es durch einen Neustart des Modems behoben, aber wenn dies nicht der Fall war, riefen wir Comcast an, das einen Techniker schickte, der das Kabelmodem ersetzte, um den Dienst wiederherzustellen.
Ein paar Tage später passierte das gleiche wieder. Wir riefen erneut an, und der Techniker vor Ort (ein anderer Techniker als zuvor) versuchte erneut, das Modem zu ersetzen, diesmal durch ein neueres Modell. Überraschenderweise unterstützte das neuere Kabelmodem das Ändern der LAN-Subnetzadresse nicht. Das Standardsubnetz ist 10.1.10.0/24 und kann nicht geändert werden. (Nur das 4. Oktett war konfigurierbar.) Da unser Büro-Subnetz 192.168.100.0/24 ist, ließ ich den Techniker wissen, dass wir es nicht verwenden konnten, ohne das LAN-Subnetz ändern zu können. Er verstand, hatte aber keine Informationen darüber, warum das Kabelmodem die Änderung verhindern würde. Also installierte er ein Ersatzmodem des gleichen Modells wie zuvor, das wir identisch konfigurierten, und der Internetzugang war wiederhergestellt.
Ein oder zwei weitere Tage vergehen, und der Service fällt wieder aus. Als ich dieses Mal Comcast anrief, stellte der erste Techniker, mit dem ich sprach, detaillierte und sachkundige Fragen zu unserer Netzwerkkonfiguration. Als ich erklärte, dass das Kabelmodem mit einer LAN-IP in unserem Subnetz konfiguriert war, schien er darüber verwirrt zu sein. Er sagte, dass die meisten Comcast-Kunden einen NAT-Router zwischen dem Kabelmodem und dem LAN anschließen, anstatt das NAT des Kabelmodems zu verwenden. Tatsächlich sagte er, er wisse nicht, dass das Kabelmodem NAT unterstütze.
Comcast schickte einen anderen Techniker mit einem brandneuen Kabelmodem (neuestes Modell, das den Wechsel des LAN-Subnetzes nicht unterstützt). Er führte umfangreiche Tests mit dem vorhandenen Modem durch und stellte schließlich fest, dass es nur IPv6-Verkehr durchließ – keinen IPv4. Er bestätigte auch, was der Telefontechniker gesagt hatte – dass es empfohlen wird, einen separaten Router für NAT zu verwenden und das LAN-Subnetz auf dem Kabelmodem nicht zu ändern (was wir bei den neueren Modems jetzt sowieso nicht tun können).
Und jetzt kommen wir endlich zu unserem Netzwerkwechsel. Ich habe einen einfachen LinkSys-Router zwischen dem Kabelmodem und unserem Core-Router installiert, konfiguriert mit unserer statischen IP auf der Modemseite und einer LAN-IP auf der Innenseite. Der Internetdienst wurde dann wiederhergestellt und ist seit einiger Zeit stabil.
Nachdem der Internetdienst wiederhergestellt war, dachte ich über die Seltsamkeit des IPv6-Problems mit dem Kabelmodem nach, was mich wiederum an das Problem mit Android v5 erinnerte. Ich habe dann unsere Android-Geräte im Büro getestet und war fassungslos, als ich feststellte, dass das DNS-Problem nicht mehr auftrat.
Das Hinzufügen des LinkSys-Routers für NAT'ing ist die EINZIGE NETZWERKÄNDERUNG, DIE WIR VORGENOMMEN HABEN. Zufall?? Möglich, aber es schien nur ein wenig seltsam, dass beide mit IPv6 verwandt waren.
Wie auch immer, nochmals Entschuldigung für die lange Geschichte, aber unser Android-Problem ist weg. Machen Sie daraus, was Sie können.
Dimarc67
Ich bin auf diesen Beitrag gestoßen, als ich versuchte, mein Android 6.0-Gerät dazu zu bringen, den lokal konfigurierten DNS-Server zum Auflösen lokaler Hostnamen zu verwenden. Eine Antwort oben deutete darauf hin, dass Android 5.0 und neuer auf der Verwendung von IPv6-DNS-Servern besteht. Das war der Hinweis, der mich zu meiner Lösung führte.
Mein Router hat die von meinem ISP bereitgestellten IPv6-DNS-Server mit DHCP-PD angekündigt. Ich habe meinen Router neu konfiguriert, um die Werbung für die IPv6-DNS-Server zu stoppen, und jetzt löst das Android 6.0-Gerät den lokalen Hostnamen mithilfe des von DHCP (IPv4) bereitgestellten IPv4-DNS-Servers auf.
Ich habe auch einen DNAT, um alle DNS-Anfragen (TCP/UDP-Port 53) auf meinen lokalen DNS-Server umzuleiten. Dies war vorhanden, bevor die Router-Werbung mit IPv6-DNS-Servern deaktiviert wurde, sodass ich nicht weiß, ob Android 5.0+ auf die Google-DNS-Server zurückgreift (wie in der vorherigen Antwort behauptet) und ich sie mit meiner DNAT-Regel oder ob mein Android erwischt habe 6.0-Gerät hat nur den von DHCP zugewiesenen IPv4-DNS-Server verwendet. In jedem Fall funktioniert die lokale Hostnamenauflösung jetzt.
Ich konnte dies schließlich lösen, indem ich selbst einen DHCP-Server im selben Netzwerk einrichtete, der die richtige Suchdomäne konfiguriert, die an die Clients gesendet wird.
Einmal hatte ich einen DHCP-Server, in meinem Fall isc-dhcpd mit der Konfiguration in dhcp.conf:
option domain-name "myrealdomain.tld";
Android konnte lokale A-Einträge auflösen, die in meinem DNS-Server festgelegt wurden.
mackowiakp
Arseni Murzenko
mackowiakp
derobert
Arseni Murzenko
Michael