Wdrażanie urządzeń WUS o wysokiej dostępności

W tym artykule wyjaśniono najbardziej typowe opcje wdrażania zestawu wirtualnych urządzeń sieciowych (WUS) w celu zapewnienia wysokiej dostępności na platformie Azure. Urządzenie WUS jest zwykle używane do kontrolowania przepływu ruchu między segmentami sieci sklasyfikowanymi przy użyciu różnych poziomów zabezpieczeń, na przykład między siecią wirtualną De-Militarized (DMZ) a publicznym Internetem lub łączenie lokalizacji zewnętrznych z platformą Azure, takich jak urządzenia sieci VPN lub SDWAN (Software-Defined WAN).

Istnieje wiele wzorców projektowych, w których urządzenia WUS są używane do inspekcji ruchu między różnymi strefami zabezpieczeń, na przykład:

• Aby sprawdzić ruch wychodzący z maszyn wirtualnych do Internetu i uniemożliwić eksfiltrację danych.
• Aby sprawdzić ruch przychodzący z Internetu do maszyn wirtualnych i zapobiec atakom.
• Aby filtrować ruch między maszynami wirtualnymi na platformie Azure, aby zapobiec ruchom bocznym systemów, których bezpieczeństwo jest zagrożone.
• Aby filtrować ruch między systemami lokalnymi i maszynami wirtualnymi platformy Azure, jeśli są one uważane za należące do różnych poziomów zabezpieczeń. (Na przykład jeśli platforma Azure hostuje strefę DMZ i lokalnie aplikacje wewnętrzne).
• Aby przerwać tunele SIECI VPN lub SDWAN z lokalizacji zewnętrznych, takich jak sieci lokalne lub inne chmury publiczne.

Istnieje wiele przykładów urządzeń WUS, w tym między innymi następujących:

• Zapory sieciowe
• Odwrotne serwery proxy warstwy 4
• Punkty końcowe sieci VPN protokołu IPsec
• Urządzenia SDWAN
• Internetowe odwrotne serwery proxy z funkcją zapory aplikacji internetowej
• Internetowe serwery proxy, aby ograniczyć dostęp do stron internetowych z platformy Azure
• Moduły równoważenia obciążenia warstwy 7

Wszystkie te urządzenia WUS można wstawić do projektu platformy Azure przy użyciu wzorców opisanych w tym artykule. Nawet wirtualne urządzenia sieciowe pierwszej firmy platformy Azure, takie jak Azure Firewall i azure Application Gateway, korzystać z projektów opisanych w dalszej części tego artykułu. Zrozumienie tych opcji ma kluczowe znaczenie zarówno z perspektywy projektu, jak i podczas rozwiązywania problemów z siecią.

Pierwsze pytanie, na które należy odpowiedzieć, jest to, dlaczego wymagana jest wysoka dostępność dla wirtualnych urządzeń sieciowych. Przyczyną jest to, że te urządzenia kontrolują komunikację między segmentami sieci. Jeśli nie są dostępne, ruch sieciowy nie może przepływać, a aplikacje przestaną działać. Zaplanowane i nieplanowane awarie będą od czasu do czasu wyłączać wystąpienia urządzenia WUS (jak każda inna maszyna wirtualna na platformie Azure lub w innej chmurze). Wystąpienia są wyłączane, nawet jeśli te urządzenia WUS są skonfigurowane z dyskami zarządzanymi w warstwie Premium w celu zapewnienia umowy SLA z pojedynczym wystąpieniem na platformie Azure. W związku z tym aplikacje o wysokiej dostępności wymagają co najmniej drugiego urządzenia WUS, które może zapewnić łączność.

Wymagania wstępne: W tym artykule założono podstawową wiedzę na temat sieci platformy Azure, usługi Azure Load Balancersi routingu ruchu w sieci wirtualnej (UDR).

