У меня есть виртуальная машина в виртуальной сети Azure, которой необходимо знать исходный общедоступный IP-адрес входящих подключений, которые перенаправляются на порт с помощью брандмауэра. Пока я могу успешно перенаправить порт с брандмауэра на сервер, только если я "SNAT" входящее соединение. Но это скрывает исходный IP-адрес источника.
Вот упрощение текущий дизайн
Брандмауэр имеет единый интерфейс 10.0.0.1, связанный с общедоступным IP-адресом в Azure. Перенаправление портов настроено на брандмауэре для отправки любого TCP 80 на сервер 10.0.1.1 в соответствии с логикой, изложенной в этом блог Клиент подключается к общедоступному IP-адресу. Журналы брандмауэра показывают утвержденные данные с IP 1.2.3.4 -> 10.0.0.1. Если исходящий NAT настроен на брандмауэре для преобразования соединения после перенаправления порта, сервер (10.0.1.1) показывает соединение, но IP-адрес источника = 10.0.0.1 (т.е. частный интерфейс FW)
Если исходящая трансляция NAT отключена на устройстве FW, журналы показывают ту же утвержденную информацию на FW для входящего соединения, но пакет никогда не достигает сервера 10.0.1.1.
Если я устанавливаю второй сервер 10.0.1.2 или 10.0.0.2, а затем подключаюсь к 10.0.0.1:80 (с отключенной трансляцией NAT для исходящего трафика на устройстве FW), то соединение выполняется успешно, хотя к серверу 10.0.1.1 и src IP правильно равен 10.0.1.2 или 10.0.0.2
Я подозреваю, что маршрутизация структуры Azure отбрасывает любые пакеты, в которых какой-либо IP-адрес src не входит в диапазон адресного пространства виртуальной сети. В Интернете есть множество статей, демонстрирующих подобный подход в стиле «DMZ» в Azure, но ни в одной из них не требуется, чтобы серверы обработки запросов знали исходный общедоступный IP-адрес источника.
Это можно сделать?
Редактировать:
После целого дня борьбы с этим я не мог заставить его работать. Итак, я отказался от FW и воссоздал другое приложение с двумя сетевыми адаптерами. Исходная сетевая карта (WAN), как и раньше, а другая в подсети 10.0.1.1 (LAN). НО ЭТО ПО-прежнему НЕ РАБОТАЕТ! Я даже не могу установить связь ...
У меня в офисе реплицируется такая же установка на голом железе, и она отлично работает. Я проверил все настройки FW (включая маршруты) между экземпляром с голым железом и экземпляром Azure. Я запустил захват пакетов на LAN-интерфейсе экземпляра azure и вижу, что пакеты «перенаправлен порт» покидают интерфейс. У меня Wireshark работает на 10.0.1.1, но пакеты никогда не приходят! Я подумал, что это может быть проблема шлюза по умолчанию, поэтому я добавил определяемый пользователем маршрут в подсеть 10.0.1.0 для сети 1.2.3.4/32, чтобы убедиться, что ACK вернутся к клиенту через устройство FW. Но и это не сработало.
Любая другая помощь была бы очень признательна, эта была обнаружена.
Успех
Через много часов и виртуальных машин у меня все заработало. Проблема заключалась в определяемом пользователем маршруте в сети 10.0.1.x. Я только включил маршрут для охвата диапазона подключающихся клиентов, но это не сработало. Если я установил UDR = 0.0.0.0/0 и следующий переход к устройству FW, то бинго.
Итак, чтобы резюмировать мою рабочую конфигурацию.
В то время как вышеупомянутое теперь полностью передает IP-адрес клиента на виртуальную машину в сети 10.0.1.x и обеспечивает успешное соединение, я добавил исходящее сопоставление NAT 10.0.1.x / 24, чтобы виртуальная машина могла получить доступ к Интернет. Без этого не могло быть. UDR также блокирует любой доступ через общедоступный IP-адрес, подключенный к виртуальной машине в сети 10.0.1.x, и теперь требуются дополнительные правила для FW, чтобы разрешить RDP и т. Д. К виртуальной машине через FW.
Для чьей-либо выгоды у меня также работают две NIC FW. Здесь UDR просто должен указывать на IP-адрес сетевой карты LAN.
Если исходящий NAT настроен на брандмауэре для преобразования соединения после перенаправления порта, сервер (10.0.1.1) показывает соединение, но IP-адрес источника = 10.0.0.1 (т.е. частный интерфейс FW)
Если исходящая трансляция NAT отключена на устройстве FW, журналы показывают ту же утвержденную информацию на FW для входящего соединения, но пакет никогда не достигает сервера 10.0.1.1.
Все это сделано специально. И должно работать именно так.
Если исходный IP-адрес не является частным адресом брандмауэра, то ответ будет отправлен непосредственно на 1.2.3.4 (исходный IP-адрес является общедоступным IP-адресом, и ответ будет отправлен с общедоступным адресом, назначенным серверу. .)
Клиент, который отправляет пакет, получит ответ с совершенно другого публичного IP-адреса, что приведет к сбою соединения.
Чтобы ответные пакеты проходили через брандмауэр, необходимо включить исходящий NAT.
================================================== =======================
Обновить:
Если задействован определяемый пользователем маршрут (UDR), то он работает. Я тестировал его с двумя виртуальными машинами Linux.
Следует отметить несколько моментов:
Переадресация IP должна быть включена на виртуальной машине, которая выполняет переадресацию портов (оба параметра на портале Azure и ОС).
NSG виртуальной машины, которая выполняет переадресацию портов, требует перенастройки, чтобы разрешить перенаправленный трафик и ответ от клиентской виртуальной машины.
Группу безопасности сети клиентской виртуальной машины необходимо перенастроить, чтобы разрешить трафик, пересылаемый виртуальной машиной переадресации портов.
