Integracja usługi Azure Firewall z usługą Azure Standard Load Balancer

Usługę Azure Firewall można zintegrować z siecią wirtualną z wykorzystaniem publicznego lub wewnętrznego Azure Standard Load Balancer.

Preferowanym projektem jest użycie wewnętrznego modułu równoważenia obciążenia w usłudze Azure Firewall, ponieważ upraszcza konfigurację. Jeśli masz już wdrożony publiczny moduł równoważenia obciążenia i chcesz nadal z niego korzystać, pamiętaj o potencjalnych problemach z routingiem asymetrycznym, które mogą zakłócać działanie funkcji.

Aby uzyskać więcej informacji na temat usługi Azure Load Balancer, zobacz Co to jest usługa Azure Load Balancer?

Publiczny moduł równoważenia obciążenia

W przypadku publicznego modułu równoważenia obciążenia jest on wdrażany przy użyciu publicznego adresu IP interfejsu.

Routing asymetryczny

Routing asymetryczny polega na tym, że pakiet pobiera jedną ścieżkę do miejsca docelowego i przyjmuje inną ścieżkę podczas powrotu do źródła. Ten problem występuje, gdy podsieć ma domyślną trasę przechodzącą do prywatnego adresu IP zapory i używasz publicznego modułu równoważenia obciążenia. W takim przypadku przychodzący ruch modułu równoważenia obciążenia jest odbierany za pośrednictwem publicznego adresu IP, ale ścieżka powrotna przechodzi przez prywatny adres IP zapory. Ponieważ zapora jest stanowa, odrzuca zwracany pakiet, ponieważ zapora nie zna takiej ustalonej sesji.

Rozwiązywanie problemu z routingiem

Scenariusz 1: Usługa Azure Firewall bez bramy NAT

Podczas wdrażania usługi Azure Firewall w podsieci należy utworzyć trasę domyślną dla podsieci. Ta trasa kieruje pakiety przez prywatny adres IP zapory, który znajduje się w podsieci AzureFirewallSubnet. Aby uzyskać szczegółowe instrukcje, zobacz Wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu witryny Azure Portal. Podczas integrowania zapory ze scenariuszem modułu równoważenia obciążenia upewnij się, że ruch internetowy przechodzi przez publiczny adres IP zapory. Zapora stosuje swoje reguły i wykonuje translację adresów sieciowych pakietów na publiczny adres IP modułu równoważenia obciążenia. Problem występuje, gdy pakiety docierają do publicznego adresu IP zapory, ale zwracają się za pośrednictwem prywatnego adresu IP (przy użyciu trasy domyślnej).

Aby zapobiec routingowi asymetrycznemu, dodaj określoną trasę dla publicznego adresu IP zapory. Pakiety przeznaczone dla publicznego adresu IP zapory są kierowane przez Internet, omijając domyślną trasę do prywatnego adresu IP zapory.

Przykład tabeli tras

Na przykład poniższa tabela tras przedstawia trasy zapory z publicznym adresem IP 203.0.113.136 i prywatnym adresem IP 10.0.1.4.

Scenariusz 2: Azure Firewall z NAT Gateway

W niektórych scenariuszach można skonfigurować bramę NAT w podsieci usługi Azure Firewall, aby przezwyciężyć ograniczenia portów SNAT (źródłowego tłumaczenia adresów sieciowych) dla łączności wychodzącej. W takich przypadkach konfiguracja trasy w scenariuszu 1 nie działa, ponieważ adres IP bramy NAT ma pierwszeństwo przed adresem IP Azure Firewall.

Aby uzyskać więcej informacji, zobacz Integracja bramy NAT z usługą Azure Firewall.

Gdy NAT Gateway jest skojarzony z podsiecią usługi Azure Firewall, ruch przychodzący z Internetu ląduje na publicznym adresie IP usługi Azure Firewall. Następnie usługa Azure Firewall zmienia (SNAT) źródłowy adres IP na publiczny adres IP bramy NAT, zanim przekaże ruch do publicznego adresu IP modułu równoważenia obciążenia.

Bez bramy NAT, usługa Azure Firewall zmienia źródłowy adres IP na własny publiczny adres IP przed przekazaniem ruchu do publicznego adresu IP modułu równoważenia obciążenia.

Przykład tabeli tras z bramą NAT

Należy dodać trasę dla ścieżki powrotnej, aby użyć publicznego adresu IP NAT Gateway zamiast publicznego adresu IP Azure Firewall, który używa Internetu jako następnego przeskoku.

Na przykład poniższa tabela tras przedstawia trasy dla bramy NAT z publicznym adresem IP 198.51.100.101 i zapory z prywatnym adresem IP 10.0.1.4.

Przykład reguły NAT

W obu scenariuszach reguła NAT tłumaczy ruch RDP (Remote Desktop Protocol) z publicznego adresu IP zapory (203.0.113.136) na publiczny adres IP modułu równoważenia obciążenia (203.0.113.220):

Sondy kondycji

Pamiętaj, aby mieć usługę internetową, która jest uruchomiona na hostach w puli modułu równoważenia obciążenia, jeśli używasz sond zdrowotnych TCP (Transport Control Protocol) na porcie 80 lub sond HTTP/HTTPS.

Wewnętrzny moduł równoważenia obciążenia

Wewnętrzny równoważnik obciążenia jest wdrażany z prywatnym adresem IP połączenia frontowego.

Ten scenariusz nie ma problemów z routingiem asymetrycznym. Pakiety przychodzące docierają do publicznego adresu IP zapory, są tłumaczone na prywatny adres IP modułu równoważenia obciążenia i wracają do prywatnego adresu IP zapory przy użyciu tej samej ścieżki.

Wdróż ten scenariusz w sposób podobny do scenariusza z publicznym równoważnikiem obciążenia, ale bez potrzeby konfiguracji trasy hosta z publicznym adresem IP zapory sieciowej.

Maszyny wirtualne w puli zaplecza mogą mieć wychodzącą łączność internetową za pośrednictwem usługi Azure Firewall. Skonfiguruj trasę zdefiniowaną przez użytkownika w podsieci maszyny wirtualnej, z zaporą jako kolejny etap.

Dodatkowe zabezpieczenia

Aby dodatkowo zwiększyć bezpieczeństwo scenariusza ze zrównoważonym obciążeniem, użyj sieciowych grup zabezpieczeń (NSG).

Na przykład utwórz NSG w podsieci zaplecza, gdzie znajdują się maszyny wirtualne z równoważeniem obciążenia. Zezwalaj na ruch przychodzący pochodzący z publicznego adresu IP i portu zapory. Jeśli brama NAT jest skojarzona z podsiecią Azure Firewall, zezwól na ruch przychodzący z publicznego adresu IP i portu bramy NAT.

Aby uzyskać więcej informacji na temat grup zabezpieczeń sieciowych, zobacz Grupy zabezpieczeń.

Następne kroki

• Dowiedz się, jak wdrożyć i skonfigurować usługę Azure Firewall.