Podczas wybierania najlepszej opcji wdrożenia wirtualnego urządzenia sieciowego w sieci wirtualnej platformy Azure najważniejszym aspektem, który należy wziąć pod uwagę, jest to, czy dostawca urządzenia WUS zweryfikował i zweryfikował ten konkretny projekt. Dostawca musi również podać wymaganą konfigurację urządzenia WUS wymaganą do zintegrowania urządzenia WUS na platformie Azure. Jeśli dostawca urządzenia WUS oferuje różne alternatywy jako obsługiwane opcje projektowania urządzenia WUS, te czynniki mogą mieć wpływ na decyzję:

• Czas zbieżności: jak długo trwa w każdym projekcie kierowanie ruchu z dala od wystąpienia urządzenia WUS, które zakończyło się niepowodzeniem?
• Obsługa topologii: jakie konfiguracje urządzenia WUS obsługuje każda opcja projektowa? Aktywne/aktywne, aktywne/rezerwowe, skalowane w poziomie klastry NVA z nadmiarowością n+1?
• Symetria ruchu: czy określony projekt wymusza, aby urządzenie WUS wykonało translowanie adresów sieciowych źródła (SNAT) na pakietach, aby uniknąć routingu asymetrycznego? Czy też symetria ruchu jest wymuszana w inny sposób?

W poniższych sekcjach w dokumencie opisano najbardziej typowe architektury używane do integrowania urządzeń WUS z siecią piasty i szprych.

Omówienie architektur wysokiej dostępności

W poniższych architekturach opisano zasoby i konfigurację niezbędną dla urządzeń WUS o wysokiej dostępności:

Projekt modułu równoważenia obciążenia

Ten projekt używa dwóch modułów równoważenia obciążenia platformy Azure do uwidocznienia klastra urządzeń WUS w pozostałej części sieci. Takie podejście jest często używane zarówno w przypadku stanowych, jak i bezstanowych urządzeń WUS:

• Wewnętrzny moduł równoważenia obciążenia służy do przekierowywania ruchu wewnętrznego z platformy Azure i lokalnego do urządzeń WUS. Ten wewnętrzny moduł równoważenia obciążenia jest skonfigurowany przy użyciu reguł portów wysokiej dostępności, dzięki czemu każdy port TCP/UDP jest przekierowywany do wystąpień urządzenia WUS.
• Publiczny moduł równoważenia obciążenia uwidacznia urządzenia WUS w Internecie. Ponieważ porty wysokiej dostępności są przeznaczone dla ruchu przychodzącego, każdy pojedynczy port TCP/UDP musi być otwarty w dedykowanej regule równoważenia obciążenia.

Na poniższym diagramie opisano sekwencję przeskoków, które pakiety z Internetu do serwera aplikacji w sieci wirtualnej będącej szprychą śledziłyby przechodzenie przez wirtualne urządzenie WUS zapory w celu kontrolowania ruchu do/z publicznego Internetu (nazywanego również ruchem północnym/południowym):

Pobierz plik programu Visio dla tej architektury.

Mechanizm wysyłania ruchu z szprych do publicznego Internetu za pośrednictwem urządzeń WUS jest trasą User-Defined dla 0.0.0.0/0 z następnym przeskokiem wewnętrznego adresu IP modułu równoważenia obciążenia.

W przypadku ruchu między platformą Azure i publicznym Internetem każdy kierunek przepływu ruchu przechodzi przez inny moduł równoważenia obciążenia platformy Azure. Dzieje się tak, nawet jeśli urządzenie WUS zapory ma jedną kartę sieciową zarówno dla sieci publicznych, jak i wewnętrznych, ponieważ pakiet przychodzący przechodzi przez publiczną usługę ALB, a pakiet wychodzący przechodzi przez wewnętrzną usługę ALB. Ponieważ oba kierunki przepływu przechodzące przez różne moduły równoważenia obciążenia, jeśli wymagana jest symetria ruchu, tak jak zwykle w przypadku większości zapór, źródłowe tłumaczenie adresów sieciowych (SNAT) musi być wykonywane przez wystąpienia urządzenia WUS w celu przyciągnięcia ruchu zwrotnego i uniknięcia asymetrii ruchu.

