Azure: одна виртуальная машина с двумя службами на двух сетевых адаптерах с двумя общедоступными IP-адресами.

Настраивать

Я настраиваю виртуальную машину Azure (стандартный E2as_v4 под управлением Debian 10) для обслуживания нескольких служб. Я хочу использовать отдельный общедоступный IP-адрес для каждой службы. Чтобы проверить, могу ли я это сделать, я установил следующее:

vm1
 - nic1
  - vnet1, subnet1
  - ipconfig1: 10.0.1.1 <-> p.0.0.1
  - nsg1
    - allow: ssh (22)
 - nic2
  - vnet1, subnet2
  - ipconfig2: 10.0.2.1 <-> p.0.0.2
  - nsg2
    - allow: http (80)

vnet1
 - subnet1: 10.0.1.0/24
 - subnet2: 10.0.2.0/24
 - address space: [10.0.1.0/24, 10.0.2.0/24]

Где 10.x.x.x IP являются частными, а p.x.x.x IP общедоступными.

nic1 (сетевой интерфейс) и сопровождающий его nsg1 (группа безопасности сети) были созданы автоматически, когда я создал виртуальную машину; в противном случае они симметричны nic2, nsg2 (за исключением nsg2, разрешающего HTTP, а не SSH). Кроме того, обе сетевые карты нормально регистрируются на виртуальной машине.

Проблема

Я могу подключиться к SSH через общедоступный IP-адрес nic1 (p.0.0.1). Однако мне не удается подключиться к HTTP через общедоступный IP-адрес nic2 (p.0.0.2).

Вещи, которые я пробовал

Прослушивание 0.0.0.0. Чтобы проверить, не проблема ли это с моим сервером, мой HTTP-сервер прослушивал 0.0.0.0. Затем я разрешил HTTP на nsg1 и добавил конфигурацию вторичного IP на nic1 с другим общедоступным IP (статическим 10.0.1.101 <-> p.0.0.3). Я вручную добавил статический частный IP-адрес в конфигурацию виртуальной машины (/run/network/interfaces.d/eth0; возможно, не тот файл, который нужно редактировать, но IP-адрес был зарегистрирован правильно). Теперь я мог подключиться через оба общедоступных IP-адреса, связанных с nic1 (p.0.0.1 и p.0.0.3), но все еще не через nic2 (p.0.0.2). Это означает, что я успешно настроил два общедоступных IP-адреса для двух разных служб на виртуальной машине, но они используют одну и ту же сетевую карту.

Настройка балансировщика нагрузки. Я также попытался добиться такой же настройки с помощью балансировщика нагрузки. В этом случае я создал балансировщик нагрузки с двумя внутренними пулами - backend-pool1 для nic1 и backend-pool2 для nic2. Я перенаправил трафик SSH на backend-pool1, а трафик HTTP на backend-pool2. Результаты были аналогичны приведенным выше (SSH подключился успешно, HTTP не удалось, если я не использую backend-pool1, а не backend-pool2). Я также пробовал правила прямого входящего NAT - с тем же эффектом.

Убедитесь, что связь через подсеть работает. Наконец, я создал виртуальную машину на subnet2. Я могу общаться со службой, используя частный IP-адрес (10.0.2.1) независимо от конфигурации NSG (я пробовал порт, который не разрешен в NSG, и он прошел). Однако это не работает, когда я использую общедоступный IP-адрес (p.0.0.2).

Вопрос

Что мне не хватает? Есть ли параметр, который я не рассматриваю? В чем причина того, что я не могу подключиться к моей виртуальной машине через общедоступный IP-адрес, настроенный на дополнительной сетевой карте?

Связанные вопросы

Настройка дополнительной сетевой карты в Azure с помощью интернет-шлюза - ответ относится к созданию вторичного публичного IP
Несколько общедоступных IP-адресов для виртуальной машины Azure - ответ относится к созданию нагрузки балансир

Примечания: Я могу попытаться предоставить командные строки для воссоздания установки, если этой информации недостаточно. Я использую HTTP-сервер:

sudo docker run -it --rm -p 10.0.2.1:80:80 nginx

И я заменил слушать на 0.0.0.0 для последующих тестов.

Вот последняя топология, которую я использовал для тестирования.

Yuval 04.05.2021 источник

Ответы (1)

arrow_upward
0
arrow_downward

Чтобы разрешить вторичному интерфейсу (с общедоступным IP-адресом) доступ к Интернету или из него, нам не нужно создавать балансировщик нагрузки. Вместо этого мы можем использовать iproute для поддержки нескольких таблиц маршрутизации. Прочтите http://www.rjsystems.nl/en/2100-adv-routing.php и этот SO-ответ Больше подробностей.

После моей проверки вы можете добавить следующие конфигурации, и у меня это работало на виртуальной машине Linux (ubuntu 18.04).

Активируйте расширенную маршрутизацию Linux в системе Debian GNU / Linux, установите пакет iproute:

apt-get install iproute
Настройте два маршрута по умолчанию

echo 2 cheapskate >> /etc/iproute2/rt_tables
Добавьте новый маршрут по умолчанию в таблицу cheapskate, а затем отобразите его:

~# ip route add default via 10.0.2.1 dev eth1 table cheapskate

~# ip route show table cheapskate

default via 10.0.2.1 dev eth1
Добавьте правило для случая, когда пакет имеет шаблон from 10.0.2.4, и в этом случае следует использовать таблицу маршрутизации cheapskate с уровнем приоритета 1000.

ip rule add from 10.0.2.4 lookup cheapskate prio 1000

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

После всего этого вы можете проверить это с помощью следующей команды, вы увидите общедоступный IP-адрес, прикрепленный к вторичному интерфейсу.

curl --interface eth1 api.ipify.org?format=json -w "\n"

Обратите внимание, что у вас достаточно прав для выполнения всех вышеперечисленных шагов.

Nancy Xiong 12.05.2021