Question Comment éviter les retards associés aux enregistrements IPv6 AAAA?


Nos serveurs Windows enregistrent IPv6 AAAA enregistrements avec nos serveurs DNS Windows. Cependant, le routage IPv6 n'étant pas activé sur notre réseau, cela entraîne souvent des comportements de blocage.

Microsoft RDP est le pire délinquant. Lors de la connexion à un serveur doté d'un AAAA enregistrer dans DNS, le client de bureau distant essaiera d’abord IPv6 et ne retombera pas sur IPv4 tant que la connexion n’aura pas expiré. Les utilisateurs expérimentés peuvent contourner ce problème en se connectant directement à l'adresse IP. Résoudre l’adresse IPv4 avec ping -4 hostname.foo travaille toujours instantanément.

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

  • Désactiver IPv6 sur le client?
  • Désactiver IPv6 sur le serveur?
  • Masquer les enregistrements IPv6 sur le récurseur DNS de type utilisateur?
  • Empêcher l'enregistrement d'enregistrements IPv6 AAAA sur le serveur Microsoft DNS?
    • Je ne pense pas que ce soit même possible.

À ce stade, j'envisage d'écrire un script qui purge tous les enregistrements AAAA de nos zones DNS. S'il vous plaît, aidez-moi à trouver un meilleur moyen.


METTRE À JOUR: La résolution DNS est ne pas le problème. Comme @joeqwerty le souligne dans sa réponse, les enregistrements DNS sont renvoyés instantanément. Tous les deux A et AAAA les enregistrements sont immédiatement disponibles. Le problème est que certains clients (mstsc.exe) tentera préférentiellement une connexion sur IPv6 et mettra un certain temps à revenir à IPv4.

Cela semble être un problème de routage. le ping Cette commande génère un message d'erreur "General failure" car l'adresse de destination est non routable.

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 paquet de ce comportement. L'exécution de cette commande ping (échec) ne produit aucun paquet dans le Moniteur réseau Microsoft. De même, tenter une connexion avec mstsc.exe à un hôte avec un AAAA record ne génère aucun trafic tant qu’il n’a pas recours à IPv4.

METTRE À JOUR: Nos hôtes utilisent tous des adresses IPv4 pouvant être routées publiquement. Je pense que ce problème pourrait se résumer à une configuration 6to4 cassée. 6to4 se comporte différemment sur les hôtes avec des adresses IP publiques par rapport aux adresses RFC1918.

METTRE À JOUR: Il y a certainement quelque chose de louche avec 6to4 sur mon réseau. Lorsque je désactive 6to4 sur le client Windows, les connexions se résolvent instantanément.

netsh int ipv6 6to4 set state disabled

Mais comme @joeqwerty le dit, cela ne fait que masquer le problème. J'essaie toujours de savoir pourquoi la communication IPv6 sur notre réseau ne fonctionne pas du tout.


11
2017-10-25 22:15


origine


Terminez le déploiement d’IPv6 sur votre réseau, bien sûr. - Michael Hampton♦
Avez-vous exécuté une capture réseau sur un client pour confirmer cet échec / retard de résolution IPv6? - joeqwerty
De plus, Microsoft fournit plusieurs outils Fixit pratiques pour désactiver / activer divers composants IPv6: support.microsoft.com/kb/929852 - joeqwerty
@ joeqwerty Les serveurs et les utilisateurs sont sur des sous-réseaux distincts, mais tout est un seul grand site. Nous n'utilisons pas de DNS à cerveau divisé, il n'y a donc pas de concept de "DNS interne". - Nic
Aussi je pense que vous trouverez cet article de RIPE aussi bien que RFC 6343 lecture très intéressante et pertinente. Ma recommandation personnelle à vous serait de vider 6to4 entièrement. - Michael Hampton♦


Réponses:


Cette question est assez intéressante et je dois avouer que je n'ai jamais vu ce comportement. En essayant de mieux comprendre, j'ai pris un extrait de requête nslookup interrogeant l'un de mes serveurs RDS W2K8R2 sur 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 pas tardé à renvoyer l'enregistrement IPv6 et nslookup a montré à mon serveur de test interroger l'enregistrement IPv4 avant d'interroger cet enregistrement IPv6. Le delta temporel dans la capture ne montre aucun retard appréciable (que je puisse vérifier) ​​dans les deux requêtes.


enter image description here


enter image description here


MODIFIER

Maintenant vous êtes sur quelque chose.

