Udostępnij za pośrednictwem

Scenariusz urządzenia wirtualnego

  • Artykuł

Typowym scenariuszem wśród większych klientów platformy Azure jest zapewnienie aplikacji dwuwarstwowej, która jest uwidoczniona w Internecie, a jednocześnie umożliwia dostęp do warstwy zaplecza z lokalnego centrum danych. W tym artykule przedstawiono scenariusz korzystający z tabel tras, bramy sieci VPN i wirtualnych urządzeń sieciowych w celu wdrożenia dwuwarstwowego środowiska spełniającego następujące wymagania:

  • Aplikacja internetowa musi być dostępna tylko z publicznego Internetu.
  • Serwer internetowy hostują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 bramy sieci VPN.
  • 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ą. Ten scenariusz można utworzyć na platformie Azure przy użyciu sieciowych grup zabezpieczeń, wirtualnych urządzeń zapory lub kombinacji obu tych grup.

W poniższej tabeli przedstawiono niektóre zalety i wady sieciowe grupy zabezpieczeń i wirtualne urządzenia zapory.

Towar Plusy Minusy
Sieciowa grupa zabezpieczeń Bez kosztów.
Zintegrowane z dostępem opartym na rolach platformy Azure.
Możliwość tworzenia reguł w szablonach usługi Azure Resource Manager.		 Złożoność może się różnić w większych środowiskach.
Firewall Pełna kontrola nad płaszczyzną danych.
Centralne zarządzanie za pośrednictwem konsoli zapory.		 Koszt urządzenia zapory.
Nie jest zintegrowana 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.

Kwestie wymagające rozważenia

Powyższe środowisko można wdrożyć na platformie Azure, korzystając z dostępnych obecnie funkcji:

  • Sieć wirtualna: sieć wirtualna platformy Azure działa w podobny sposób do sieci lokalnej. Można podzielić je na co najmniej jedną podsieć, aby zapewnić izolację ruchu i separację problemów.
  • Urządzenie wirtualne: kilku partnerów udostępnia urządzenia wirtualne w witrynie Azure Marketplace do użycia dla 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 GatewaySubnetprogramu , który przekazuje cały ruch, który przechodzi do sieci wirtualnej platformy Azure z połączenia hybrydowego z urządzeniem wirtualnym.
  • Przekazywanie adresów IP: domyślnie aparat sieci platformy Azure przekazuje pakiety do wirtualnych kart sieciowych (KART sieciowych) tylko wtedy, gdy docelowy adres IP pakietu jest zgodny z adresem IP karty sieciowej. Jeśli tabela tras definiuje, że pakiet musi być wysyłany do określonego urządzenia wirtualnego, aparat sieci platformy Azure odrzuca 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 lub kart sieciowych w tym rozwiązaniu. Sieciowe grupy zabezpieczeń dodatkowo filtrują ruch w tych podsieciach i z tych podsieci i kart sieciowych.

Diagram przedstawiający łączność IPv6.

