Architecture-center: Klärung der Verwendung von "Weitergeleiteten Datenverkehr zulassen"

Hallo @jtuliani Vielen Dank, dass Sie dieses Problem gemeldet haben! Wir werden dies überprüfen und alle erforderlichen Änderungen vornehmen.

+1, würde ich noch hinzufügen, dass wir sollten beachten , dass , wenn der Verkehr auf der VNet weitergeleitet Enabling berücksichtigen müssen Benutzer , dass die Azure NICs müssen auch Weiterleitung aktiviert haben (wir können einfach verlinken auf hier ).

Ich habe viel Zeit damit verbracht, herauszufinden, warum sich meine Linux-VMs in Peering-VNETs nach diesem Handbuch nicht erreichen konnten, bis mir klar wurde, dass es auch eine zusätzliche Einstellung auf den NICs gab, die aktiviert werden musste.

Vielen Dank - dieser Punkt wurde zur Verfeinerung der Dokumentation in unseren internen Backlog verschoben.

@doodlemania2 In der Dokumentation steht immer noch, dass " Weitergeleiteten Datenverkehr zulassen" erforderlich ist. Nach @jtuliani- Tests zu urteilen, sollte dies nicht der

Hier haben Sie geantwortet, dass es erforderlich ist:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

Dies ist eine großartige Frage! Wir tun dies, damit die Peers über das Routing über den Hub miteinander kommunizieren können. Ohne sie würden die Pakete fallen, wenn sie versuchten, den für den Hub bestimmten Spoke zu verlassen und umgekehrt. Lassen Sie es uns wissen, wenn das immer noch nicht gut erklärt wird, und wir können uns eine Neuformulierung ansehen!

Ist es tatsächlich erforderlich und sein Test war etwas falsch? Oder die Dokumentation muss aktualisiert werden?

Sie können auch Spokes konfigurieren, um das Hub-Gateway für die Kommunikation mit Remote-Netzwerken zu verwenden. Damit Gateway-Datenverkehr vom Spoke zum Hub fließen und eine Verbindung zu Remote-Netzwerken hergestellt werden kann, müssen Sie:

• Konfigurieren Sie die Peering-Verbindung im Hub, um Gateway-Transit zuzulassen .
• Konfigurieren Sie die Peering-Verbindung in jedem Spoke, um Remote-Gateways zu verwenden .
• Konfigurieren Sie alle Peering-Verbindungen, um weitergeleiteten Datenverkehr zuzulassen .

Ich schlage auch vor, dass wir das Thema hier nicht schließen, bis es erledigt ist. Der interne Prozess spielt für die Community keine Rolle, sonst stoßen wir einfach auf solche Situationen.

danke, dass du dieses Feedback @evandropomatti geteilt hast , wir wissen das sehr zu schätzen 😸

Ich denke, dies bezieht sich auf den Abschnitt Virtual Network Peering unter Empfehlungen, wo nach meinem Verständnis zwei verschiedene Szenarien diskutiert werden.

Szenario A

Wenn Sie Spokes benötigen, um eine Verbindung ohne Peering herzustellen.

Lassen Sie uns für dieses Fallszenario aus den Dokumenten Peering erstellen Folgendes teilen:

_"Wenn dieses Kontrollkästchen für das Peering zwischen jedem virtuellen Spoke-Netzwerk und dem virtuellen Hub-Netzwerk nicht aktiviert ist, fließt kein Datenverkehr zwischen den virtuellen Spoke-Netzwerken, da der Hub den Datenverkehr zwischen den virtuellen Netzwerken nicht weiterleitet."_

Zusätzlich,

_"Sie müssen diese Einstellung nicht überprüfen, wenn Datenverkehr zwischen virtuellen Netzwerken über ein Azure VPN Gateway weitergeleitet wird."_

Szenario B

Konfigurieren Sie Spokes, um das Hub-Gateway für die Kommunikation mit Remote-Netzwerken zu verwenden. Für diese spezielle Konfiguration ist Weiterleitungsverkehr zulassen nicht erforderlich.

Lassen Sie uns dieses Thema jedoch erneut öffnen, da ich beim Lesen der Dokumente zustimme, dass dies eine gute Idee ist, hier eine Unterscheidung zu treffen.

Als Teil dieser Überarbeitung sollten wir auch angeben, bei welchem ​​Peering diese Prüfungen wirklich erforderlich sind (dh Szenario B, [x] Use remote gateways wird vom Spoke-Hub-Peering benötigt, während [x] Allow gateway transit vom Hub benötigt wird -spoke peering, und [] Allow forwarded traffic könnte für beide deaktiviert bleiben) vorausgesetzt, dies ist die Präferenz des Autors. Eine Seitenansicht davon könnte ideal sein.

Um es zusammenzufassen und der Fairness halber zu sein, die aktuelle Konfiguration wird für beide Szenarien A + B gut funktionieren, sodass sie sich nicht widersprechen. Angesichts dessen möchten wir der Einfachheit halber die ARM(s) vorerst unverändert lassen.

@ferantivero Ich denke, du hast es geschafft und wir können das Problem jetzt schließen.