Architecture-center: 「転送されたトラフィックを許可する」の使用を明確にする

こんにちは@jtulianiこの問題を報告していただきありがとうございます！ 確認し、必要な変更を加えます。

+ 1、VNetで転送されたトラフィックを有効にする場合、ユーザーはAzure NICでも転送を有効にする必要があることを考慮する必要があることにも注意してください（ここにリンクするだけ

NICにも有効にする追加の設定があることに気付くまで、このガイドに従って、ピアリングされたVNetでLinuxVMが相互に到達できない理由を理解するために多くの時間を費やしました。

どうもありがとうございました-このアイテムは、ドキュメントの改良のために内部バックログに移動されました。

@ doodlemania2のドキュメントには、「転送されたトラフィックを許可する」必要があると記載されています。 @jtulianiテストで判断すると、そうすべきではなく、ドキュメントを変更する必要があります。

ここであなたはそれが必要であると答えました：
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

これは素晴らしい質問です！ これは、ピアがハブを介したルーティングを介して相互に通信できるようにするためです。 これがないと、パケットはハブ宛てのスポークを出ようとしたときにドロップし、その逆も同様です。 それでもうまく説明できない場合はお知らせください。言い換えを検討できます。

それは実際に必要であり、彼のテストはやや間違っていましたか？ または、ドキュメントを更新する必要がありますか？

ハブゲートウェイを使用してリモートネットワークと通信するようにスポークを構成することもできます。 ゲートウェイトラフィックがスポークからハブに流れ、リモートネットワークに接続できるようにするには、次のことを行う必要があります。

• ゲートウェイトランジットを
• リモートゲートウェイを使用するように、各スポークのピアリング接続を構成し
• 転送されたトラフィックをます。

また、問題が解決するまで、ここで問題を解決しないことをお勧めします。 内部プロセスはコミュニティにとって重要ではありません。そうでなければ、このような状況に遭遇するだけです。

このフィードバックを共有してくれてありがとう@jtulianiと@evandropomatti 、私たちは本当にこれに感謝します😸

これは、私の理解に基づいて2つの異なるシナリオが議論されている、推奨事項の仮想ネットワークピアリングのセクションを参照していると思います。

シナリオA

スポークをピアリングせずに相互に接続する必要がある場合。

この場合のシナリオでは、ピアリングの

_ "各スポーク仮想ネットワークとハブ仮想ネットワーク間のピアリングでこのチェックボックスがオフになっている場合、ハブは仮想ネットワーク間でトラフィックを転送していないため、トラフィックはスポーク仮想ネットワーク間を流れません。" _

さらに、

_ "トラフィックがAzureVPNゲートウェイを介して仮想ネットワーク間で転送される場合は、この設定を確認する必要はありません。" _

シナリオB

ハブゲートウェイを使用してリモートネットワークと通信するようにスポークを構成します。 この非常に特殊な構成では、転送トラフィックを許可する必要はありません。

そうは言っても、ドキュメントを読みながら、ここで区別するのは良い考えであることに同意するので、この問題を再度開いてみましょう。

この改訂の一環として、これらのチェックが実際に必要なピアリングを示すことも検討してください（つまり、シナリオB、スポークハブピアリングからは[x] Use remote gatewaysが必要ですが、ハブからは[x] Allow gateway transitが必要です） -スポークピアリング、および[] Allow forwarded trafficは、作成者の好みである場合は、両方のチェックを外したままにすることができます）。 これを並べて表示するのが理想的かもしれません。

結論として、公平を期すために、現在の構成は両方のシナリオA + Bでうまく機能するため、互いに競合することはありません。 それを考えると、簡単にするために、今のところARMをそのままにしておくことをお勧めします。

@ferantiveroあなたはそれを釘付けにしたと思います、そして私たちは今問題を閉じることができます。