Scenariusz urządzenia wirtualnego
Typowym scenariuszem wśród większych klientów platformy Azure jest potrzeba udostępnienia aplikacji dwuwarstwowej uwidocznionej w Internecie, umożliwiając jednocześnie dostęp do warstwy wewnętrznej z lokalnego centrum danych. Ten dokument przeprowadzi Cię przez scenariusz przy użyciu tabel tras, VPN Gateway i wirtualnych urządzeń sieciowych w celu wdrożenia środowiska dwuwarstwowego spełniającego następujące wymagania:
Aplikacja sieci Web musi być dostępna tylko z publicznego Internetu.
Serwer internetowy obsługujący aplikację musi mieć dostęp do serwera aplikacji zaplecza.
Cały ruch z Internetu do aplikacji internetowej musi przechodzić przez wirtualne urządzenie zapory. To urządzenie wirtualne jest używane tylko dla ruchu internetowego.
Cały ruch przechodzący do serwera aplikacji musi przechodzić przez wirtualne urządzenie zapory. To urządzenie wirtualne jest używane do uzyskiwania dostępu do serwera zaplecza i dostępu pochodzącego z sieci lokalnej za pośrednictwem VPN Gateway.
Administratorzy muszą mieć możliwość zarządzania wirtualnymi urządzeniami zapory z komputerów lokalnych przy użyciu trzeciego wirtualnego urządzenia zapory używanego wyłącznie do celów zarządzania.
Ten przykład jest standardowym scenariuszem sieci obwodowej (znanej również jako DMZ) z strefą DMZ i chronioną siecią. Taki scenariusz można utworzyć na platformie Azure przy użyciu sieciowych grup zabezpieczeń, wirtualnych urządzeń zapory lub kombinacji obu tych elementów.
W poniższej tabeli przedstawiono niektóre zalety i wady między sieciowymi grupami zabezpieczeń a wirtualnymi urządzeniami zapory.
| Element | Zalety | Wady |
|---|---|---|
| Sieciowa grupa zabezpieczeń | Bez kosztów. Zintegrowane z dostępem opartym na rolach platformy Azure. Reguły można tworzyć w szablonach usługi Azure Resource Manager. |
Złożoność może się różnić w większych środowiskach. |
| Zapora | Pełna kontrola nad płaszczyzną danych. Centralne zarządzanie za pośrednictwem konsoli zapory. |
Koszt urządzenia zapory. Nie można zintegrować z dostępem opartym na rolach platformy Azure. |
Poniższe rozwiązanie używa wirtualnych urządzeń zapory do implementowania scenariusza sieci obwodowej (DMZ)/chronionej sieci.
Zagadnienia do rozważenia
Środowisko wyjaśnione wcześniej na platformie Azure można wdrożyć przy użyciu różnych dostępnych obecnie funkcji, jak pokazano poniżej.
Sieć wirtualna. Sieć wirtualna platformy Azure działa podobnie do sieci lokalnej i może być podzielona na jedną lub więcej podsieci w celu zapewnienia izolacji ruchu i rozdzielenia problemów.
Urządzenie wirtualne. Kilku partnerów udostępnia urządzenia wirtualne w Azure Marketplace, które mogą być używane w przypadku trzech opisanych wcześniej zapór.
Tabele tras. Tabele tras są używane przez sieć platformy Azure do kontrolowania przepływu pakietów w sieci wirtualnej. Te tabele tras można zastosować do podsieci. Tabelę tras można zastosować do podsieci GatewaySubnet, która przekazuje cały ruch do sieci wirtualnej platformy Azure z połączenia hybrydowego do urządzenia wirtualnego.
Przekazywanie ip. Domyślnie aparat sieci platformy Azure przekazuje pakiety do wirtualnych kart sieciowych tylko wtedy, gdy docelowy adres IP pakietu jest zgodny z adresem IP karty sieciowej. W związku z tym jeśli tabela tras definiuje, że pakiet musi być wysyłany do danego urządzenia wirtualnego, aparat sieci platformy Azure porzuci ten pakiet. Aby upewnić się, że pakiet jest dostarczany do maszyny wirtualnej (w tym przypadku urządzenie wirtualne), które nie jest rzeczywistym miejscem docelowym pakietu, włącz przekazywanie IP dla urządzenia wirtualnego.
Sieciowe grupy zabezpieczeń. Poniższy przykład nie korzysta z sieciowych grup zabezpieczeń, ale można użyć sieciowych grup zabezpieczeń zastosowanych do podsieci i/lub kart sieciowych w tym rozwiązaniu. Sieciowe grupy zabezpieczeń dodatkowo filtrują ruch do i z tych podsieci i kart sieciowych.
W tym przykładzie istnieje subskrypcja zawierająca następujące elementy:
Dwie grupy zasobów, które nie są wyświetlane na diagramie.
ONPREMRG. Zawiera wszystkie zasoby niezbędne do symulowania sieci lokalnej.
AZURERG. Zawiera wszystkie zasoby niezbędne dla środowiska sieci wirtualnej platformy Azure.
Sieć wirtualna o nazwie onpremvnet segmentowana w następujący sposób, aby naśladować lokalne centrum danych.
onpremsn1. Podsieć zawierająca maszynę wirtualną z uruchomioną dystrybucją systemu Linux w celu naśladowania serwera lokalnego.
onpremsn2. Podsieć zawierająca maszynę wirtualną z uruchomioną dystrybucją systemu Linux naśladuje komputer lokalny używany przez administratora.
Istnieje jedno urządzenie wirtualne zapory o nazwie OPFW w sieci lokalnej używane do obsługi tunelu do sieci azurevnet.
Sieć wirtualna o nazwie azurevnet została segmentowana w następujący sposób.
azsn1. Zewnętrzna podsieć zapory używana wyłącznie dla zewnętrznej zapory. Cały ruch internetowy jest kierowany przez tę podsieć. Ta podsieć zawiera tylko kartę sieciową połączoną z zewnętrzną zaporą.
azsn2. Podsieć frontonu hostująca maszynę wirtualną działającą jako serwer internetowy dostępny z Internetu.
azsn3. Podsieć zaplecza hostująca maszynę wirtualną z uruchomionym serwerem aplikacji zaplecza dostępnym przez serwer frontonu sieci Web.
azsn4. Podsieć zarządzania używana wyłącznie do zapewniania dostępu do zarządzania wszystkim wirtualnym urządzeniom zapory. Ta podsieć zawiera tylko kartę sieciową dla każdego wirtualnego urządzenia zapory używanego w rozwiązaniu.
GatewaySubnet. Podsieć połączenia hybrydowego platformy Azure wymagana dla usługi ExpressRoute i VPN Gateway w celu zapewnienia łączności między sieciami wirtualnymi platformy Azure i innymi sieciami.
W sieci azurevnet istnieje 3 wirtualne urządzenia zapory.
AZF1. Zewnętrzna zapora uwidoczniona publicznemu Internetowi przy użyciu zasobu publicznego adresu IP na platformie Azure. Musisz upewnić się, że masz szablon z witryny Marketplace lub bezpośrednio od dostawcy urządzenia, który wdraża urządzenie wirtualne z 3 kartami sieciowymi.
AZF2. Wewnętrzna zapora używana do kontrolowania ruchu między azsn2 i azsn3. Ta zapora jest również urządzeniem wirtualnym 3-kart sieciowych.
AZF3. Zapora zarządzania dostępna dla administratorów z lokalnego centrum danych i połączona z podsiecią zarządzania używaną do zarządzania wszystkimi urządzeniami zapory. Szablony urządzeń wirtualnych 2 kart sieciowych można znaleźć w witrynie Marketplace lub zażądać jednego bezpośrednio od dostawcy urządzenia.
Tabele tras
Każda podsieć na platformie Azure może być połączona z tabelą tras służącą do definiowania sposobu kierowania ruchu inicjowanego w tej podsieci. Jeśli nie zdefiniowano tras zdefiniowanych przez użytkownika, platforma Azure używa domyślnych tras, aby zezwolić na przepływ ruchu z jednej podsieci do innej. Aby lepiej zrozumieć tabele tras i routing ruchu, zobacz Routing ruchu w sieci wirtualnej platformy Azure.
Aby zapewnić komunikację za pośrednictwem odpowiedniego urządzenia zapory, na podstawie ostatniego wymagania wymienionego wcześniej, należy utworzyć następującą tabelę tras w usłudze azurevnet.
azgwudr
W tym scenariuszu jedynym ruchem przepływającym ze środowiska lokalnego do platformy Azure jest zarządzanie zaporami przez połączenie z usługą AZF3, a ruch musi przechodzić przez wewnętrzną zaporę AZF2. W związku z tym tylko jedna trasa jest niezbędna w podsieci GatewaySubnet , jak pokazano poniżej.
| Element docelowy | Narzędzie Następny przeskok | Wyjaśnienie |
|---|---|---|
| 10.0.4.0/24 | 10.0.3.11 | Zezwala na ruch lokalny w celu uzyskania dostępu do zapory zarządzania AZF3 |
azsn2udr
| Element docelowy | Narzędzie Następny przeskok | Wyjaśnienie |
|---|---|---|
| 10.0.3.0/24 | 10.0.2.11 | Zezwala na ruch do podsieci zaplecza hostowania serwera aplikacji za pośrednictwem narzędzia AZF2 |
| 0.0.0.0/0 | 10.0.2.10 | Zezwala na kierowanie całego innego ruchu za pośrednictwem azF1 |
azsn3udr
| Element docelowy | Narzędzie Następny przeskok | Wyjaśnienie |
|---|---|---|
| 10.0.2.0/24 | 10.0.3.10 | Zezwala na przepływ ruchu do azsn2 z serwera aplikacji do serwera internetowego za pośrednictwem azF2 |
Należy również utworzyć tabele tras dla podsieci w sieci lokalnej , aby naśladować lokalne centrum danych.
onpremsn1udr
| Element docelowy | Narzędzie Następny przeskok | Wyjaśnienie |
|---|---|---|
| 192.168.2.0/24 | 192.168.1.4 | Zezwala na ruch do ruchu onpremsn2 przez OPFW |
onpremsn2udr
| Element docelowy | Narzędzie Następny przeskok | Wyjaśnienie |
|---|---|---|
| 10.0.3.0/24 | 192.168.2.4 | Zezwala na ruch do obsługiwanej podsieci na platformie Azure za pośrednictwem systemu OPFW |
| 192.168.1.0/24 | 192.168.2.4 | Zezwala na ruch do ruchu onpremsn1 do OPFW |
Przesyłanie dalej IP
Tabele tras i przekazywanie IP to funkcje, których można używać w połączeniu, aby umożliwić używanie urządzeń wirtualnych do kontrolowania przepływu ruchu w usłudze Azure Virtual Network. Urządzenie wirtualne to po prostu maszyna wirtualna, na której działa aplikacja służąca do obsługi ruchu sieciowego w określony sposób, na przykład zapora lub urządzenie NAT.
Ta maszyna wirtualna urządzenia wirtualnego musi mieć możliwość odbierania ruchu przychodzącego, który nie jest adresowany do samego siebie. Aby umożliwić maszynie wirtualnej odbieranie ruchu kierowanego do innych miejsc docelowych, konieczne jest włączenie dla tej maszyny wirtualnej funkcji przesyłania dalej IP. To ustawienie jest ustawieniem platformy Azure, a nie ustawieniem w systemie operacyjnym gościa. Urządzenie wirtualne nadal musi uruchamiać aplikację pewnego typu w celu obsługi ruchu przychodzącego i odpowiednio go kierować.
Aby dowiedzieć się więcej na temat przekazywania adresów IP, zobacz Routing ruchu w sieci wirtualnej platformy Azure.
Załóżmy na przykład, że masz następującą konfigurację w sieci wirtualnej platformy Azure:
Podsieć onpremsn1 zawiera maszynę wirtualną o nazwie onpremvm1.
Podsieć onpremsn2 zawiera maszynę wirtualną o nazwie onpremvm2.
Urządzenie wirtualne o nazwie OPFW jest połączone z elementem onpremsn1 i onpremsn2.
Trasa zdefiniowana przez użytkownika połączona z elementem onpremsn1 określa, że cały ruch do onpremsn2 musi być wysyłany do OPFW.
W tym momencie, jeśli onpremvm1 próbuje nawiązać połączenie z onpremvm2, trasa zdefiniowana przez użytkownika zostanie użyta, a ruch zostanie wysłany do OPFW jako następnego przeskoku. Należy pamiętać, że rzeczywiste miejsce docelowe pakietu nie jest zmieniane, ale nadal mówi onpremvm2 jest miejscem docelowym.
Bez włączonego przekazywania ip dla OPFW logika sieci wirtualnej platformy Azure odrzuca pakiety, ponieważ umożliwia wysyłanie pakietów tylko do maszyny wirtualnej, jeśli adres IP maszyny wirtualnej jest miejscem docelowym pakietu.
Dzięki funkcji przekazywania ip logika sieci wirtualnej platformy Azure przekazuje pakiety do OPFW bez zmiany oryginalnego adresu docelowego. OPFW musi obsługiwać pakiety i określać, co z nimi zrobić.
Aby scenariusz działał wcześniej, należy włączyć przekazywanie ip na kart sieciowych dla OPFW, AZF1,AZF2 i AZF3, które są używane do routingu (wszystkie karty sieciowe z wyjątkiem kart sieciowych połączonych z podsiecią zarządzania).
Reguły zapory
Zgodnie z wcześniejszym opisem przekazywanie adresów IP gwarantuje, że pakiety są wysyłane do urządzeń wirtualnych. Urządzenie nadal musi zdecydować, co zrobić z tymi pakietami. W poprzednim scenariuszu należy utworzyć następujące reguły na urządzeniach:
OPFW
OPFW reprezentuje urządzenie lokalne zawierające następujące reguły:
Trasa: cały ruch do 10.0.0.0/16 (azurevnet) musi być wysyłany przez tunel ONPREMAZURE.
Zasady: Zezwalaj na cały ruch dwukierunkowy między portami 2 i ONPREMAZURE.
AZF1
AZF1 reprezentuje urządzenie wirtualne platformy Azure zawierające następujące reguły:
- Zasady: Zezwalaj na cały ruch dwukierunkowy między portem1 i portem2.
AZF2
AZF2 reprezentuje urządzenie wirtualne platformy Azure zawierające następujące reguły:
- Zasady: Zezwalaj na cały ruch dwukierunkowy między portem1 i portem2.
AZF3
AZF3 reprezentuje urządzenie wirtualne platformy Azure zawierające następujące reguły:
- Trasa: cały ruch do 192.168.0.0/16 (onpremvnet) musi być wysyłany do adresu IP bramy platformy Azure (tj. 10.0.0.1) do portu1.
Sieciowe grupy zabezpieczeń
W tym scenariuszu sieciowe grupy zabezpieczeń nie są używane. Można jednak zastosować sieciowe grupy zabezpieczeń do każdej podsieci, aby ograniczyć ruch przychodzący i wychodzący. Można na przykład zastosować następujące reguły sieciowej grupy zabezpieczeń do zewnętrznej podsieci FW.
Dane
Zezwalaj na cały ruch TCP z Internetu do portu 80 na dowolnej maszynie wirtualnej w podsieci.
Odmów całego innego ruchu z Internetu.
Wychodzące
- Odmów całego ruchu do Internetu.
Kroki ogólne
Aby wdrożyć ten scenariusz, wykonaj następujące ogólne kroki.
Zaloguj się do subskrypcji platformy Azure.
Jeśli chcesz wdrożyć sieć wirtualną, aby naśladować sieć lokalną, wdróż zasoby, które są częścią ONPREMRG.
Wdróż zasoby, które są częścią usługi AZURERG.
Wdróż tunel z sieci onpremvnet w usłudze azurevnet.
Po aprowizacji wszystkich zasobów zaloguj się do poleceń onpremvm2 i ping 10.0.3.101, aby przetestować łączność między elementem onpremsn2 i azsn3.