W tym przykładzie subskrypcja zawiera następujące elementy:

  • Dwie grupy zasobów (nie pokazane 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 jest segmentowana i używana do naśladowania lokalnego 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 w celu naśladowania komputera lokalnego używanego przez administratora.

  • Jedno urządzenie wirtualne zapory ma nazwę OPFW na .onpremvnet Służy do obsługi tunelu do azurevnet.

  • Sieć wirtualna o nazwie azurevnet jest segmentowana w następujący sposób:

    • azsn1: zewnętrzna podsieć zapory używana wyłącznie dla zapory zewnętrznej. Cały ruch internetowy przechodzi przez tę podsieć. Ta podsieć zawiera tylko kartę sieciową połączoną z zewnętrzną zaporą.
    • azsn2: podsieć frontonu, która hostuje maszynę wirtualną działającą jako serwer internetowy, do którego uzyskuje się dostęp z Internetu.
    • azsn3: podsieć zaplecza, która hostuje maszynę wirtualną z serwerem aplikacji zaplecza, do którego uzyskuje dostęp serwer internetowy frontonu.
    • azsn4: Podsieć zarządzania używana wyłącznie do zapewniania dostępu do zarządzania wszystkimi wirtualnymi urządzeniami 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, która jest wymagana dla usługi Azure ExpressRoute i usługi Azure VPN Gateway w celu zapewnienia łączności między sieciami wirtualnymi platformy Azure i innymi sieciami.

  • W sieci znajdują się azurevnet trzy wirtualne urządzenia zapory:

    • AZF1: Zewnętrzna zapora uwidoczniona w publicznym Internecie przy użyciu zasobu publicznego adresu IP na platformie Azure. Musisz upewnić się, że masz szablon z witryny Azure Marketplace lub bezpośrednio od dostawcy urządzenia, który wdraża urządzenie wirtualne z trzema kartami sieciowymi.
    • AZF2: wewnętrzna zapora używana do kontrolowania ruchu między azsn2 i azsn3. Ta zapora jest również urządzeniem wirtualnym z trzema kartami sieciową.
    • 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 z dwiema kartami sieciową można znaleźć w witrynie Azure Marketplace. Możesz również zażądać jednego bezpośrednio od dostawcy urządzenia.

Tabele tras

Połącz każdą podsieć na platformie Azure z tabelą tras, aby zdefiniować sposób kierowania ruchu inicjowanego w tej podsieci. Jeśli nie zdefiniowano tras zdefiniowanych przez użytkownika, platforma Azure używa tras domyślnych, 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 upewnić się, że komunikacja odbywa się za pośrednictwem odpowiedniego urządzenia zapory, na podstawie ostatniego wymagania wymienionego wcześniej, należy utworzyć następującą tabelę tras w pliku azurevnet.

azgwudr

W tym scenariuszu jedynym ruchem, który przepływa ze środowiska lokalnego do platformy Azure, jest używany do zarządzania zaporami przez połączenie z AZF3usługą , a ruch musi przechodzić przez wewnętrzną zaporę. AZF2 Tylko jedna trasa jest niezbędna w elemecie 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 AZF3zarządzania.

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, która hostuje serwer aplikacji za pośrednictwem usługi AZF2.
0.0.0.0/0 10.0.2.10 Zezwala na kierowanie całego innego ruchu przez AZF1element .

azsn3udr

Element docelowy Narzędzie Następny przeskok Wyjaśnienie
10.0.2.0/24 10.0.3.10 Umożliwia przepływ ruchu azsn2 z serwera aplikacji do serwera internetowego za pośrednictwem usługi AZF2.

Należy również utworzyć tabele tras dla podsieci, onpremvnet 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 przez onpremsn2 OPFW.

onpremsn2udr

Element docelowy Narzędzie Następny przeskok Wyjaśnienie
10.0.3.0/24 192.168.2.4 Zezwala na ruch do podsieci zaplecza na platformie Azure za pośrednictwem usługi OPFW.
192.168.1.0/24 192.168.2.4 Zezwala na ruch przez onpremsn1 OPFW.

Przekazywanie IP

Tabele tras i przekazywanie adresów IP to funkcje, których można używać w połączeniu, aby umożliwić urządzeniom wirtualnym sterowanie przepływem ruchu w sieci wirtualnej platformy Azure. Urządzenie wirtualne nie jest maszyną wirtualną, która uruchamia aplikację używaną do obsługi ruchu sieciowego w jakiś sposób, na przykład zapory lub urządzenia translacji adresów sieciowych.

Ta maszyna wirtualna urządzenia wirtualnego musi mieć możliwość odbierania ruchu przychodzącego, który nie jest kierowany do samego siebie. Aby umożliwić maszynie wirtualnej odbieranie ruchu adresowanego do innych miejsc docelowych, należy włączyć przekazywanie adresów IP dla maszyny wirtualnej. To ustawienie jest ustawieniem platformy Azure, a nie ustawieniem w systemie operacyjnym gościa. Urządzenie wirtualne nadal musi uruchamiać jakąś aplikację, aby obsługiwać ruch przychodzący 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 elementami onpremsn1 i onpremsn2.
  • Trasa zdefiniowana przez użytkownika połączona onpremsn1 z elementem określa, że cały ruch, który onpremsn2 ma być wysyłany do .OPFW

W tym momencie, jeśli onpremvm1 próbuje nawiązać połączenie z onpremvm2, trasa zdefiniowana przez użytkownika jest używana, a ruch jest wysyłany do OPFW jako następny przeskok. Rzeczywiste miejsce docelowe pakietu nie jest zmieniane. Nadal mówi, że onpremvm2 jest to miejsce docelowe.

Bez włączonego przekazywania adresów IP dla OPFWusługi logika sieci wirtualnej platformy Azure usuwa pakiety, ponieważ umożliwia wysyłanie pakietów tylko do maszyny wirtualnej, jeśli adres IP maszyny wirtualnej jest miejscem docelowym pakietu.

Dzięki przekierowywaniu adresów IP logika sieci wirtualnej platformy Azure przekazuje pakiety do OPFW, bez zmieniania oryginalnego adresu docelowego. OPFW musi obsługiwać pakiety i określać, co z nimi zrobić.

Aby poprzedni scenariusz działał, należy włączyć przekazywanie adresów IP na kart sieciowych dla OPFW, AZF1, AZF2i 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

Jak opisano wcześniej, przekazywanie adresów IP gwarantuje tylko, ż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 w urządzeniach.

OPFW

OPFW reprezentuje urządzenie lokalne, które zawiera 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 dwukierunkowy ruch między port2 i ONPREMAZURE.

AZF1

AZF1 reprezentuje urządzenie wirtualne platformy Azure, które zawiera następującą regułę:

Zasady: Zezwalaj na cały dwukierunkowy ruch między port1 i port2.

AZF2

AZF2 reprezentuje urządzenie wirtualne platformy Azure, które zawiera następującą regułę:

Zasady: Zezwalaj na cały dwukierunkowy ruch między port1 i port2.

AZF3

AZF3 reprezentuje urządzenie wirtualne platformy Azure, które zawiera następującą regułę:

Trasa: cały ruch do 192.168.0.0/16 (onpremvnet) musi być wysyłany do adresu IP bramy platformy Azure (tj. od 10.0.0.1) do port1adresu .

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 zapory.

Przychodzący

  • 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ących

Odmów całego ruchu do Internetu.

Ogólne kroki

Aby wdrożyć ten scenariusz, wykonaj następujące kroki:

  1. Zaloguj się do subskrypcji platformy Azure.

  2. Jeśli chcesz wdrożyć sieć wirtualną, aby naśladować sieć lokalną, wdróż zasoby będące częścią ONPREMRGprogramu .

  3. Wdróż zasoby, które są częścią elementu AZURERG.

  4. Wdróż tunel z onpremvnet do azurevnet.

  5. Po aprowizacji wszystkich zasobów zaloguj się do onpremvm2 usługi i wyślij polecenie ping 10.0.3.101, aby przetestować łączność między onpremsn2 i azsn3.