web-dev-qa-db-fra.com

Comment prévenir les retards associés aux enregistrements IPv6 AAAA?

Nos serveurs Windows enregistrent IPv6 AAAA enregistrements avec nos serveurs Windows DNS. Cependant, nous n'avons pas de routage IPv6 activé sur notre réseau. Cela provoque donc fréquemment des comportements de décrochage.

Microsoft RDP est le pire délinquant. Lors de la connexion à un serveur comportant un enregistrement AAAA enregistré dans DNS, le client de bureau distant essaiera d'abord IPv6 et ne rejouera pas IPv4 jusqu'à ce que les temps de connexion. Les utilisateurs de puissance peuvent contourner cela en se connectant directement à l'adresse IP. Résoudre l'adresse IPv4 avec ping -4 hostname.foo fonctionne toujours instantanément.

Que puis-je faire pour éviter ce délai?

  • Désactiver IPv6 sur le client?
  • Désactiver IPv6 sur le serveur? [.____]
  • Masque IPv6 Records sur le récurseur DNS UTILISABNIG?
  • Prévenir l'enregistrement des enregistrements IPv6 AAAA sur le serveur Microsoft DNS?
    • Je ne pense pas que ce soit même possible.

À ce stade, je envisage d'écrire un script qui purge tous les enregistrements AAAA de nos zones DNS. S'il vous plaît, aidez-moi à trouver une meilleure façon.

Mise à jour: La résolution DNS est non le problème. Comme @joeqwerty souligne dans sa réponse, les enregistrements DNS sont renvoyés instantanément. Les enregistrements A et AAAA sont immédiatement disponibles. Le problème est que certains clients (mstsc.exe) tentera préférentiellement une connexion via IPv6 et prendra un certain temps pour revenir à IPv4.

Cela semble être un problème de routage. La commande ping génère un message d'erreur "défaillance générale" car l'adresse de destination est trouble.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Je ne peux pas obtenir une capture de paquets de ce comportement. Exécution de cette commande (échec) Ping ne produit aucun paquets dans Microsoft Network Monitor. De même, tenter une connexion avec mstsc.exe à un hôte avec un enregistrement AAAA ne produit aucun trafic tant qu'il ne fait pas de replier IPv4.

Mise à jour: Nos hôtes utilisent toutes des adresses IPv4 routihables publiques. Je pense que ce problème pourrait descendre à une configuration de 6to4 cassée. 6to4 se comporte différemment sur les hôtes avec adresses IP publiques VS RFC1918.

Mise à jour: Il y a définitivement quelque chose de poisson avec 6to4 sur mon réseau. Lorsque je désactive 6to4 sur le client Windows, les connexions résolvent instantanément.

netsh int ipv6 6to4 set state disabled

Mais comme @joeqwerty dit, cela ne masque que le problème. J'essaie toujours de savoir pourquoi la communication IPv6 sur notre réseau est complètement non fonctionnelle.

domain-name-systemwindows-server-2008-r2ipv6
11
Nic

La technologie de transition IPv6 appelée 6to4 est infâme pour causer des problèmes tels que celui-ci. Il y a plusieurs facteurs au travail. Individuellement, ils sont inoffensifs, mais l'effet combiné est que les utilisateurs finaux peuvent subir des retards de connexion.

Une liste de facteurs habilitants et des réflexions sur leur atténuation est présentée ci-dessous.

Windows permet 6to4 par défaut

Si vos hôtes exécutent une version récente de Windows (Vista ou ultérieure), Windows permettra d'activer de manière opportuniste 6to4 tunneling lorsqu'une adresse IPv4 routière publiquement est disponible. De manière critique, cela s'applique aux serveurs et aux clients.

Pour savoir si un système utilise 6to4, exécutez ipconfig et recherchez une adresse IPv6 qui commence par le préfixe 6to4 2002:. Cela ressemblerait à quelque chose comme ça.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222
  • Si vos points d'extrémité sont connectés à Active Directory, vous pouvez utiliser la stratégie de groupe pour désactiver les protocoles de transition tels que 6to4 et Teredo. Ceci est bien documenté dans KB929852 . (L'application de cela à vos clients ou aux serveurs serait suffisante, mais si vous prenez cette étape, il est probablement logique de le désactiver partout, sur les deux clients et serveurs.).
  • Si vous ne gérez que quelques hôtes, vous pouvez désactiver 6to4 au cas par cas. C'est beaucoup mieux que de désactiver entièrement IPv6. netsh int ipv6 6to4 set state disabled
  • Utilisez un autre système d'exploitation client. Par exemple, Mac OS X n'a ​​pas été activé par défaut.