Assurez-vous de capturer 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. Notez les 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


Donc, 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 à IPv4 (qui est la valeur par défaut pour Windows - Windows préfère IPv6 à IPv4) et parce que IPv6 ne fonctionne pas correctement, il provoque le retard (comme vous l’avez indiqué) lorsque vous passez de IPv6 à IPv4. Vous pouvez résoudre ce problème en configurant les clients pour qu'ils préfèrent IPv4 à IPv6, mais je pense que cela ne ferait que masquer le problème. La meilleure solution serait de comprendre pourquoi IPv6 ne fonctionne pas et de résoudre ce problème. Je ne connais pas suffisamment le système IPv6 pour aider, mais j’imagine que les enregistrements IPv6 renvoyés par DNS sont des adresses "locales" valides uniquement sur le sous-réseau hébergeant les hôtes RDS et, comme les clients se trouvent dans un sous-réseau différent, ils peuvent " t pas atteindre ces adresses IPv6.


10
2017-10-25 23:21



Bro, avez-vous même RFC 1918? - Ryan Ries
LOL. Ils sont arrivés tôt, se sont vus attribuer leur propre bloc / 24 et ont choisi de l’utiliser en interne au lieu de traiter avec NAT. Ils utilisent environ 80% du bloc et ont pris la position "si ce n'est pas cassé ne le répare pas". - joeqwerty
@joeqwerty J'ai mis à jour ma question avec quelques précisions. nslookup fonctionne bien mais le ping échoue avec l'échec général. - Nic
@ joeqwerty Merci pour toutes vos contributions. J'ai posté une réponse à cette question qui clarifie ce qui s'est passé dans mon environnement et suggère ce que d'autres personnes pourraient faire dans une situation similaire. - Nic


La technologie de transition IPv6 appelée 6to4 est infâme pour causer des problèmes comme 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 des facteurs habilitants et des réflexions sur leur atténuation est présentée ci-dessous.


Windows active 6to4 par défaut

Si vos hôtes exécutent une version récente de Windows (Vista ou version ultérieure), Windows active de manière opportuniste le tunneling 6to4 lorsqu'une adresse IPv4 routable 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 commençant 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 de terminaison 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. (Appliquer cela à vos clients ou à vos serveurs serait suffisant, mais si vous prenez cette étape, il est probablement logique de la désactiver partout, sur les deux clients. et les 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 IPv6 entièrement. netsh int ipv6 6to4 set state disabled
  • Utilisez un autre système d'exploitation client. Par exemple, 6to4 n'est pas activé par défaut pour Mac OS X.

Des adresses IPv4 publiquement routables sont utilisées

6to4 ne fonctionne que sur les hôtes disposant d'adresses IPv4 pouvant être routées publiquement. Ce problème ne concerne donc pas les hôtes situés derrière un pare-feu NAT.

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

6to4 ne fonctionne pas correctement sur le réseau

Il est tristement difficile de dépanner 6to4 en mode anycast. Il est si gênant qu’une demande officielle ait été adressée à l’IETF 6to4 devrait être reclassé comme historique. De l'avis de cet auteur, 6to4 est obsolète.

En résumé, 6to4 fonctionne en encapsulant des paquets IPv6 dans des paquets IPv4 en utilisant un protocole appelé 6in4 (protocole IP = 41). Les paquets IPv4 sont adressés à une adresse anycast 192.88.99.1 dans l’espoir d’arriver à un relais 6to4 en état de fonctionnement quelque part sur Internet. Il pourrait même être géographiquement proche, si vous avez de la chance.

En pratique, certains relais 6to4 sont configurés de manière incorrecte et de nombreux réseaux ne permettent même pas au trafic 6 en 4 de traverser le pare-feu. Cela se produit généralement lorsqu'un pare-feu autorise tout le trafic sortant, mais n'autorise pas explicitement les paquets du protocole IP 41 à transiter par le pare-feu. (Notez le RFC pertinent pour le dépannage.) Cet échec ("trou noir entrant") et de nombreux autres sont décrits dans RFC 6343.

  • Configurez votre pare-feu pour qu'il rejette bruyamment le protocole IP 41 (avec réinitialisation TCP) lorsqu'il est envoyé depuis des hôtes internes à votre réseau. Cela devrait entraîner un comportement «échec rapide» qui a plus de sens que des retards de connexion non déterministes. Cela a été démontré qu'il fonctionne dans des environnements de test limités.
  • Demandez à votre FAI ou à votre fournisseur de transit du premier saut de configurer un relais 6to4 en état de fonctionnement. Si cela est fait correctement, les utilisateurs finaux bénéficieront de la meilleure expérience. Tout utilisateur final possédant une adresse IPv4 pouvant être routée publiquement serait en mesure de participer à Internet IPv6.