Ten sam projekt z modułami równoważenia obciążenia może być również używany do sprawdzania ruchu między platformą Azure i sieciami lokalnymi (wschód/zachód), w przypadku którego jest zaangażowany tylko wewnętrzny moduł równoważenia obciążenia:

Mechanizm wysyłania ruchu między szprychami za pośrednictwem urządzeń WUS jest dokładnie taki sam, więc nie podano żadnego innego diagramu. Na powyższych przykładowych diagramach, ponieważ szprycha1 nie wie o zakresie szprychy, trasa zdefiniowana przez użytkownika 0.0.0.0/0 wysyła ruch skierowany do szprychy2 do wewnętrznego modułu równoważenia obciążenia urządzenia WUS.

W przypadku ruchu między sieciami lokalnymi a platformą Azure lub między maszynami wirtualnymi platformy Azure symetria ruchu jest gwarantowana w urządzeniach WUS z jedną kartą sieciową przez wewnętrzny moduł równoważenia obciążenia platformy Azure: gdy oba kierunki przepływu ruchu przechodzą przez ten sam moduł równoważenia obciążenia azure Load Balancer, to samo wystąpienie urządzenia WUS zostanie wybrane przez moduł równoważenia obciążenia. W przypadku urządzeń WUS z podwójną kartą sieciową, w których istnieje wewnętrzny moduł równoważenia obciążenia dla każdego poczucia komunikacji, symetria ruchu musi być dostarczana za pośrednictwem SNAT, jak w powyższym przykładzie północ/południe.

Innym wyzwaniem, przed którym stoją urządzenia WUS z podwójną kartą sieciową w tym projekcie, jest wysłanie odpowiedzi z powrotem do kontroli kondycji modułu równoważenia obciążenia. Usługa Azure Load Balancer zawsze używa tego samego adresu IP co źródło kontroli kondycji (168.63.129.16). Urządzenie WUS musi mieć możliwość wysłania odpowiedzi do kontroli kondycji pochodzącej z tego adresu IP w tym samym interfejsie, który został odebrany. Zwykle wymaga to wielu tabel routingu w systemie operacyjnym, ponieważ routing oparty na miejscu docelowym wysyła odpowiedź na kontrole kondycji zawsze za pośrednictwem tej samej karty sieciowej.

Usługa Azure Load Balancer ma dobry czas zbieżności w przypadku awarii poszczególnych urządzeń WUS. Ponieważ sondy kondycji mogą być wysyłane co 5 sekund i trwa 3 nieudane sondy w celu zadeklarowania wystąpienia zaplecza poza usługą, zwykle trwa to 10–15 sekund, aby usługa Azure Load Balancer konwerwerowała ruch do innego wystąpienia urządzenia WUS.

Ta konfiguracja obsługuje zarówno konfiguracje aktywne/aktywne, jak i aktywne/rezerwowe. W przypadku konfiguracji aktywnych/rezerwowych wystąpienia urządzenia WUS muszą oferować port TCP/UDP lub punkt końcowy HTTP, który odpowiada tylko na sondy kondycji modułu równoważenia obciążenia dla wystąpienia, które znajduje się w aktywnej roli.

Korzystanie z modułów równoważenia obciążenia L7

Konkretny przypadek tego projektu dla urządzeń zabezpieczeń zastępuje publiczny moduł równoważenia obciążenia platformy Azure modułem równoważenia obciążenia warstwy 7, takim jak azure Application Gateway (które można samodzielnie traktować jako urządzenie WUS). W tym przypadku urządzenia WUS wymagają tylko wewnętrznego modułu równoważenia obciążenia dla ruchu pochodzącego z systemów obciążeń. Ten mechanizm jest czasami używany przez urządzenia z podwójną kartą sieciową, aby uniknąć problemu z routingiem z kontrolami kondycji usługi Azure Load Balancer opisanymi w poprzedniej sekcji. Jednym z ograniczeń tego projektu jest to, że obsługuje tylko protokoły warstwy 7 obsługiwane przez moduł równoważenia obciążenia warstwy 7, zazwyczaj HTTP(S).