Les adresses IPv4 routables publiques sont utilisées

6To4 ne fonctionne que sur les hôtes qui ont des adresses IPv4 roulées publiquement afin que ce problème n'affecte jamais les hôtes derrière un pare-feu NAT.

  • Vous pouvez déplacer des clients et/ou des serveurs derrière un pare-feu NAT et de commencer à utiliser RFC1918 Adressage. Mais dans certains cas, des adresses routables publiquement sont réellement préférées. Changer l'adressage d'un réseau entier pourrait également être un choix irréaliste.

6to4 ne fonctionne pas correctement sur le réseau

Il est concrètement difficile de résoudre le problème de 6to4 en mode Anycast. Il est tellement gênant qu'il y avait une demande formelle à l'IETF que 6to4 devrait être reclassée comme historique . De l'avis de cet auteur, 6to4 a été obsolète.

En bref, 6to4 fonctionne en encapsulant des paquets IPv6 dans des paquets IPv4 à l'aide d'un protocole appelé 6in4 (Protocole IP = 41). Les paquets IPv4 sont adressés à AnyCast Adresse 192.88.99.1 Dans l'espoir qu'il arrivera à un relais de 6to4 travaillant quelque part sur Internet. Cela pourrait même être géographiquement à proximité, si vous êtes chanceux.

En pratique, certains relais de 6to4 sont configurés de manière incorrecte et beaucoup de réseaux ne permettent même pas à 6 pouces de trafic de traverser le pare-feu. Généralement, cela se produit lorsqu'un pare-feu permet à tout le trafic sortant, mais n'autorise pas explicitement que les paquets de protocole IP 4.1 de retourner par le pare-feu. (TODO NOTE Le RFC pertinent pour le dépannage.) Cette défaillance ("trou noir entrant") et beaucoup d'autres sont décrites dans RFC 634 .

  • Configurez votre pare-feu pour rejeter à haute voix le protocole IP 41 (avec TCP réinitialisations) lors de l'envoi des hôtes internes à votre réseau. Cela devrait aboutir à un comportement "Fail Fast" qui a plus de sens que des retards de connexion non déterministes. Cela a été démontré pour travailler dans des environnements de test limités .
  • Demandez à votre fournisseur de transit FIVP ou de premier hop pour configurer un relais de travail de 6to4. Si cela est fait correctement, cela entraînera la meilleure expérience des utilisateurs finaux. Tout utilisateur final avec une adresse IPv4 routière publiquement serait en mesure de participer à l'Internet IPv6.

Enregistrement DNS dynamique

Dans un environnement typique Active Directory, chaque ordinateur est autorisé à enregistrer ses propres adresses avec le serveur DNS. Lorsqu'un hôte est multi-hybriomé, il enregistre toutes ses adresses, même à partir d'un tunnel de 6to4.