Enregistrement DNS dynamique

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

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

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

L'application client n'échoue pas correctement

Le client RDP de Microsoft est un exemple d'application client qui ne résout pas correctement les problèmes de routage IPv6. La plupart des navigateurs Web traitent mieux les cas extrêmes IPv6 comme celui-ci, ils n'ont donc pas tendance à montrer ce comportement.

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

9
2017-10-28 00:44



Je voudrais élargir la discussion sur les problèmes 6to4 en mentionnant comment les adresses RFC 6598 pourraient aggraver le problème. La plupart des logiciels qui activent automatiquement 6to4 si une adresse IPv4 publique est disponible ont été écrits avant cette RFC. Par conséquent, une adresse RFC 6598 sera naturellement détectée comme s'il s'agissait d'une adresse IPv4 publique. Mais ce n'est pas le cas, et exécuter 6to4 sur une adresse RFC 6598 ne fonctionnera pas. Si vous voyez une adresse IPv6 de 2002: 6440 :: / 26, vous avez rencontré le problème 6to4 + RFC 6598. - kasperd
Le relais anycast 6to4 n’est relavent que lorsqu’il communique entre un hôte 6to4 et un hôte IPv6 natif. Il n’est pas relavent lorsqu’il communique entre deux hôtes 6to4 (paradoxalement, cela signifie que l’ajout d’IPv6 natif à certains hôtes peut aggraver la situation). - Peter Green


Je me rends compte que ce n'est pas très utile dans cette situation, mais pour les développeurs confrontés à un dilemme similaire, il existe une technique d'implémentation appelée "Joyeux yeux" (RFC 6555) qui spécifie une technique permettant de se connecter simultanément à ipv4 et ipv6 et de choisir celle qui se connecte en premier.


2
2017-10-29 14:23





Voici ma solution. Par défaut, Windows attribue aux routes IPv6 une priorité plus élevée que les routes IPv4. Si vous modifiez la stratégie de préfixe IPv6, vous pouvez modifier ce comportement pour lui faire utiliser IPv4 plutôt que IPv6.

Pour être sûr que tous les systèmes de mon réseau sont configurés de la même manière, j'ai placé les commandes suivantes dans un script .bat exécuté lors de l'installation du logiciel après la construction ou la remise à neuf 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

Pour 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 voudrez peut-être ne pas utiliser ces 3 lignes si vous ne donnez pas à votre machine l'adresse IPv6, dans mon cas, j'ai un serveur DHCPv6 et l'infrastructure associée qui attribue IPv6 pour la connectivité en tunnel

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

Le troisième bloc recrée ensuite les stratégies de préfixe IPv6, mais utilise un ensemble de priorités différent. De même, le préfixe correspondant à IPv4 a la préférence sur IPv6, et la machine voudra alors utiliser IPv4 à moins que l’application ne spécifie l’utilisation d’IPv6.

Cette solution conserve la capacité fonctionnelle de double pile, mais la préférence pour l’utilisation d’IPv4 signifie que les sites avec un IPv6 incomplet, peu fiable ou peu performant éviteront de l’utiliser à moins d’un programme du système.

Je suis d’avis que faire en sorte que les systèmes d’exploitation utilisent IPv6 de préférence à IPv4 empêche réellement leur adoption. Au cours de la période de transition, un hôte pense parfois qu'il dispose d'une connectivité IPv6 mais ne dispose pas d'une connexion pleinement fonctionnelle, ce qui entraîne des dysfonctionnements logiciels et des retards importants. De nombreuses personnes que je connais ont entièrement désactivé IPv6 sur leur routeur pour contourner le problème qui empêchait les fournisseurs de services Internet de déployer IPv6 avant d'établir une connectivité complète. Ils oublient simplement de le réactiver, les laissant sans IPv6 jusqu'à ce qu'ils reconfigurent leur routeur.


0
2017-07-10 16:01



+1 pour désactiver le tunneling, -1 pour préférer IPv4. Ce n'est pas un problème pour la plupart des gens et ne devrait être appliqué qu'à des utilisateurs spécifiques dans des circonstances spécifiques. - Michael Hampton♦