Perché Android rifiuta di risolvere i record DNS che puntano a indirizzi IP interni?


14

Ho un comportamento molto strano su un dispositivo Android (Nexus 7) quando provo ad accedere alle applicazioni di rete locale. Invece di ottenere l'IP effettivo della macchina sulla LAN, il dispositivo Android ottiene l' IP pubblico , il che significa che Chrome, Firefox o qualsiasi altro browser mostra semplicemente la pagina Web del router.

Ho un server DNS interno che gestisce le reti locali. Fare pingda un PC funziona correttamente:

$ 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

Su un dispositivo HTC One (accessibile con adb shell), funziona anche bene:

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

Tuttavia, questo è ciò che ottengo facendo lo stesso pingda 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

Invece di risolvere l'IP interno, si risolve in quello pubblico.

La configurazione di rete è — tranne l'indirizzo IP del dispositivo — esattamente la stessa su entrambi i dispositivi: le impostazioni IP sono impostate su Statico e i server DNS sono quelli interni. Entrambi i dispositivi Android sono collegati tramite Wi-Fi (a differenza del PC). Una grande differenza, tuttavia, è che Nexus 7 utilizza Android 6.0.1, mentre HTC One utilizza Android 5.0.2.

No nm-tool, digo nslookupsu Nexus 7. Il dispositivo non è rootato.

Il problema esisteva da quando ho acquistato il dispositivo poche settimane fa, quindi potrebbe non essere il problema con la cache DNS.

Cosa posso fare per esaminare ulteriormente questo problema?


Prima di tutto devi ovviamente ispezionare il problema. Quindi, installa IP Tools dal Play Store, crea alcuni nslookup e così via e di quanto ne sapremo di più. Soprattutto l'utilizzo del server DNS Nexus, la ricerca DNS e così via. Prova questo IP Tools . È in lingua polacca ma ovviamente puoi cambiarlo. Questo strumento che uso in caso di tali problemi.
mackowiakp,

Hm. In Informazioni IP , visualizza gli indirizzi DNS corretti. Nella ricerca DNS , viene mostrato l'IP corretto (192.168.1.15). Tuttavia, la scheda Traceroute mostra un IP pubblico errato (90.78.26.42).
Arseni Mourzenko,

Quindi - a mio avviso - c'è qualcosa di sbagliato nella voce DNS interna per Nexus. Uso una configurazione simile e tutto funziona bene
mackowiakp

