Você escrevefilesnum emulador de terminal e nada volta; você escrevefiles.corp.examplee o mesmo servidor responde de imediato. Nada mudou nas credenciais da VPN, e o servidor DNS privado nunca esteve avariado. No Android, a etiqueta curta e o nome completo seguem caminhos diferentes pelo resolvedor, e um desses caminhos depende de uma definição que o proprietário do túnel tem de fornecer. A decisão à sua frente não é que servidor DNS mudar, mas quem controla a rede que a aplicação realmente usa.

Um domínio de pesquisa não é um endereço. É uma lista de sufixos que o resolvedor acrescenta a uma etiqueta simples antes de desistir.

Um sufixo de pesquisa e um servidor DNS são campos separados

O endereço do resolvedor diz ao Android onde perguntar. O sufixo de pesquisa diz o que perguntar quando só fornece a etiqueta mais à esquerda. Ambos vivem no mesmo objeto de rede, e qualquer um deles pode faltar sozinho.

É precisamente essa independência que explica porque funciona o nome de anfitrião completo. Um nome totalmente qualificado não precisa de sufixo, porque já é a cadeia que vai para o servidor.

O Android expõe essa separação através deLinkProperties. A lista de servidores DNS e a lista de pesquisa de domínios ficam no mesmo objeto, e a segunda costuma estar vazia mesmo quando a primeira está completa. Uma rede com resolvedor mas sem domínio é uma rede em que o sufixo nunca foi aplicado — não um servidor que recusou o nome curto.

Leia a rede efetiva antes de mudar seja o que for

Wi-Fi, rede móvel e uma interface VPN são três redes separadas, e o túnel passa a ser o predefinido assim que sobe. Por isso o sufixo que funcionava no Wi-Fi do escritório não é automaticamente o sufixo em vigor enquanto o túnel está ativo. Inspecione a rede em que a aplicação está realmente selecionada, não a que configurou na semana passada.

Uma consola de terminal no dispositivo é uma má testemunha aqui, porque o seuresolv.confreflete uma visão do resolvedor e não a de cada aplicação.

As barras de endereço dos navegadores acrescentam outra camada: uma palavra simples pode ser tratada como consulta de pesquisa, ou resolvida através dapolítica própria de DNS cifrado do navegador, pelo que uma página que carrega no Chrome não prova nada sobre consultas do sistema. Teste com algo que use o resolvedor da plataforma e imprima o que voltou. Depois execute a forma curta e a forma completa na mesma sessão, na mesma rede, e anote qual produziu uma resposta.

Se constrói a aplicação VPN, anexe o sufixo no construtor

Quando a sua aplicação estabelece a interface através deVpnService,addSearchDomainé a entrada suportada para isto. Recebe uma cadeia de domínio comocorp.example, e não é uma forma alternativa de passar um endereço de servidor.

A chamada liga o sufixo à rede que está a construir, por isso não há nenhuma definição global para inverter depois. Se a aplicação desmonta a interface e a reconstrói ao reconectar, o novo construtor tem de acrescentar o sufixo outra vez, ou a rede de substituição sobe sem ele.

É aqui que muitos imports de perfis de ambiente de trabalho perdem o campo. O exportador escreve o domínio no seu próprio modelo, o frontend do Android só mapeia as opções que conhece, e a interface resultante parece correta em todos os outros aspetos. Um perfil que funciona num portátil e falha num telemóvel é normalmente uma lacuna de mapeamento, não um problema de protocolo.

Se apenas consome a VPN, isto não é consigo para configurar

Não existe qualquer edição do lado do cliente que acrescente um sufixo, nem qualquer propriedade global que possa alterar para falsificar um. O valor é entregue por quem possui o túnel: no perfil do cliente gerido, no seu mapeamento por plataforma, ou através do que o servidor enviar. Diga em que plataforma está e que nome falha, porque os frontends de ambiente de trabalho e móvel divergem exatamente neste campo.

Voltar a importar um perfil de ambiente de trabalho não prova nada sobre o mapeamento móvel.

Três condições decidem se tem um defeito ou uma limitação esperada. Primeira, a organização trata a etiqueta curta como um nome suportado, ou é uma comodidade que só alguma vez funcionou no Wi-Fi do escritório? Segunda, a consulta que falha vem de um navegador, que pode contornar por completo o resolvedor do sistema? Terceira, o nome curto deve ser alcançável pelo túnel, ou apenas a partir da LAN? Se a última resposta for apenas-LAN, acrescentar um sufixo criaria um nome que se resolve fora do escritório e depois não é encaminhado.

Quando o sufixo está presente e os nomes curtos continuam a falhar

Se a lista de pesquisa de domínios já mostracorp.example, deixe de culpar o sufixo. Verifique se o resolvedor devolve alguma resposta para o nome expandido, porque um sufixo só muda a pergunta que faz. Nunca torna o servidor autoritativo para uma zona que não aloja.

Depois verifique a rota. Um endereço que se resolve mas que o túnel não transporta falha ao ligar, o que parece idêntico a uma consulta falhada num navegador que desiste em silêncio.

Os certificados merecem uma menção própria. A validação HTTPS usa o nome de anfitrião que realmente escreveu, por isso um nome curto que se expande corretamente continua a apresentarfilesno aperto de mão. Um certificado emitido parafiles.corp.examplenão será válido para ele, e esse erro é um comportamento correto e não um sintoma do problema de DNS com que começou.

O que fazer a seguir

Confirme a separação antes de tocar em qualquer coisa: o nome completo resolve-se, o curto não, a mesma aplicação, a mesma sessão. Depois encontre a rede selecionada e leia a sua lista de pesquisa de domínios ao lado da lista de resolvedores. A que das duas estiver vazia diz-lhe quem tem de agir — você, se for dono da aplicação; o operador do túnel, se não for.

Por fim, prefira o nome de serviço completo nos marcadores e na configuração do cliente onde a portabilidade importar. Sobrevive a uma mudança de rede, não depende de um mapeamento que o frontend móvel pode não implementar, e coincide com o nome para o qual foi emitido um certificado.

Artigos relacionados