Architecture-center: Clarifier l'utilisation de « Autoriser le trafic transféré »

Salut @jtuliani Merci d'avoir signalé ce problème ! Nous examinerons et apporterons les modifications nécessaires.

+1, j'ajouterais également que nous devons noter que lors de l'activation du trafic transféré sur le réseau virtuel, les utilisateurs doivent considérer que les cartes réseau Azure doivent également avoir le transfert activé (nous pouvons simplement créer un lien vers ici ).

J'ai passé beaucoup de temps à essayer de comprendre pourquoi mes machines virtuelles Linux ne pouvaient pas se joindre dans les réseaux virtuels appairés en suivant ce guide jusqu'à ce que je réalise qu'il y avait un paramètre supplémentaire sur les cartes réseau à activer également.

Merci beaucoup - cet élément a été déplacé vers notre backlog interne pour le raffinement de la documentation.

@ doodlemania2 la documentation indique toujours que "autoriser le trafic transféré" est requis. À en juger par les tests de @jtuliani , cela ne devrait pas être le cas et la documentation devrait être modifiée.

Ici, vous avez répondu qu'il est nécessaire:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

C'est une excellente question! Nous faisons cela pour que les pairs puissent se parler via le routage via le hub. Sans cela, les paquets tomberaient lorsqu'ils tenteraient de quitter le rayon destiné au concentrateur et vice-versa. Faites-nous savoir si cela ne l'explique toujours pas bien et nous pouvons envisager une reformulation !

Est-ce en fait requis et son test était quelque peu incorrect? Ou la documentation doit être mise à jour ?

Vous pouvez également configurer des rais pour utiliser la passerelle hub pour communiquer avec les réseaux distants. Pour permettre au trafic de la passerelle de circuler du satellite au concentrateur et de se connecter aux réseaux distants, vous devez :

• Configurez la connexion d'appairage dans le hub pour autoriser le transit de la passerelle .
• Configurez la connexion d'appairage dans chaque rai pour utiliser des passerelles distantes .
• Configurez toutes les connexions d'appairage pour autoriser le trafic transféré .

Je suggère également que nous ne fermions pas la question ici jusqu'à ce qu'elle soit terminée. Le processus interne n'a pas d'importance pour la communauté, sinon nous nous heurtons à des situations comme celle-ci.

merci d'avoir partagé ce retour @jtuliani et @evandropomatti , nous l'apprécions vraiment 😸

Je pense que cela fait référence à la section Virtual Network Peering sous Recommandations où, selon ma compréhension, deux scénarios différents sont en cours de discussion.

Scénario A

Si vous avez besoin que les rayons se connectent les uns aux autres sans les appairer.

Pour ce scénario de cas, laissez-nous partager les documents suivants à partir de la création d'un peering :

_"Si cette case n'est pas cochée pour le peering entre chaque réseau virtuel en étoile et le réseau virtuel du concentrateur, le trafic ne circule pas entre les réseaux virtuels en étoile car le concentrateur ne transfère pas le trafic entre les réseaux virtuels."_

En outre,

_"Vous n'avez pas besoin de vérifier ce paramètre si le trafic est transféré entre les réseaux virtuels via une passerelle VPN Azure."_

Scénario B

Configurez les rais pour utiliser la passerelle hub pour communiquer avec les réseaux distants. Pour cette configuration très particulière, Autoriser le trafic transféré n'est pas requis.

Cela étant dit, s'il vous plaît laissez-nous rouvrir ce problème car je suis d'accord en lisant les documents que c'est une bonne idée de faire une distinction ici.

Dans le cadre de cette révision, envisageons également d'indiquer sur quel peering ces vérifications sont vraiment nécessaires (c'est-à-dire le scénario B, [x] Use remote gateways est requis pour le peering spoke-hub, tandis que [x] Allow gateway transit est requis pour le hub -spoke peering, et [] Allow forwarded traffic pourraient rester non cochés pour les deux) à condition que ce soit la préférence de l'auteur. Une vue côte à côte de cela pourrait être idéale.

Juste pour conclure et en toute justice, la configuration actuelle fonctionnera bien pour les deux scénarios A + B, de sorte qu'ils ne se contredisent pas. Étant donné que, par souci de simplicité, nous pourrions vouloir conserver le ou les ARM en l'état pour le moment.

@ferantivero Je pense que vous avez