Urządzenie WUS powinno przyjmować ruch przychodzący dla protokołów nieobsługiwanych przez moduł równoważenia obciążenia warstwy 7 oraz potencjalnie cały ruch wychodzący. Aby uzyskać więcej informacji na temat tej konfiguracji w przypadku używania usługi Azure Firewall jako urządzenia WUS i usługi Azure Application Gateway jako internetowego zwrotnego serwera proxy w warstwie 7, zobacz Firewall and Application Gateway for virtual networks.

Azure Route Server

azure Route Server to usługa, która umożliwia urządzeniu WUS interakcję z siecią SDN platformy Azure za pośrednictwem protokołu BGP (Border Gateway Protocol). Nie tylko urządzenia WUS uczą się, które prefiksy adresów IP istnieją w sieciach wirtualnych platformy Azure, ale są w stanie wstrzyknąć trasy w obowiązujących tabelach tras maszyn wirtualnych na platformie Azure.

Na diagramie powyżej każde wystąpienie urządzenia WUS jest równorzędne za pośrednictwem protokołu BGP z usługą Azure Route Server. W podsieciach szprych nie jest wymagana żadna tabela tras, ponieważ usługa Azure Route Server programuje trasy anonsowane przez urządzenia WUS. Jeśli co najmniej dwie trasy są programowane na maszynach wirtualnych platformy Azure, używają równego kosztu wielościeżkowego (ECMP), aby wybrać jedno z wystąpień urządzenia WUS dla każdego przepływu ruchu. W związku z tym SNAT jest koniecznością w tym projekcie, jeśli symetria ruchu jest wymagana.

Ta metoda wstawiania obsługuje zarówno aktywne/aktywne (wszystkie urządzenia WUS anonsują te same trasy do serwera usługi Azure Route Server), jak i aktywne/wstrzymanie (jedno urządzenie WUS anonsuje trasy z krótszą ścieżką AS niż druga). Usługa Azure Route Server obsługuje maksymalnie 8 adjacencies protokołu BGP. W związku z tym w przypadku korzystania z klastra skalowalnego w poziomie aktywnych urządzeń WUS ten projekt obsługuje maksymalnie 8 wystąpień urządzenia WUS.

Czas zbieżności jest szybki w tej konfiguracji i jest pod wpływem czasomierzy keepalive i holdtime sąsiedztwa protokołu BGP. Chociaż serwer usługi Azure Route Server ma domyślne czasy utrzymania aktywności i czasu wstrzymania (odpowiednio 60 sekund i 180 sekund), urządzenia WUS mogą negocjować niższe czasomierze podczas ustanowienia sąsiedztwa protokołu BGP. Ustawienie tych czasomierzy zbyt niskie może prowadzić do niestabilności protokołu BGP.

Ten projekt jest najbardziej typową opcją dla urządzeń WUS, które wymagają interakcji z routingiem platformy Azure, na przykład sdWAN lub IPsec NVA, które zwykle mają dobrą obsługę protokołu BGP i muszą poznać prefiksy skonfigurowane w sieciach wirtualnych platformy Azure lub anonsować niektóre trasy za pośrednictwem prywatnej komunikacji równorzędnej usługi ExpressRoute. Ten typ urządzeń jest zwykle bezstanowy, więc symetria ruchu nie jest problemem, więc SNAT nie jest wymagany.

Moduł równoważenia obciążenia bramy

