Концепция дизайна
Из-за стоимости Azure Firewall ожидается, что он будет использоваться в более масштабных реализациях. Но высокоприоритетные машины не обязаны быть крупными; несколько виртуальных машин могут быть ответственны за миллионы долларов бизнеса.
Идея Microsoft обычно заключается в развернутом Azure Firewall, представленным архитектурой hub-and-spoke в виртуальной сети (peered VNets), но вы можете развернуть брандмауэр Azure и в выделенной подсети одной виртуальной сети.
Firewall
Развернутая специальная подсеть согласно требованиям Azure Firewall — эта подсеть, которая называется AzureFirewallSubnet, должна иметь маску подсети по крайней мере 25 бит.
Azure Firewall имеет два IP адреса:
- Внешний IP адрес (PIP — a public IP address): Вы должны записать IPv4-адрес PIP во все правила NAT, которые хотите создать. Правила NAT требуют «IP-адрес назначения», куда будет направляться интернет-трафик.
- Внутренний IP адрес (Internal IP Address): Azure Firewall будет использовать один IP-адрес из AzureFirewallSubnet. Этот адрес будет использоваться в таблицах маршрутизации для веб-сайтов и подсетей сервера.
Веб-подсеть
Подсеть создается для веб серверов. Подсеть имеет:
- Специальную группу безопасности сети (NSG — a dedicated network security group): NSG контролирует, какой трафик TCP / UDP может поступать в подсеть и выходить из нее из любого пункта/адреса назначения, включая Интернет, другие машины в виртуальной сети, другие машины в той же подсети и Azure Firewall.
- Специальную таблицу маршрутизации (a dedicated route table): таблица маршрутизации направляет весь трафик во внутренний IP адрес Azure Firewall.
Теперь к маршрутизации. Если вы намерены направить весь трафик, включая внутренний, через firewall, то вы должны создать очень детальные правила. 0.0.0.0/0 будет направлять внешний трафик через firewall; трафик в те же/другие подсети в той же виртуальной сети будет направляться напрямую, минуя firewall. Чтобы заставить веб-сервера маршрутизировать к бэкэнду (предположим, что бэкэнд — 10.0.3.0/24), необходимо создать правило, отправляющее весь трафик на 10.0.3.0/24 на внутренний IP-адрес firewall, также как и правило для 0.0.0.0/0.
Получить полный контроль над маршрутизацией и отправкой всего внутреннего трафика через firewall может быть непросто, особенно если есть другие сервисы с внешними IP-адресами (разделенная маршрутизация). Но все же есть преимущества этой «микросегментации»:
- Весь трафик проверяется Azure Firewall
- Весь трафик регистрируется Azure Firewall
Вы можете заметить, что веб-сервера имеют внутренний балансировщик IP-нагрузки; это обеспечивает единый внутренний IP-адрес (адрес перевода), который можно использовать для правил NAT.
Подсеть бекенда
Вышеописанная информация о маршрутизации применима и здесь. Обратите внимание, что в данном случае NAT не будет использоваться для трафика из Интернета в эту подсеть. Вместо этого, приложение и/или правила сети в Azure Firewall позволят трафику проходить из веб-подсети во внутреннюю подсеть — при условии, что вы следовали приведенному выше совету о получении полного контроля над маршрутизацией.
Расширение
Допустим, у вас есть другие службы, которые будут иметь внешние IP-адреса. Может быть, инсталляционный сервер (или хост-бастион) будет иметь специальный PIP, или, может быть, вы хотите разместить шлюз/firewall веб-приложения перед веб-серверами (еще один специальный PIP)? Если вам что-нибудь из этого подходит, то следует быть осторожными с маршрутизацией. Если у вас есть таблица маршрутов, которая отправляет весь трафик через firewall, то:
- Внешние клиенты увидят ответы, пришедшие с другого IP-адреса, а не с того, куда они отправили запрос.
- Брандмауэр Azure может блокировать исходящий трафик, поскольку он не рассматривается как ответ на разрешенное правило входящего трафика.
В этом случае вам придется уделять гораздо больше внимания структуре подсети, размещению машины/устройства и тому, как трафик направляется во внешний мир.