Table des matières

Introduction

Aperçu

Problèmes courants

Inconnu, Non protégé

Aucun site n'est bloqué

Application d'une stratégie incorrecte

Échec du DNS public ou de tous les DNS

Échec du DNS local

Le client affiche Hors connexion sur le tableau de bord

L'ordinateur signale un avertissement d'absence de connectivité

L'entrée DNS locale de l'ordinateur disparaît

Introduction

Ce document décrit comment dépanner les problèmes courants où un client itinérant est protégé mais ne se comporte pas comme prévu.

Aperçu

Bienvenue dans la série d'articles de la base de connaissances « my roaming client ». Cette série de questions interactives répond aux défis courants des clients itinérants.

Ce document cible le scénario dans lequel le client itinérant est vert et protégé, mais ne se comporte pas comme prévu. Ce document fournit les questions fréquemment posées sur ce scénario, fréquemment rencontrées après le déploiement de clients en itinérance. Le client s'installe, mais ne se comporte pas comme prévu.

L'index « My Roaming Client Series » :

1. Mon client d'itinérance ne s'active pas et....

2. Dépannage des erreurs courantes du client d'itinérance protégé

Problèmes courants

Explorez les possibilités de chaque sous-section en remplissant le champ « Mon client itinérant dit « Protégé » mais... _________ » :

Inconnu, Non protégé

S'il s'agit de l'état actuel, cet article n'est pas ciblé pour ce scénario ! Il s'agit d'un état non protégé dans lequel le client n'est pas encore enregistré. Consultez cet article pour découvrir comment un proxy peut empêcher un client itinérant de s'enregistrer ou contactez notre équipe d'assistance pour obtenir de l'aide.

Aucun site n'est bloqué

Le client d'itinérance signale « Protégé » lorsque nous pouvons atteindre 208.67.220.220 et 208.67.222.222 pour DNS sur UDP 53 ou 443 ou si le client est configuré pour désactiver en raison d'une stratégie connue. Si le client signale un mode protégé, mais que des blocages ne se produisent pas, procédez comme suit :

1. Recherchez un proxy. Dans le cas d'un proxy transparent ou explicite, le DNS résolu sur l'ordinateur est à nouveau demandé et remplacé par le serveur proxy. Voir Utiliser un DNS parapluie avec un proxy HTTP.

2. Un proxy DNS logiciel tiers remplace les réponses DNS du client d'itinérance

3. Une stratégie différente de celle attendue est en cours d'application. Pour savoir comment confirmer l'application de la stratégie attendue, cliquez ici.

Application d'une stratégie incorrecte

Le client d'itinérance signale « Protégé et chiffré » ou « Protégé et transparent », mais les stratégies du client d'itinérance ne s'appliquent pas :

1. Vérifiez que la stratégie basée sur le client itinérant est la stratégie gagnante. Si, sur un réseau, le réseau est plus élevé dans l’ordre des politiques que les clients en itinérance, sa politique s’applique. Consultez cet article pour savoir quelle politique est appliquée ou visitez le site policy-debug.opendns.com pour plus de détails.

2. Recherchez un proxy. Dans le cas d'un proxy transparent ou explicite, le DNS résolu sur l'ordinateur est à nouveau demandé et remplacé par le serveur proxy. Le serveur proxy utilisant Umbrella appliquerait uniquement sa couverture de niveau réseau basée sur la sortie. Voir Utiliser un DNS parapluie avec un proxy HTTP.

3. Utilisation du module de sécurité d’itinérance AnyConnect ? Le client d'itinérance autonome ne doit pas être installé en même temps ! Si ERCService.exe et acumbrellaagent.exe s'exécutent simultanément, cela indique que les deux sont installés. Désinstallez le client d'itinérance autonome Umbrella et assurez-vous qu'aucun outil de gestion logiciel ne le réinstalle.

Échec du DNS public ou de tous les DNS

Dans ce scénario, tous les DNS ne reçoivent pas de réponse. Une commande nslookup dans l'invite de commandes ou le terminal affiche la durée de l'erreur ou échoue, et les navigateurs signalent les problèmes DNS et l'échec du chargement des pages :

1. Un proxy DNS logiciel tiers remplace les réponses DNS du client d'itinérance.

2. De nombreux logiciels ne remplacent que les enregistrements A de « destination du site Web », ce qui permet aux enregistrements TXT de passer librement. Comme le client d'itinérance vérifie la disponibilité DNS avec les enregistrements TXT, il s'active même si tous les enregistrements A n'atteignent pas Umbrella. Le DNS de parapluie chiffré associé au logiciel d'arrière-plan entraîne souvent l'échec de l'envoi des enregistrements A du DNS.

3. Un pare-feu intègre une protection DNS ou un service de « protection Web », ce qui peut interférer avec Umbrella.

4. Si cela se produit par intermittence, il peut s'agir d'un épuisement PAT/NAT. L'ajout du client d'itinérance a augmenté le nombre de connexions UDP directes à partir du réseau de sortie des stations de travail. Par intermittence, cela entraîne l’échec du trafic DNS ou du trafic Web. Pour plus d'informations, consultez cet article sur l'épuisement de ce port et comment modifier le délai d'attente UDP ou valider votre limite de connexion UDP peut vous aider.

