Le VPN Android résout le nom d'hôte complet mais pas le nom court

Vous tapezfilesdans un émulateur de terminal et rien ne revient ; vous tapezfiles.corp.exampleet le même serveur répond aussitôt. Rien n'a changé dans les identifiants du VPN, et le serveur DNS privé n'a jamais été cassé. Sous Android, le nom court et le nom complet empruntent des chemins différents dans le résolveur, et l'un de ces chemins dépend d'un paramètre que le propriétaire du tunnel doit fournir. La décision qui vous attend n'est pas quel serveur DNS changer, mais qui contrôle le réseau que l'application utilise réellement.

Un domaine de recherche n'est pas une adresse. C'est une liste de suffixes que le résolveur ajoute à une étiquette nue avant d'abandonner.

Un suffixe de recherche et un serveur DNS sont deux champs distincts

L'adresse du résolveur dit à Android où interroger. Le suffixe de recherche lui dit quoi demander quand vous ne fournissez que l'étiquette la plus à gauche. Les deux vivent sur le même objet réseau, et l'un comme l'autre peut manquer seul.

Cette indépendance est précisément la raison pour laquelle le nom d'hôte complet fonctionne. Un nom pleinement qualifié n'a pas besoin de suffixe, car il est déjà la chaîne qui part vers le serveur.

Android expose cette séparation viaLinkProperties. La liste des serveurs DNS et la liste de recherche de domaines se trouvent sur le même objet, et la seconde est souvent vide même quand la première est pleine. Un réseau doté d'un résolveur mais sans domaine est un réseau où le suffixe n'a jamais été appliqué — pas un serveur qui a refusé le nom court.

Lisez le réseau effectif avant de changer quoi que ce soit

Le Wi-Fi, le réseau mobile et une interface VPN sont trois réseaux distincts, et le tunnel devient la passerelle par défaut dès qu'il monte. Le suffixe qui fonctionnait sur le Wi-Fi du bureau n'est donc pas automatiquement celui en vigueur pendant que le tunnel est actif. Inspectez le réseau sur lequel l'application est réellement sélectionnée, pas celui que vous avez configuré la semaine dernière.

Un shell de terminal sur l'appareil est un mauvais témoin ici, car sonresolv.confreflète une seule vue du résolveur et non celle de chaque application.

Les barres d'adresse des navigateurs ajoutent une couche : un mot nu peut être traité comme une requête de recherche, ou résolu viala politique de DNS chiffré propre au navigateur, si bien qu'une page qui se charge dans Chrome ne prouve rien sur les résolutions système. Testez avec quelque chose qui utilise le résolveur de la plateforme et affiche ce qui est revenu. Puis lancez la forme courte et la forme complète dans la même session, sur le même réseau, et notez laquelle a produit une réponse.

Si vous développez l'application VPN, attachez le suffixe dans le constructeur

Quand votre application établit l'interface viaVpnService,addSearchDomainest l'entrée prise en charge pour cela. Elle accepte une chaîne de domaine commecorp.example, et ce n'est pas une autre façon de transmettre une adresse de serveur.

L'appel lie le suffixe au réseau que vous construisez, il n'y a donc aucun réglage global à basculer ensuite. Si l'application démonte l'interface et la reconstruit à la reconnexion, le nouveau constructeur doit ajouter à nouveau le suffixe, sinon le réseau de remplacement monte sans lui.

C'est ici que beaucoup d'importations de profils de bureau perdent le champ. L'exportateur écrit le domaine dans son propre modèle, le frontal Android ne mappe que les options qu'il connaît, et l'interface obtenue paraît correcte à tous les autres égards. Un profil qui fonctionne sur un portable et échoue sur un téléphone est généralement une lacune de mappage, pas un problème de protocole.

Si vous ne faites que consommer le VPN, ce n'est pas à vous de le régler

Il n'existe aucune modification côté client qui ajoute un suffixe, ni aucune propriété globale que vous pourriez changer pour en simuler un. La valeur est fournie par celui qui possède le tunnel : dans le profil du client géré, dans son mappage par plateforme, ou par ce que le serveur pousse. Dites sur quelle plateforme vous êtes et quel nom échoue, car les frontaux de bureau et mobile divergent précisément sur ce champ.

Réimporter un profil de bureau ne prouve toujours rien sur le mappage mobile.

Trois conditions décident si vous avez un défaut ou une limite attendue. Premièrement, l'organisation traite-t-elle le nom court comme un nom pris en charge, ou est-ce une commodité qui n'a jamais fonctionné que sur le Wi-Fi du bureau ? Deuxièmement, la résolution qui échoue vient-elle d'un navigateur, qui peut contourner entièrement le résolveur système ? Troisièmement, le nom court doit-il être joignable par le tunnel, ou seulement depuis le LAN ? Si la dernière réponse est LAN uniquement, ajouter un suffixe créerait un nom qui se résout hors du bureau puis ne se route pas.

Quand le suffixe est présent et que les noms courts échouent encore

Si la liste de recherche de domaines affiche déjàcorp.example, cessez d'accuser le suffixe. Vérifiez si le résolveur renvoie une réponse pour le nom développé, car un suffixe ne change que la question posée. Il ne rend jamais le serveur autoritaire pour une zone qu'il n'héberge pas.

Vérifiez ensuite la route. Une adresse qui se résout mais que le tunnel ne transporte pas échoue à la connexion, ce qui ressemble exactement à un échec de résolution dans un navigateur qui abandonne en silence.

Les certificats méritent une mention à part. La validation HTTPS utilise le nom d'hôte que vous avez réellement saisi, donc un nom court qui se développe correctement présente encorefilesdans la poignée de main. Un certificat émis pourfiles.corp.examplene sera pas valide pour lui, et cette erreur est un comportement correct, pas le symptôme du problème DNS avec lequel vous avez commencé.

Que faire ensuite

Confirmez la séparation avant de toucher à quoi que ce soit : le nom complet se résout, le court non, même application, même session. Trouvez ensuite le réseau sélectionné et lisez sa liste de recherche de domaines à côté de sa liste de résolveurs. Laquelle des deux est vide vous indique qui doit agir — vous, si l'application est la vôtre ; l'opérateur du tunnel, sinon.

Enfin, préférez le nom d'hôte de service complet dans les favoris et la configuration client partout où la portabilité compte. Il survit à un changement de réseau, ne dépend pas d'un mappage que le frontal mobile peut ne pas implémenter, et correspond au nom pour lequel un certificat a été émis.