usługi Azure Gateway Load Balancer to nowy sposób wstawiania urządzeń WUS w ścieżce danych bez konieczności kierowania ruchem przy użyciu tras User-Defined. W przypadku maszyn wirtualnych, które uwidaczniają obciążenia za pośrednictwem usługi Azure Load Balancer lub publicznego adresu IP, ruch przychodzący i wychodzący może być przekierowywany w sposób niewidoczny dla klastra urządzeń WUS znajdujących się w innej sieci wirtualnej. Na poniższym diagramie opisano ścieżkę obserwowaną przez pakiety dla ruchu przychodzącego z publicznego Internetu, jeśli obciążenia uwidaczniają aplikację za pośrednictwem usługi Azure Load Balancer:

Jedną z głównych zalet tej metody wstrzykiwania urządzenia WUS jest to, że źródłowe tłumaczenie adresów sieciowych (SNAT) nie jest wymagane do zagwarantowania symetrii ruchu. Inną zaletą tej opcji projektowej jest to, że te same urządzenia WUS mogą służyć do inspekcji ruchu do/z różnych sieci wirtualnych, co zapewnia wielodostępność z perspektywy urządzenia WUS. Żadna komunikacja równorzędna sieci wirtualnych nie jest wymagana między siecią wirtualną urządzenia WUS a sieciami wirtualnymi obciążenia, a w sieci wirtualnej obciążenia nie są wymagane żadne trasy User-Defined, co znacznie upraszcza konfigurację.

Iniekcja usługi za pomocą modułu równoważenia obciążenia bramy może służyć do przepływów przychodzących osiągających publiczny moduł równoważenia obciążenia platformy Azure (i ich ruch powrotny) oraz przepływów wychodzących pochodzących z platformy Azure. East-West ruchu między maszynami wirtualnymi platformy Azure nie można wykorzystać modułu równoważenia obciążenia bramy na potrzeby iniekcji urządzenia WUS.

W klastrze urządzenia WUS sondy sprawdzania kondycji usługi Azure Load Balancer są używane do wykrywania awarii poszczególnych wystąpień urządzenia WUS, co zapewnia szybki czas zbieżności (10–15 sekund).

Zmienianie PIP-UDR

Chodzi o to, aby konfiguracja była wymagana bez nadmiarowości urządzenia WUS i została zmodyfikowana w przypadku, gdy urządzenie WUS cierpi na przestoje. Na poniższym diagramie pokazano, jak publiczny adres IP platformy Azure jest skojarzony z aktywnym urządzeniem WUS (WUS1), a trasy User-Defined w szprychach mają aktywny adres IP urządzenia WUS jako następny przeskok (10.0.0.37).

/UDR

Jeśli aktywne urządzenie WUS stanie się niedostępne, rezerwowe urządzenie WUS wywoła interfejs API platformy Azure, aby ponownie zamapować publiczny adres IP i szprychę User-Defined trasy do siebie (lub przenieść prywatny adres IP). Te wywołania interfejsu API mogą potrwać kilka minut, dlatego ten projekt oferuje najgorszy czas zbieżności wszystkich opcji w tym dokumencie.

Innym ograniczeniem tego projektu jest to, że obsługiwane są tylko konfiguracje aktywne/rezerwowe, co może prowadzić do problemów ze skalowalnością: jeśli trzeba zwiększyć przepustowość obsługiwaną przez urządzenia WUS, jedyną opcją tego projektu jest skalowanie w górę obu wystąpień.

Jedną z zalet tego projektu jest to, że do zagwarantowania symetrii ruchu nie jest wymagane żadne translowanie adresów sieciowych (Source Network Address Translation, SNAT), ponieważ w danym momencie jest aktywne tylko jedno urządzenie WUS.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główni autorzy:

• Keith Mayer | Główny architekt rozwiązań w chmurze
• Telmo Sampaio | Główny menedżer inżynierów usług
• Jose Moreno | Główny inżynier

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Dowiedz się, jak zaimplementować bezpieczną sieć hybrydową przy użyciu usługi Azure Firewall.
• sieci obwodowe — cloud adoption Framework
• Cloud DMZ — Cloud Adoption Framework