Scenariusze usługi Azure Firewall dotyczące inspekcji ruchu kierowanego do prywatnego punktu końcowego
Uwaga
Jeśli chcesz zabezpieczyć ruch do prywatnych punktów końcowych w usłudze Azure Virtual WAN przy użyciu zabezpieczonego koncentratora wirtualnego, zobacz Bezpieczny ruch kierowany do prywatnych punktów końcowych w usłudze Azure Virtual WAN.
Prywatny punkt końcowy platformy Azure to podstawowy blok konstrukcyjny usługi Azure Private Link. Prywatne punkty końcowe umożliwiają zasobom platformy Azure wdrożonym w sieci wirtualnej komunikację prywatną z zasobami łącza prywatnego.
Prywatne punkty końcowe umożliwiają zasobom dostęp do usługi łącza prywatnego wdrożonej w sieci wirtualnej. Dostęp do prywatnego punktu końcowego za pośrednictwem komunikacji równorzędnej sieci wirtualnych i połączeń sieci lokalnych rozszerza łączność.
Może być konieczne sprawdzenie lub zablokowanie ruchu od klientów do usług udostępnianych za pośrednictwem prywatnych punktów końcowych. Wykonaj tę inspekcję przy użyciu usługi Azure Firewall lub wirtualnego urządzenia sieciowego innej firmy.
Obowiązują następujące ograniczenia:
Ruch sieciowych grup zabezpieczeń jest pomijany z prywatnych punktów końcowych z powodu wyłączenia zasad sieciowych dla podsieci w sieci wirtualnej domyślnie. Aby korzystać z zasad sieciowych, takich jak trasy zdefiniowane przez użytkownika i obsługa sieciowych grup zabezpieczeń, należy włączyć obsługę zasad sieciowych dla podsieci. To ustawienie ma zastosowanie tylko do prywatnych punktów końcowych w podsieci. To ustawienie ma wpływ na wszystkie prywatne punkty końcowe w podsieci. W przypadku innych zasobów w podsieci dostęp jest kontrolowany na podstawie reguł zabezpieczeń w sieciowej grupie zabezpieczeń.
Ruch tras zdefiniowanych przez użytkownika (UDR) jest pomijany z prywatnych punktów końcowych. Trasy zdefiniowane przez użytkownika mogą służyć do zastępowania ruchu przeznaczonego dla prywatnego punktu końcowego.
Do podsieci można dołączyć pojedynczą tabelę tras
Tabela tras obsługuje maksymalnie 400 tras
Usługa Azure Firewall filtruje ruch przy użyciu jednego z następujących elementów:
Nazwa FQDN w regułach sieci dla protokołów TCP i UDP
Nazwa FQDN w regułach aplikacji dla protokołów HTTP, HTTPS i MSSQL.
Ważne
Użycie reguł aplikacji zamiast reguł sieciowych jest zalecane podczas sprawdzania ruchu kierowanego do prywatnych punktów końcowych w celu zachowania symetrii przepływu. Reguły aplikacji są preferowane za pośrednictwem reguł sieci w celu sprawdzenia ruchu kierowanego do prywatnych punktów końcowych, ponieważ usługa Azure Firewall zawsze kieruje ruch SNATs z regułami aplikacji. Jeśli stosowane są reguły sieciowe lub zamiast usługi Azure Firewall jest używane wirtualne urządzenie sieciowe, funkcja SNAT musi być skonfigurowana pod kątem ruchu kierowanego do prywatnych punktów końcowych w celu zachowania symetrii przepływu.
Uwaga
Filtrowanie nazw FQDN SQL jest obsługiwane tylko w trybie serwera proxy (port 1433). Tryb serwera proxy może spowodować większe opóźnienie w porównaniu do przekierowania. Jeśli chcesz nadal używać trybu przekierowania, który jest domyślnym ustawieniem dla klientów łączących się na platformie Azure, możesz filtrować dostęp przy użyciu nazwy FQDN w regułach sieci zapory.
Scenariusz 1: Architektura piasty i szprych — dedykowana sieć wirtualna dla prywatnych punktów końcowych
Ten scenariusz jest najbardziej rozszerzalną architekturą, która łączy się prywatnie z wieloma usługami platformy Azure przy użyciu prywatnych punktów końcowych. Trasa wskazująca przestrzeń adresową sieci, w której są tworzone prywatne punkty końcowe. Ta konfiguracja zmniejsza nakład pracy administracyjnej i uniemożliwia przekroczenie limitu 400 tras.
Połączenie z sieci wirtualnej klienta do usługi Azure Firewall w sieci wirtualnej koncentratora są naliczane opłaty, jeśli sieci wirtualne są równorzędne. Połączenie iony z usługi Azure Firewall w sieci wirtualnej koncentratora do prywatnych punktów końcowych w równorzędnej sieci wirtualnej nie są naliczane opłaty.
Aby uzyskać więcej informacji na temat opłat związanych z połączeniami z równorzędnymi sieciami wirtualnymi, zobacz sekcję Często zadawane pytania na stronie cennika.
Scenariusz 2. Architektura piasty i szprych — współdzielona sieć wirtualna dla prywatnych punktów końcowych i maszyn wirtualnych
Ten scenariusz jest implementowany, gdy:
Nie można mieć dedykowanej sieci wirtualnej dla prywatnych punktów końcowych
Gdy tylko kilka usług jest uwidocznionych w sieci wirtualnej przy użyciu prywatnych punktów końcowych
Maszyny wirtualne mają /32 trasy systemowe wskazujące każdy prywatny punkt końcowy. Jedna trasa dla prywatnego punktu końcowego jest skonfigurowana do kierowania ruchu przez usługę Azure Firewall.
Obciążenie administracyjne związane z utrzymywaniem tabeli tras zwiększa się w miarę uwidocznienia usług w sieci wirtualnej. Możliwość osiągnięcia limitu trasy również wzrasta.
W zależności od ogólnej architektury można uruchomić limit 400 tras. Zaleca się używanie scenariusza 1 zawsze, gdy jest to możliwe.
Połączenie z sieci wirtualnej klienta do usługi Azure Firewall w sieci wirtualnej koncentratora są naliczane opłaty, jeśli sieci wirtualne są równorzędne. Połączenie iony z usługi Azure Firewall w sieci wirtualnej koncentratora do prywatnych punktów końcowych w równorzędnej sieci wirtualnej nie są naliczane opłaty.
Aby uzyskać więcej informacji na temat opłat związanych z połączeniami z równorzędnymi sieciami wirtualnymi, zobacz sekcję Często zadawane pytania na stronie cennika.
Scenariusz 3. Pojedyncza sieć wirtualna
Użyj tego wzorca, gdy migracja do architektury piasty i szprych nie jest możliwa. Mają zastosowanie te same zagadnienia, co w scenariuszu 2. W tym scenariuszu opłaty za komunikację równorzędną sieci wirtualnych nie mają zastosowania.
Scenariusz 4. Ruch lokalny do prywatnych punktów końcowych
Tę architekturę można zaimplementować, jeśli skonfigurowano łączność z siecią lokalną przy użyciu jednego z następujących rozwiązań:
Jeśli wymagania dotyczące zabezpieczeń wymagają, aby ruch klienta do usług uwidocznionych za pośrednictwem prywatnych punktów końcowych był kierowany przez urządzenie zabezpieczeń, wdróż ten scenariusz.
Te same zagadnienia, co w scenariuszu 2 powyżej, mają zastosowanie. W tym scenariuszu nie są naliczane opłaty za komunikację równorzędną sieci wirtualnych. Aby uzyskać więcej informacji na temat konfigurowania serwerów DNS w celu umożliwienia obciążeń lokalnych uzyskiwania dostępu do prywatnych punktów końcowych, zobacz obciążenia lokalne przy użyciu usługi przesyłania dalej DNS.
Następne kroki
W tym artykule przedstawiono różne scenariusze, których można użyć do ograniczenia ruchu między maszyną wirtualną a prywatnym punktem końcowym przy użyciu usługi Azure Firewall.
Aby zapoznać się z samouczkiem dotyczącym konfigurowania usługi Azure Firewall pod kątem inspekcji ruchu kierowanego do prywatnego punktu końcowego, zobacz Samouczek: inspekcja ruchu prywatnego punktu końcowego za pomocą usługi Azure Firewall
Aby dowiedzieć się więcej na temat prywatnego punktu końcowego, zobacz Co to jest prywatny punkt końcowy platformy Azure?.