La plupart des services Internet n'utilisent pas DNS dynamique, ce problème est donc généralement limité aux sites d'entreprise où les clients et les serveurs sont tous "internes" sur le même réseau.

  • Vous pouvez choisir de désactiver les mises à jour DNS dynamiques. Ensuite, si vous ne mettez aucun enregistrement de ressources AAAA dans le fichier de zone, ils ne seront jamais servis. Cependant, DNS dynamique est souvent souhaitable pour les serveurs DNS internes. (Si vous faites cela, assurez-vous de supprimer également les enregistrements AAAA pouvant déjà être présents.)
  • Configurez le serveur DNS pour ne pas fournir de réponses aux enregistrements de ressources AAAA. Mais ne faites pas cela, car cela vous donnera vraiment des problèmes lorsque vous souhaitez commencer à mettre en œuvre IPv6. (Quelqu'un peut-il connaître un pare-feu DNS gratuit/open source?)

L'application client n'a pas échoué gracieusement

Le client RDP de Microsoft est un exemple d'application client qui ne gère pas gracieusement les problèmes de routage IPv6. La plupart des navigateurs Web préfèrent mieux les cas d'IPv6 Edge, comme celui-ci, ils n'ont donc pas tendance à montrer ce comportement.

  • Essayez d'utiliser un autre client. Peut-être que vous aurez de la chance.
9
Nic

Cette question est assez intéressante et je dois admettre que je n'ai jamais vu ce comportement. En faisant des tripes pour essayer de mieux comprendre, j'ai pris un extrait de Nslookup Interrogé pour l'un de mes serveurs RDS W2K8R2 à partir d'un autre serveur W2K8R2 et j'ai également capturé un extrait d'une session RDP sur le même serveur RDS à partir du même serveur de test. . NSLOOKUP n'a montré aucun délai dans le retour de l'enregistrement IPv6 et le NSLOOKUP a montré à My Test Server Interrogation pour l'enregistrement IPv4 avant d'interroger pour l'enregistrement IPv6. Le délai Delta de la capture ne montre aucun délai appréciable (que je peux vérifier) ​​dans l'une ou l'autre des requêtes.

enter image description here

enter image description here

ÉDITER

Maintenant, vous êtes sur quelque chose.

Assurez-vous que vous capturez le trafic pour l'adaptateur Microsoft 6to4, sinon vous ne verrez pas IPv6:

enter image description here

Voici le résultat de Nslookup pour mon serveur RDS. Prenez note des adresses IPv6:

enter image description here

Maintenant voici un extrait de ma capture:

enter image description here

Et enfin, voici un extrait de NetStat montrant la connexion:

enter image description here

Si clairement, comme vous l'avez confirmé, la résolution DNS n'est pas le problème. Le problème est que la connexion RDP préfère IPv6 via IPv4 (qui correspond à la valeur par défaut de Windows - Windows préfère IPv6 sur IPv4) et, étant donné que IPv6 ne fonctionne pas correctement, il provoque le retard (tel que vous avez indiqué) lors de la baisse de IPv6 à IPv4. Vous pouvez résoudre ce problème en configurant les clients pour préférer IPv4 sur IPv6, mais je pense que cela ne ferait que masquer le problème. La meilleure solution serait de déterminer pourquoi IPv6 ne fonctionne pas et ne résout pas cela. Je ne sais pas assez sur IPv6 pour vous aider, mais je suppose que les enregistrements IPv6 étant renvoyés par DNS sont des adresses "locales" uniquement valables sur le sous-réseau où les hôtes RDS existent et que les clients sont dans un sous-réseau différent, ils peuvent " t atteindre ces adresses IPv6.

10
joeqwerty

Je me rends compte que ce n'est pas très utile pour cette situation, mais pour les impléments confrontés à un dilemme similaire, il existe une technique de mise en œuvre connue sous le nom de "Happy Eyeballs" (RFC 6555 ) Cela spécifie une technique pour la connexion IPv4 et IPv6 simultanément et choisir celui qui se connecte en premier.

2
joe miller

Voici ma solution. Par défaut Windows fournit des itinéraires IPv6 une priorité plus élevée que les itinéraires IPv4. Si vous modifiez la stratégie de préfixe IPv6, vous pouvez modifier ce comportement pour l'utiliser IPv4 de préférence à IPv6.

Pour vous assurer que tous les systèmes de mon réseau sont configurés de la même manière, je pose les commandes suivantes dans un script .bat exécuté pendant l'installation du logiciel après la construction ou la rénovation d'une machine.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface Teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Expliquer ce que cela fait:

Les 3 premières lignes désactivent les interfaces de tunneling intégrées, car elles sont redondantes pour la plupart des réseaux. Vous ne voudrez peut-être pas utiliser ces 3 lignes si vous ne donnez pas à vos machines adresses IPv6 à leur propre, dans mon cas, j'ai un serveur DHCPV6 et une infrastructure associée attribuant IPv6 pour la connectivité tunnelée.

Le deuxième bloc de commandes supprime toutes les stratégies de préfixe de routage IPv6 existantes.

Le troisième bloc recueille ensuite les stratégies de préfixes IPv6, mais utilise un ensemble de priorités différents. Comme pour que le préfixe correspondant à IPv4 soit donné de préférence sur IPv6, et la machine voudra alors utiliser IPv4 à moins que l'application spécifie l'utilisation de IPv6.

Cette solution conserve la capacité de double pile fonctionnelle, mais la préférence d'utiliser IPv4 signifie que les sites avec IPv6 incomplètes, peu fiables ou médiocres, éviteront l'utiliser à moins d'un programme sur le système.

J'estime que l'utilisation de systèmes d'exploitation utiliser IPv6 de préférence à IPv4 entrave réellement l'adoption. Pendant la période de transition, il y aura des moments où un hôte pense qu'il possède une connectivité IPv6 mais ne dispose pas d'une connexion entièrement fonctionnelle, ce qui entraîne des dysfonctionnements logiciels et des retards importants. Beaucoup de personnes que je connais ont désactivé IPv6 entièrement à leur routeur en tant que solution de contournement pour le déploiement de ISPP déployant IPv6 de manière cassée avant d'établir une connectivité complète, et ces personnes n'oublieront tout simplement de le permettre de les laisser à nouveau sans IPv6 avant de reconfigurer leur routeur.

0
OdinYggd