As aplicacións non logran resolver un nome mentres o túnel segue conectado e todos os demais indicadores parecen sans. No móbil, a causa habitual é un resolutor elixido polo dispositivo e non polo perfil de VPN. Dous axustes poden reclamar cada un a autoridade sobre a mesma consulta. Averiguar cal gaña e se sequera pode responder á pregunta é máis rápido que tocar o túnel.

Dous axustes deciden o mesmo nome

O axuste Private DNS do móbil elixe un resolutor para o dispositivo, con modos que van da selección automática a un nome de host concreto. Un perfil de VPN pode impor o seu propio resolutor ao mesmo tempo, e os dous configúranse en pantallas distintas e por propietarios distintos. Ningún anula necesariamente o outro para cada aplicación. Por iso un túnel que funciona e unha consulta que falla conviven sen contradición.

O navegador pode engadir unha terceira capa, porque o DNS seguro dentro do navegador pode escoller o seu propio provedor. A aplicación que produciu o erro é a única guía fiable de cal dos tres respondeu. O resolutor tamén ten que poder responder. Un nome exclusivo da empresa non está nos datos dun resolutor público, así que a consulta falla polo contido e non pola conectividade.

Escolla o modo segundo os nomes que necesita

Se o dispositivo debe resolver nomes internos, o resolutor ten que ser un que conteña esas zonas, o que normalmente significa o resolutor do túnel ou un esquema de DNS dividido que a organización documente. Se só importan os nomes públicos, un resolutor cifrado estrito é unha opción defendible que ademais elimina as consultas en texto claro. A decisión despréndese dos nomes, non dunha preferencia sobre o cifrado.

O comportamento ante fallos tamén cambia segundo o modo. Unha elección estrita que non pode acadar o seu resolutor produce fallos para todos os nomes, mentres que un modo con retroceso permitido pode manter os nomes públicos funcionando e os internos rotos. Esa diferenza di en que modo está antes de abrir unha pantalla de axustes. Nun dispositivo xestionado decide a política aprobada e o usuario non pode anulala con seguridade. Nunha configuración persoal abonda unha comparación documentada para identificar o conflito, e o axuste de privacidade previsto debe restaurarse despois en lugar de deixalo desactivado.

Comprobe que aplicación pregunta

Reproduza o fallo na aplicación que o notificou e anote se o erro é de nome ou de conexión. Un erro de nome nunha aplicación e unha páxina correcta noutra é a sinatura de dous resolutores, non dun túnel roto.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

Eses comandos len a configuración actual do dispositivo, e as compilacións dos fabricantes poden renomear ou restrinxir os valores subxacentes, así que trate a saída como unha pista e non como unha especificación. A documentación de Android sobre Private DNS describe os modos e a forma de nome de host que espera un dispositivo.

Compare esa resposta co resolutor que impón o perfil de VPN. Se non coinciden, atopou o conflito e a pregunta que queda é cal quere a organización que gañe.

Restaure o axuste previsto tras unha comparación

Cambie un axuste, volva probar os dous nomes e deixe o axuste como estaba. Un dispositivo deixado nun modo permisivo resolve nomes internos e envía en silencio cada consulta pública a quen responda primeiro, o que é un cambio de privacidade que ninguén rexistrou.

Escriba o resultado como regra: os nomes internos resólvense con este resolutor, os públicos con aquel, e o navegador segue ou non segue o dispositivo. Unha regra que nomea o resolutor é verificable, mentres que unha nota que di que a VPN se arranxou non o é. Logo comprobe se algo máis do dispositivo depende do resolutor que cambiou. As comprobacións de actualizacións, a detección de portais cativos e os clientes de correo fan as súas propias peticións, e fallan de xeitos que os usuarios notifican como problemas non relacionados.

Artigos relacionados