Il DNS interno funziona perfettamente sul mio Nexus 6p, Nexus 5, Nexus 10, ecc. Hai provato a eseguire il flashing delle immagini di fabbrica sul Nexus 7 (se il suo bootloader è sbloccato) per assicurarti che stia eseguendo un software noto? (Suppongo che tu l'abbia usato, dato che il Nexus 7 non è un nuovo dispositivo).
derobert,

L'ho acquistato di seconda mano, ma ho effettuato un ripristino prima di utilizzarlo, seguito dagli aggiornamenti all'ultima versione di Android. Immagino che questo sia sufficiente per garantire che non stia eseguendo alcun software personalizzato, dato che il dispositivo non è rootato.
Arseni Mourzenko,

Risposte:


5

Di recente abbiamo riscontrato questo problema e lo abbiamo limitato a verificarsi SOLO sui dispositivi con Android v5 e versioni successive. Android v4 e tutti gli altri sistemi operativi non hanno alcun problema.

Con questa informazione, abbiamo stabilito che Android v5 e le versioni successive insistono sull'uso di IPv6 per la risoluzione dei nomi DNS. (Dal momento che abbiamo completamente disabilitato IPv6 sulla nostra rete, questo si snoda con il problema.) Se Android v5 (+) non può ottenere una risposta IPv6 dal DNS locale, raggiunge l'host di nomi pubblici di Google (8.8.8.8) . Quindi, nessun DNS interno, solo esterno.

Abbiamo risolto il problema creando record DNS sui nostri server DNS rivolti al pubblico per selezionare nomi e IP interni. Fatto ciò, il DNS pubblico di Google potrebbe risolvere questi nomi interni con IP interni e i dispositivi potrebbero quindi raggiungere i nostri host interni.

Stiamo procedendo con l'abilitazione completa di IPv6 sui nostri server DNS interni (controller di dominio) come soluzione permanente.

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

AGGIORNAMENTO-- Beh, si scopre che potrebbe essere un'aringa rossa totale ... o no. La mia rete domestica è Win2008R2, dominio singolo con DHCP e DNS e nessun binding IPv6. Testato un dispositivo Android v5 da lì e non ha avuto problemi. La rete di Office con problema è Win2012 (non R2), dominio singolo.

Bypassato l'attuale WAP dell'ufficio con Linksys autonomo WAP e SSID separato per i test, il problema persiste.

Differenze tra reti domestiche e di ufficio (che mi viene in mente): - Versione di Windows - 2012 vs 2008 R2 - Modello di router (Cisco vs. Linksys) - Modello WAP (Aruba Networks con marchio Dell vs. Linksys)

Procedendo con qualsiasi ulteriore test mi venga in mente per restringere il problema. Qualsiasi suggerimento o input è estremamente apprezzato!

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

PROBLEMA ANDATO (?!)

Il nostro problema sembrava scomparire da solo a seguito di una modifica della topologia di rete che non pensavo fosse correlata, ma ecco le informazioni nel caso.

(ENORMI APOLOGIE per questa lunga storia elaborata, ma è qui che sono scomparsi i nostri problemi con Android, quindi prova questo se puoi. Probabilmente sto fornendo troppi dettagli qui, ma poiché non riesco a vedere una connessione diretta, Sto spiegando tutto esattamente come è successo.)

Il nostro ISP è Comcast Business Class, un modem via cavo con un blocco IP statico di cinque indirizzi (numero strano ma è così che Comcast li vende). Il modem via cavo di Comcast è essenzialmente una combinazione modem / firewall / router / switch, con il nostro blocco IP statico programmato da remoto in esso.

Per oltre 10 anni e quasi altrettanti datori di lavoro, ho sempre costruito reti di uffici allo stesso modo:
configura un IP LAN per il modem / router ISP, che il traffico NAT da Internet. Non potrebbe essere più semplice, ed è così che la mia attuale rete dell'ufficio è stata configurata per quattro anni.

Recentemente il nostro servizio Internet dell'ufficio è andato in fumo. Di solito un riavvio del modem lo corregge, ma quando non lo facevamo abbiamo chiamato Comcast che ha inviato un tecnico, che ha sostituito il modem via cavo per ripristinare il servizio.

Pochi giorni dopo, è successa la stessa cosa. Abbiamo chiamato di nuovo e la tecnologia in loco (tecnologia diversa da prima) ha tentato di sostituire nuovamente il modem, questa volta con un modello più recente. Sorprendentemente, il modem via cavo più recente non supportava la modifica dell'indirizzo della sottorete LAN. La sottorete predefinita è 10.1.10.0/24 e non può essere modificata. (Solo il 4 ° ottetto era configurabile.) Dato che la nostra sottorete dell'ufficio è 192.168.100.0/24, ho fatto sapere alla tecnologia che non potevamo usarla senza poter cambiare la sottorete LAN. Ha capito, ma non aveva informazioni sul perché il modem via cavo avrebbe impedito il cambiamento. Quindi ha installato un modem sostitutivo dello stesso modello di prima, che abbiamo configurato in modo identico, e l'accesso a Internet è stato ripristinato.

Passano un altro giorno o due e il servizio si interrompe nuovamente. Questa volta, quando ho chiamato Comcast, la tecnologia iniziale con cui ho parlato ha posto domande dettagliate e ben informate sulla nostra configurazione di rete. Quando ho spiegato che il modem via cavo era configurato con un IP LAN sulla nostra sottorete, mi sembrava perplesso. Ha affermato che la maggior parte dei clienti di Comcast collega un router NAT tra il modem via cavo e la LAN anziché utilizzare il NAT del modem via cavo. In realtà, ha detto di non essere a conoscenza del fatto che il modem via cavo supportasse NAT'ing.

Comcast ha inviato un'altra tecnologia con un modem via cavo nuovo di zecca (ultimo modello che non supporta la modifica della sottorete LAN). Ha effettuato test approfonditi sul modem esistente e alla fine ha stabilito che stava solo passando il traffico IPv6, nessun IPv4. Ha anche confermato ciò che aveva detto la tecnologia del telefono: che si consiglia di utilizzare un router separato per NAT e di non modificare la sottorete LAN sul modem via cavo (cosa che ora non possiamo fare con i modem più recenti).

E ora finalmente arriviamo al cambiamento di rete che abbiamo fatto. Ho installato un semplice router LinkSys tra il modem via cavo e il nostro router principale, configurato con il nostro IP statico sul lato modem e un IP LAN all'interno. Il servizio Internet è stato quindi ripristinato ed è rimasto stabile da qualche tempo.

Dopo il ripristino del servizio Internet, ho pensato alla stranezza del problema IPv6 con il modem via cavo, che a sua volta mi ha ricordato il problema di Android v5. Ho quindi testato i nostri dispositivi Android in ufficio e sono rimasto sbalordito nel vedere che il problema DNS non si verificava più.

L'aggiunta del router LinkSys per NAT è l'UNICO CAMBIO DI RETE CHE ABBIAMO EFFETTUATO. Coincidenza?? Forse, ma sembrava un po 'strano che entrambi fossero correlati a IPv6.

Comunque, scusami ancora per la lunga storia, ma il nostro problema con Android è sparito. Crea ciò che puoi da esso.

Dimarc67


In effetti, questa dovrebbe essere la causa anche nel mio caso, poiché, allo stesso modo, non uso IPv6 internamente. Ho aggirato il problema DNS creando un server VPN locale e chiedendo al dispositivo Android di usare VPN; funziona, ma ovviamente è troppo drastico.
Arseni Mourzenko,

@ArseniMourzenko Hai mai risolto questo problema? Ho letteralmente perso due giorni senza fare nient'altro che cercare di risolvere questo problema, poiché ha letteralmente rotto molto di ciò che funzionava in precedenza. E sì, ho provato una VPN ma ha ridotto la velocità di trasferimento da 100 Mbps + a circa 20
Michael,

@Michael: poiché i miei server DNS locali sono configurati per supportare solo IPv4, la risposta di Dimarc67 è stata rilevante per me (anche per questo è contrassegnata come risposta accettata). Da lì, ho appena impostato una VPN per tutti i dispositivi Android e da allora sono felice di usarla. Non ho notato alcuna riduzione della velocità di trasferimento, non mi importerebbe, dato il modo in cui utilizzo i dispositivi mobili. Per quello che vale, sto usando OpenVPN sul lato server Debian e OpenVPN Connect su dispositivi Android.
Arseni Mourzenko,

2

Mi sono imbattuto in questo post durante il tentativo di ottenere il mio dispositivo Android 6.0 per utilizzare il server DNS configurato localmente per risolvere i nomi host locali. Una risposta sopra ha indicato che Android 5.0 e versioni successive insistono sull'uso dei server DNS IPv6. Questo è stato l'indizio che mi ha portato alla mia soluzione.

Il mio router pubblicizzava i server DNS IPv6 forniti dal mio ISP utilizzando DHCP-PD. Ho riconfigurato il mio router per interrompere la pubblicità dei server DNS IPv6 e ora il dispositivo Android 6.0 sta risolvendo il nome host locale utilizzando il server DNS IPv4 fornito da DHCP (IPv4).

Ho anche un DNAT per reindirizzare tutte le query DNS (porta TCP / UDP 53) sul mio server DNS locale. Questo era in atto prima di disabilitare la pubblicità del router con i server DNS IPv6, quindi non so se Android 5.0+ ricada sui server DNS di Google (come affermato nella risposta precedente) e li ho rilevati con la mia regola DNAT o se il mio Android Il dispositivo 6.0 ha appena utilizzato il server DNS IPv4 assegnato da DHCP. In entrambi i casi, la risoluzione del nome host locale funziona ora.


La disabilitazione di IPV6 sul mio router ha risolto il problema su TUTTI i miei dispositivi Android!
Ken J,

2

Sono stato finalmente in grado di risolverlo configurando un server DHCP sulla stessa rete, il che configura il dominio di ricerca corretto da inviare ai client.

Una volta avevo un server dhcp, nel mio caso isc-dhcpd con la configurazione in dhcp.conf:

option domain-name "myrealdomain.tld";

Android è stato in grado di risolvere i record A locali impostati nel mio server DNS.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.