Вопрос по форвард трафику c на Azure Виртуальных сетях - PullRequest
1 голос
/ 10 февраля 2020

У меня проблема с маршрутизацией, которую я пытаюсь решить на облачной платформе Azure, касающейся трафика c, который необходимо маршрутизировать с одного vnet на другой vnet через другой vnet и два VPN-туннеля. .

Вот описание настройки: у меня есть две Azure Виртуальные сети (VNET1 и VNET2), каждая из которых имеет свой собственный Azure VPN-шлюз на основе маршрута и один сторонний виртуальный сеть (VNET3), которая подключена к первой Azure виртуальной сети VNTE1 через IPse c VPN-туннель. Ниже приведены адресные пространства всех 3 виртуальных сетей.

  • VNET1 10.20.0.0 / 16 (Azure vnet)
  • VNET2 10.30.0.0/16 (Azure vnet)
  • VNET3 10.0.0.0 / 12 (третье лицо vnet)

Вот что я могу сделать:

  • VNET1 подключен через IPse c VPN-туннель с VNET3. Таким образом, я могу пропинговать с ВМ в VNET1 10.20.10.5 ВМ в VNET3 10.0.0.1, и они могут пинговать меня обратно.
  • VNET1 подключен через VPN-туннель IPse c с VNET2 , Таким образом, я могу пропинговать с ВМ в VNET1 10.20.10.5 ВМ в VNET2 10.30.10.5

Вот что я не могу сделать:

  • Я не могу пропинговать с ВМ в VNET2 10.30.10.5 ВМ в VNET3 10.0.0.1.

Вот что я пытался сделать, чтобы решить проблему без какого-либо успеха на данный момент:

  • Я предполагаю, что сеть VNET2 не знает, как маршрутизировать трафик c в сеть VNET3. Таким образом, я создал таблицу маршрутов Azure и назначил таблицу маршрутов для su bnet 10.30.10.0/24, и я создал правило, согласно которому весь трафик c в сеть 10.0.0.0/12 должен маршрутизироваться. к VPN-шлюзу VNTE2. Я ожидаю, что как только трафик c будет go в GW, он достигнет VNET1, который знает, как направить его в VNET3. Это не сработало.
  • Хотя я думаю, что это не нужно, поскольку VNET1 уже знает, как маршрутизировать трафик c в VNET3, я также создал таблицу маршрутизации для 10.0.0.0/12, аналогичную той над. Это тоже не помогло.

Я где-то пропустил маршрут, если да, то какое правило и где? Или мне даже нужно иметь виртуальную машину, действующую как маршрутизатор? (Надеюсь нет)

1 Ответ

1 голос
/ 11 февраля 2020

Я думаю, что ваша проблема - ограничение Azure Виртуальный шлюз:

Локальные сети, подключающиеся через VPN-устройства на основе политик с этим механизмом, могут подключаться только к Azure виртуальному сеть; они не могут проходить в другие локальные сети или виртуальные сети через тот же Azure VPN-шлюз.

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps

Таким образом, даже если вы используете один и тот же VPN-шлюз для соединения с VNET 3 и VNET 2, по проекту VNET 3 и VNET 2 не могут обмениваться данными.

Чтобы решить эту проблему, я рекомендую использовать пиринг. Ваша конфигурация аналогична топологии classi c Hub-Spoke. Ваш VNET1 - это Hub, VNET2 - это Spoke, VNET3 - это что-то вроде «on-prem».

Никаких изменений в конфигурации между VNET1 и VNET3 не требуется. Вам необходимо установить пиринг sh между VNET1 и VNET2 и обратно и применить следующую конфигурацию:

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

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

В этом случае VNET3 сможет для связи с HUB (VNET1) и всеми спицами (VNET2 и любыми другими, подключенными к VNET1). VNET2 может связываться с HUB (VNET1) и локально (VNET3), когда туннель работает.

Предупреждение: Спицы не могут обмениваться данными друг с другом без шлюза переадресации в HUB т.е. если вы добавите VNET4 с пирингом в и из VNET1, VNET4 не сможет пропинговать виртуальные машины в VNET2. Но они могли общаться с HUB и on-prem без каких-либо дополнительных устройств.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...