Tengo un comportamiento muy extraño en un dispositivo Android (Nexus 7) cuando intento acceder a las aplicaciones de red locales. En lugar de obtener la IP real de la máquina en LAN, el dispositivo Android obtiene la IP pública , lo que significa que Chrome, Firefox o cualquier otro navegador simplemente muestra la página web del enrutador.
Tengo un servidor DNS interno que maneja las redes locales. Hacer pingdesde una PC funciona correctamente:
$ 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
En un dispositivo HTC One (al que se accede con adb shell), también funciona bien:
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
Sin embargo, esto es lo que obtengo al hacer lo mismo pingdesde 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
En lugar de resolver a la IP interna, se resuelve a la pública.
La configuración de red es, excepto la dirección IP del dispositivo, exactamente la misma en ambos dispositivos: la configuración de IP se establece en Estática y los servidores DNS son los internos. Ambos dispositivos Android están conectados a través de Wi-Fi (a diferencia de la PC). Sin embargo, una diferencia importante es que Nexus 7 usa Android 6.0.1, mientras que HTC One usa Android 5.0.2.
No hay nm-tool, digo nslookupen Nexus 7. El dispositivo no está rooteado.
El problema existía desde que compré el dispositivo hace unas semanas, por lo que difícilmente podría ser el problema con la caché de DNS.
¿Qué puedo hacer para seguir inspeccionando este problema?
fuente
Respuestas:
Recientemente encontramos este problema y lo redujimos a que ocurra SOLO en dispositivos con Android v5 y versiones posteriores. Android v4 y todos los demás sistemas operativos no tienen ningún problema.
Con ese tidbit, determinamos que Android v5 y versiones posteriores insisten en usar IPv6 para la resolución de nombres DNS. (Dado que hemos deshabilitado completamente IPv6 en nuestra red, esto concuerda con el problema). Si Android v5 (+) no puede obtener una respuesta IPv6 del DNS local, entonces llega al host de nombre público de Google (8.8.8.8) . Por lo tanto, no hay DNS interno, solo externo.
Trabajamos alrededor del problema creando registros DNS en nuestros servidores DNS públicos para nombres internos e IP seleccionados. Una vez hecho esto, el DNS público de Google podría resolver estos nombres internos con IP internas, y los dispositivos podrían llegar a nuestros hosts internos.
Estamos procediendo a habilitar completamente IPv6 en nuestros servidores DNS internos (controladores de dominio) como una solución permanente.
=========================================
ACTUALIZACIÓN: Bueno, resulta que esto puede ser un arenque rojo total ... o no. Mi red doméstica es Win2008R2, dominio único con DHCP y DNS y sin enlace IPv6. Probé un dispositivo Android v5 desde allí y NO TENGO NINGÚN PROBLEMA. La red de Office con problema es Win2012 (no R2), dominio único.
Eludió los WAP actuales de la oficina con el WAP de Linksys independiente y el SSID separado para las pruebas, el problema persiste.
Diferencias entre las redes domésticas y de oficina (en las que puedo pensar): - Versión de Windows - 2012 vs. 2008 R2 - modelo de enrutador (Cisco vs. Linksys) - Modelo WAP (Aruba Networks vs. Linksys de la marca Dell)
Continuando con cualquier otra prueba que se me ocurra para acotar el problema. Cualquier sugerencia o entrada es muy apreciada!
=========================================
PROBLEMA IDO (?!)
Nuestro problema pareció desaparecer por sí solo luego de un cambio en la topología de la red que no creo que esté relacionado, pero aquí está la información por si acaso.
(ENORMES DISCULPAS por esta larga y larga historia, pero es cuando nuestros problemas con Android desaparecieron, así que resuélvelo si puedes. Probablemente estoy proporcionando muchos detalles aquí, pero porque no puedo ver una conexión directa, Estoy exponiendo todo exactamente como sucedió).
Nuestro ISP es Comcast Business Class: un módem de cable con un bloque de IP estático de cinco direcciones (número extraño, pero así es como Comcast las vende). El cable módem de Comcast es esencialmente una combinación de módem / firewall / enrutador / conmutador, con nuestro bloque de IP estático programado de forma remota.
Durante más de 10 años y casi la misma cantidad de empleadores, siempre he construido redes de oficina de la misma manera:
configure una IP LAN para el módem / enrutador ISP, que el tráfico de NAT desde Internet. No podría ser más simple, y así es como mi red de oficina actual se ha configurado durante cuatro años.
Recientemente nuestro servicio de internet de la oficina se cayó. Por lo general, un reinicio del módem lo corrige, pero cuando no lo hizo, llamamos a Comcast, que envió un técnico, que reemplazó el módem por cable para restaurar el servicio.
Unos días después, volvió a ocurrir lo mismo. Llamamos nuevamente, y la tecnología en el sitio (tecnología diferente a la anterior) intentó reemplazar el módem nuevamente, esta vez con un modelo más nuevo. Sorprendentemente, el cable módem más nuevo no admitía el cambio de la dirección de subred LAN. La subred predeterminada es 10.1.10.0/24 y no se puede cambiar. (Solo el 4to octeto era configurable). Como nuestra subred de la oficina es 192.168.100.0/24, le hice saber al técnico que no podíamos usarla sin poder cambiar la subred LAN. Él entendió, pero no tenía información sobre por qué el cable módem evitaría el cambio. Entonces instaló un módem de reemplazo del mismo modelo que antes, que configuramos de manera idéntica, y se restableció el acceso a Internet.
Otro día o dos pases, y el servicio vuelve a caer. Esta vez, cuando llamé a Comcast, la tecnología inicial con la que hablé me hizo preguntas detalladas y bien informadas sobre nuestra configuración de red. Cuando le expliqué que el módem de cable estaba configurado con una IP de LAN en nuestra subred, pareció desconcertado por esto. Dijo que la mayoría de los clientes de Comcast conectan un enrutador NAT entre el módem por cable y la LAN en lugar de usar el enrutador NAT del módem por cable. De hecho, dijo que no sabía que el módem por cable soportaba NAT'ing.
Comcast envió otra tecnología con un nuevo cable módem (último modelo que no admite el cambio de la subred LAN). Hizo pruebas exhaustivas en el módem existente y finalmente determinó que solo estaba pasando tráfico IPv6, no IPv4. También confirmó lo que dijo la tecnología del teléfono: que se recomienda usar un enrutador separado para NAT y no cambiar la subred LAN en el módem de cable (lo que no podemos hacer en los módems más nuevos de todos modos ahora).
Y ahora finalmente llegamos al cambio de red que hicimos. Instalé un enrutador LinkSys simple entre el módem de cable y nuestro enrutador central, configurado con nuestra IP estática en el lado del módem y una IP LAN en el interior. El servicio de Internet fue restaurado y se ha mantenido estable por algún tiempo.
Después de que se restableció el servicio de Internet, pensé en la rareza del problema de IPv6 con el módem de cable, que a su vez me recordó el problema de Android v5. Luego probé nuestros dispositivos Android en la oficina y me sorprendió ver que el problema de DNS ya no ocurría.
Agregar el enrutador LinkSys para NAT es el ÚNICO CAMBIO DE RED QUE HICIMOS. ¿¿Coincidencia?? Posiblemente, pero parecía un poco peculiar que ambos estuvieran relacionados con IPv6.
De todos modos, perdón por la larga historia, pero nuestro problema con Android se ha ido. Haz lo que puedas de ella.
Dimarc67
fuente
Encontré esta publicación mientras intentaba que mi dispositivo Android 6.0 utilizara el servidor DNS configurado localmente para resolver los nombres de host locales. Una respuesta anterior indicó que Android 5.0 y versiones posteriores insisten en usar servidores DNS IPv6. Esta fue la pista que me llevó a mi solución.
Mi enrutador anunciaba los servidores DNS IPv6 proporcionados por mi ISP utilizando DHCP-PD. Reconfiguré mi enrutador para dejar de anunciar los servidores DNS IPv6 y ahora el dispositivo Android 6.0 está resolviendo el nombre de host local utilizando el servidor DNS IPv4 proporcionado por DHCP (IPv4).
También tengo un DNAT para redirigir todas las consultas DNS (puerto TCP / UDP 53) a mi servidor DNS local. Esto estaba en su lugar antes de deshabilitar el anuncio del enrutador con servidores DNS IPv6, por lo que no sé si Android 5.0+ recurre a los servidores DNS de Google (como se afirmó en la respuesta anterior) y los capturé con mi regla DNAT o si mi Android El dispositivo 6.0 acaba de utilizar el servidor DNS IPv4 asignado por DHCP. De cualquier manera, la resolución del nombre de host local está funcionando ahora.
fuente
Finalmente pude resolver esto configurando un servidor DHCP yo mismo en la misma red, que configura el dominio de búsqueda correcto para enviar a los clientes.
Una vez que tuve un servidor dhcp, en mi caso isc-dhcpd con la configuración en dhcp.conf:
Android pudo resolver los registros A locales establecidos en mi servidor DNS.
fuente