5. Utilisation du module de sécurité d’itinérance AnyConnect ? Le client d'itinérance autonome ne doit pas être installé en même temps ! Si ERCService.exe et acumbrellaagent.exe s'exécutent simultanément, cela indique que les deux sont installés. Désinstallez le client d'itinérance autonome Umbrella et assurez-vous qu'aucun outil de gestion logiciel ne le réinstalle.

Échec du DNS local

Dans ce scénario, tout enregistrement public échoue ; cependant, les domaines de votre liste de domaines internes ne peuvent pas être résolus. Si les serveurs DNS locaux sont interrogés directement, la requête réussit.

1. Le domaine n'a pas été ajouté à votre liste de domaines internes ? Remarque : tout suffixe de recherche est automatiquement ajouté dynamiquement à la liste locale (et non côté cloud). Tout domaine local ne figurant pas dans cette liste ne peut pas être résolu correctement. Tout domaine local ne figurant pas dans la liste apparaît dans votre rapport Tableau de bord. Aucun domaine de la liste ne le fait. Découvrez le fonctionnement du DNS local ici.

2. Les serveurs DNS locaux sont-ils corrects ? Vérifiez que les valeurs stockées dans le client d'itinérance correspondent à vos attentes. Vérifiez que chaque serveur répertorié (voir l'emplacement dans ce document) est en mesure de renvoyer la réponse. Choisissons-en un pour envoyer chaque requête DNS locale à. Elles correspondent à votre bail DHCP ou à votre affectation statique. Si ce n'est pas le cas, faites-le-nous savoir en ouvrant une demande d'assistance.

- Mac : /var/lib/data/opendns/resolv_orig.conf

- PC: C:\ProgramData\OpenDNS\ERC\Resolver#-Name-of-NetworkAdaptor.conf

3. Compatibilité logicielle ou VPN. Le problème se produit-il uniquement sur un VPN ? Si c'est le cas, assurez-vous que le VPN ne limite pas l'endroit où le DNS peut circuler ou que votre VPN ne figure pas dans notre liste de VPN non pris en charge. Consultez notre article sur la compatibilité VPN pour plus de détails.

Le client affiche Hors connexion sur le tableau de bord

Le processus de synchronisation du client itinérant joue un rôle déterminant dans les états du client, comme indiqué sur le tableau de bord. Le client d'itinérance s'active uniquement lorsque :

- Au moins une synchronisation vers notre serveur de synchronisation (actuellement sync.hydra.opendns.com) est terminée depuis le démarrage du client

- Un des serveurs DNS Umbrella est disponible sur le port 443 ou 53 UDP.

L'état du tableau de bord du client est mis à jour à chaque synchronisation (prend actuellement jusqu'à 60 minutes). Voici quelques raisons possibles pour lesquelles ces états ne sont pas à jour :

1. L'état du client a changé depuis la dernière synchronisation. Remarque : la synchronisation initiale au démarrage est effectuée lorsque le client est « hors ligne » ou n'est pas protégé en raison de la nécessité de protéger la synchronisation.

2. Le client ne parvient pas à se synchroniser de façon intermittente en raison de restrictions réseau. Une synchronisation initiale a pu avoir lieu, mais les mises à jour de synchronisation suivantes échouent, ce qui fait apparaître le client hors connexion.

3. L'ordinateur a commuté les réseaux depuis le dernier démarrage du client. Par exemple, l'ordinateur a été mis sous tension dans un café-boulangerie avec accès synchrone, puis il a été connecté au réseau de l'entreprise sans accès synchrone. Le client reste protégé/chiffré si DNS est disponible, mais le tableau de bord signale que le client est hors connexion.

L'ordinateur signale un avertissement d'absence de connectivité

Lors de l'utilisation du client d'itinérance, les ordinateurs de certains environnements réseau peuvent afficher un indicateur de connectivité réseau de type « triangle jaune », mais l'accès au réseau est entièrement opérationnel. Cela peut avoir un impact sur les applications Microsoft telles qu'Outlook, car elles ne se synchronisent pas si l'indicateur est déclenché.

1. Ce problème est une limitation de conception connue dans Windows. Pour la résoudre définitivement :

- Windows 7/8: suivez les instructions du fichier hosts de ce document.

- Windows 10: Effectuez une mise à jour vers la version 1709 ou ultérieure et suivez ces instructions pour modifier votre stratégie de groupe ou votre registre afin d'implémenter le correctif de Microsoft.

L'entrée DNS locale de l'ordinateur disparaît

Le client d'itinérance transfère de manière transparente toute requête DNS vers n'importe quel domaine de votre liste de domaines internes. Lorsque vous utilisez le client d'itinérance, vous voyez le plus souvent deux mises à jour au lieu d'une, car nous modifions le DNS sur la machine. Dans le cas où l'enregistrement disparaît :

1. Lisez cet article pour déployer un correctif logiciel Microsoft pour Windows 7 afin d'empêcher la suppression de l'enregistrement au moment où le client passe en mode protégé.