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 z różnymi poziomami zabezpieczeń, na przykład między siecią wirtualną strefy demilitaryzowanej (DMZ) i publicznym Internetem.
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).
Istnieje wiele przykładów urządzeń WUS, takich jak zapory sieciowe, odwrotne serwery proxy warstwy 4, punkty końcowe sieci VPN protokołu IPsec, internetowe odwrotne serwery proxy z funkcją zapory aplikacji internetowej, internetowe serwery proxy, aby ograniczyć, do których stron internetowych można uzyskiwać dostęp z platformy Azure, modułów równoważenia obciążenia warstwy 7 i wielu innych. Wszystkie z nich 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 Usługa Azure Firewall i aplikacja systemu Azure Gateway, używają 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 mogą i od czasu do czasu spowodują wyłączenie wystąpień urządzenia WUS (jak każda inna maszyna wirtualna na platformie Azure lub w dowolnej innej chmurze). Wystąpienia są wyłączane nawet wtedy, gdy te urządzenia WUS są skonfigurowane z usługą Premium Dyski zarządzane w celu zapewnienia umowy SLA z pojedynczym wystąpieniem na platformie Azure. W związku z tym aplikacje o wysokiej dostępności będą wymagać 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, modułów równoważenia obciążenia platformy Azure i 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.
Uwaga
Ten artykuł koncentruje się na projektach piast i szprych. Usługa Virtual WAN nie jest omówiona, ponieważ usługa Virtual WAN jest o wiele bardziej nakazowa dotycząca sposobu wdrażania urządzeń WUS, w zależności od tego, czy określone urządzenie WAN jest obsługiwane w koncentratorach usługi Virtual WAN. Aby uzyskać więcej informacji, zobacz Wirtualne urządzenia sieciowe w koncentratorze usługi Virtual WAN.
Omówienie architektur wysokiej dostępności
Następujące architektury opisują konfigurację i zasoby niezbędne dla urządzeń WUS wysokiej dostępności:
| Rozwiązanie | Świadczenia | Kwestie wymagające rozważenia |
|---|---|---|
| Azure Load Balancer | Obsługuje aktywne/aktywne, aktywne/rezerwowe i skalowane w poziomie urządzenia WUS. Bardzo dobry czas zbieżności | Urządzenie WUS musi zapewnić port dla sond kondycji, zwłaszcza w przypadku wdrożeń aktywnych/rezerwowych. Przepływy do/z Internetu wymagają SNAT dla symetrii |
| Azure Route Server | Urządzenie WUS musi obsługiwać protokół BGP. Obsługuje aktywne/aktywne, aktywne/rezerwowe i skalowane w poziomie urządzenia WUS. | Symetria ruchu wymaga SNAT |
| Moduł równoważenia obciążenia bramy | Symetria ruchu gwarantowana bez protokołu SNAT. Urządzenia WUS mogą być współużytkowane przez dzierżawy. Bardzo dobry czas zbieżności. Obsługuje aktywne/aktywne, aktywne/rezerwowe i skalowane w poziomie urządzenia WUS. | Obsługuje przepływy do/z Internetu, bez przepływów Wschód-Zachód |
| Zmiana trasy PIP/trasy zdefiniowanej przez użytkownika | Brak specjalnej funkcji wymaganej przez urządzenie WUS. Gwarantuje ruch symetryczny | Tylko w przypadku projektów aktywnych/pasywnych. Wysoki czas zbieżności 1–2 minut |
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:
- 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 z regułami 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 pakietów z Internetu do serwera aplikacji w sieci wirtualnej będącej szprychą:
Pobierz plik programu Visio z tą architekturą.
Mechanizm wysyłania ruchu z szprych do publicznego Internetu za pośrednictwem urządzeń WUS jest trasą zdefiniowaną przez użytkownika 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 a publicznym Internetem każdy kierunek przepływu ruchu będzie przechodzić przez inny moduł równoważenia obciążenia platformy Azure (pakiet przychodzący za pośrednictwem publicznej usługi ALB i pakiet ruchu wychodzącego za pośrednictwem wewnętrznego modułu równoważenia obciążenia). W związku z tym, jeśli wymagana jest symetria ruchu, należy wykonać translowanie adresów sieciowych (SNAT, Source Network Address Translation) przez wystąpienia urządzenia WUS, aby przyciągnąć ruch powrotny i uniknąć asymetrii ruchu.
Ten projekt może służyć również do sprawdzania ruchu między platformą Azure i sieciami lokalnymi:
Mechanizm wysyłania ruchu między szprychami za pośrednictwem urządzeń WUS jest dokładnie taki sam, więc nie podano żadnego dodatkowego diagramu. Na powyższych przykładowych diagramach, ponieważ szprycha1 nie wie o zakresie szprychy, 0.0.0.0/0 trasa zdefiniowana przez użytkownika wyśle ruch skierowany do szprychy do wewnętrznej usługi Azure Load Balancer urządzenia WUS.
W przypadku ruchu między sieciami lokalnymi a platformą Azure lub między maszynami wirtualnymi platformy Azure symetria ruchu jest gwarantowana przez wewnętrzną usługę Azure Load Balancer: gdy oba kierunki przepływu ruchu przechodzą przez tę samą usługę Azure Load Balancer, zostanie wybrane to samo wystąpienie urządzenia WUS.
Usługa Azure Load Balancer ma bardzo 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 zbiegła ruch do innego wystąpienia urządzenia WUS.
Ta konfiguracja obsługuje zarówno konfiguracje aktywne/aktywne, jak i aktywne/rezerwowe. Jednak w przypadku konfiguracji aktywnych/rezerwowych wystąpienia urządzenia WUS muszą oferować port TCP/UDP lub punkt końcowy HTTP, który nie odpowiada na sondy kondycji modułu równoważenia obciążenia, chyba że wystąpienie jest w aktywnej roli.
Korzystanie z modułów równoważenia obciążenia L7
Konkretny przypadek tego projektu zastępuje publiczny moduł równoważenia obciążenia platformy Azure modułem równoważenia obciążenia warstwy 7, takim jak brama aplikacja systemu Azure (którą można samodzielnie traktować jako urządzenie WUS). W takim przypadku urządzenia WUS będą wymagać tylko wewnętrznego modułu równoważenia obciążenia przed nimi, ponieważ ruch z usługi Application Gateway będzie pozyskiwany z wewnątrz sieci wirtualnej, a asymetria ruchu nie jest problemem.
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 bramy aplikacja systemu Azure jako internetowego zwrotnego serwera proxy warstwy 7, zobacz Zapora i usługa Application Gateway dla sieci wirtualnych.
Azure Route Server
Azure Route Server to usługa, która umożliwia urządzeniu WUS interakcję z usługą Azure SDN za pośrednictwem protokołu BGP (Border Gateway Protocol). Nie tylko urządzenia WUS dowiedzą się, które prefiksy adresów IP istnieją w sieciach wirtualnych platformy Azure, ale będą mogły wprowadzać 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 będzie programować trasy anonsowane przez urządzenia WUS. Jeśli co najmniej dwie trasy są programowane na maszynach wirtualnych platformy Azure, użyją one 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 usługi Azure Route Server), jak i aktywne/rezerwowe (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 będzie obsługiwać maksymalnie 8 wystąpień urządzenia WUS.
Czas zbieżności jest dość szybki w tej konfiguracji i będzie pod wpływem czasomierzy keepalive i holdtime adjacency 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 urządzeń WUS kończenia sieci VPN, które 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.
Moduł równoważenia obciążenia bramy
Usługa Azure Gateway Load Balancer to nowy sposób wstawiania urządzeń WUS w ścieżce danych bez konieczności kierowania ruchem za pomocą tras zdefiniowanych przez użytkownika. 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 zdefiniowane przez użytkownika, co znacznie upraszcza konfigurację.
Iniekcja usługi z modułem równoważenia obciążenia bramy może służyć do przepływów przychodzących, które trafiają do publicznego modułu równoważenia obciążenia platformy Azure (i ich ruchu powrotnego), a także dla przepływów wychodzących pochodzących z platformy Azure. Ruch wschodnio-zachodni między maszynami wirtualnymi platformy Azure nie może korzystać z 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 będą używane do wykrywania awarii poszczególnych wystąpień urządzenia WUS, osiągając bardzo szybki czas zbieżności (10–15 sekund).
Zmiana trasy 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 zdefiniowane przez użytkownika w szprychach mają aktywny adres IP urządzenia WUS jako następny przeskok (10.0.0.37).
Jeśli aktywne urządzenie WUS stało się niedostępne, urządzenie WUS w stanie wstrzymania wywoła interfejs API platformy Azure, aby ponownie zamapować publiczny adres IP i trasy zdefiniowane przez użytkownika na 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.
Autorzy zabezpieczeń:
- Keith Mayer | Główny architekt rozwiązań w chmurze
- Telmo Sampaio | Główny menedżer inżynierów usług
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