Architecture-center: Уточнить использование «Разрешить переадресацию трафика»

Привет @jtuliani Спасибо, что сообщили об этой проблеме! Мы проверим и внесем необходимые изменения.

+1, я бы также добавил, что мы должны отметить, что при включении переадресации трафика в виртуальной сети пользователи должны учитывать, что в сетевых адаптерах Azure также должна быть включена переадресация (мы можем просто сделать ссылку здесь ).

Я потратил много времени, пытаясь понять, почему мои виртуальные машины Linux не могут связаться друг с другом в одноранговых виртуальных сетях, следуя этому руководству, пока не понял, что в сетевых адаптерах также есть дополнительный параметр, который нужно включить.

Большое спасибо - этот пункт был перемещен в наш внутренний бэклог для доработки документации.

@doodlemania2 в документации по- прежнему указано, что требуется «разрешить перенаправленный трафик». Судя по тестированию @jtuliani не должно, а документацию менять надо.

Вот вы ответили, что требуется:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment-506504344

Это большой вопрос! Мы делаем это, чтобы одноранговые узлы могли общаться друг с другом посредством маршрутизации через концентратор. Без него пакеты будут отбрасываться при попытке выйти из луча, предназначенного для концентратора, и наоборот. Дайте нам знать, если это все еще не объясняет это хорошо, и мы можем посмотреть на изменение формулировки!

Действительно ли это требуется, и его тест был несколько неверным? Или документацию нужно обновить?

Вы также можете настроить периферийные устройства для использования шлюза-концентратора для связи с удаленными сетями. Чтобы разрешить трафику шлюза проходить от луча к концентратору и подключаться к удаленным сетям, необходимо:

• Настройте пиринговое соединение в концентраторе, чтобы разрешить транзит через шлюз .
• Настройте пиринговое соединение в каждом луче для использования удаленных шлюзов .
• Настройте все пиринговые соединения, чтобы разрешить переадресацию трафика .

Я также предлагаю не закрывать вопрос здесь, пока он не будет сделан. Внутренний процесс не имеет значения для сообщества, иначе мы просто столкнемся с такими ситуациями.

спасибо, что поделились этим отзывом @jtuliani и @evandropomatti , мы очень ценим это 😸

Я думаю, что это относится к разделу « Пиринг виртуальных сетей» в разделе «Рекомендации», где, насколько я понимаю, обсуждаются два разных сценария.

Сценарий А

Если вам требуется, чтобы лучи подключались друг к другу без пиринга.

В этом случае давайте поделимся из документации по созданию пиринга следующим:

_"Если этот флажок не установлен для пиринга между каждой периферийной виртуальной сетью и виртуальной сетью концентратора, трафик между виртуальными сетями луча не передается, поскольку концентратор не перенаправляет трафик между виртуальными сетями."_

Кроме того,

_"Вам не нужно устанавливать этот параметр, если трафик перенаправляется между виртуальными сетями через VPN-шлюз Azure."_

Сценарий Б

Настройте лучи для использования шлюза-концентратора для связи с удаленными сетями. Для этой очень конкретной конфигурации Разрешить перенаправленный трафик не требуется.

При этом, пожалуйста, давайте снова откроем этот вопрос, так как я согласен, читая документы, что это хорошая идея, чтобы провести здесь различие.

В рамках этого пересмотра, пожалуйста, давайте также рассмотрим возможность указать, для какого пиринга эти проверки действительно необходимы (т. е. сценарий B, [x] Use remote gateways требуется от пиринга по лучевому концентратору, а [x] Allow gateway transit требуется от концентратора). -спичечный пиринг, и [] Allow forwarded traffic могут оставаться неотмеченными для обоих) при условии, что это предпочтение автора. Вид сбоку на это может быть идеальным.

В заключение, честно говоря, текущая конфигурация будет хорошо работать для обоих сценариев A + B, поэтому они не конфликтуют друг с другом. Учитывая это, для простоты мы могли бы оставить ARM как есть.

@ferantivero Я думаю, вы