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

W tym artykule opisano typowe sposoby wdrażania zestawu wirtualnych urządzeń sieciowych (WUS) w celu zapewnienia wysokiej dostępności na platformie Azure. Urządzenie NVA zwykle kontroluje przepływ ruchu między segmentami sieci, które mają różne poziomy zabezpieczeń. Można na przykład użyć urządzenia sieciowego NVA między wirtualną siecią obwodową a publicznym Internetem, lub połączyć lokalizacje zewnętrzne z platformą Azure za pomocą wirtualnej sieci prywatnej (VPN) lub urządzeń WAN definiowanych programowo (SD-WAN).

W tym artykule założono, że masz podstawową wiedzę na temat sieci platformy Azure, modułów równoważenia obciążenia platformy Azure, routingu ruchu w sieci wirtualnej i tras zdefiniowanych przez użytkownika (UDR).

Wiele wzorców projektowych używa urządzeń NVA do inspekcji ruchu między różnymi strefami zabezpieczeń. Te wzorce mogą używać NVAs do następujących celów:

• 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, zwłaszcza jeśli należą do różnych poziomów zabezpieczeń. Na przykład platforma Azure hostuje sieć obwodową, podczas gdy środowisko lokalne hostuje aplikacje wewnętrzne.

• Aby zakończyć działanie sieci VPN lub tuneli SD-WAN z lokalizacji zewnętrznych, takich jak sieci lokalne lub inne chmury publiczne.

Następujące wirtualne urządzenia sieciowe można dodać do projektu platformy Azure, korzystając z wzorców opisanych w tym artykule.

• Zapory sieciowe
• Odwrotne serwery proxy warstwy 4
• Punkty końcowe VPN IPsec (zabezpieczenia protokołu internetowego)
• urządzenia SD-WAN
• Internetowe odwrotne serwery proxy z funkcją zapory aplikacji webowej
• Internetowe serwery proxy, aby ograniczyć dostęp do stron internetowych z platformy Azure
• Moduły równoważenia obciążenia warstwy 7

Natywne dla Azure'a wirtualne urządzenia sieciowe (NVA), takie jak Azure Firewall i Azure Application Gateway, używają projektów opisanych w dalszej części tego artykułu. Te opcje należy zrozumieć z perspektywy projektu i do celów rozwiązywania problemów z siecią.

Urządzenia WUS często wymagają wysokiej dostępności, ponieważ kontrolują komunikację między segmentami sieci. Jeśli urządzenia NVA staną się niedostępne, ruch sieciowy nie może przepływać, a aplikacje przestaną działać. Zaplanowane i nieplanowane przestoje czasami wyłączają instancje NVA, podobnie jak inne maszyny wirtualne na platformie Azure lub w innych chmurach. Instancje NVA mogą zostać zamknięte nawet po skonfigurowaniu ich przy użyciu dysków SSD Premium Azure, które zapewniają gwarancję poziomu usług dla jednej instancji w Azure. Aplikacje o wysokiej dostępności wymagają co najmniej dwóch NVA, aby pomóc w zapewnieniu łączności.

W przypadku wybrania najlepszej opcji wdrożenia urządzenia WUS w sieci wirtualnej platformy Azure najważniejszy aspekt polega na tym, czy dostawca urządzenia WUS ocenił i zweryfikował swój projekt. Dostawca musi również podać wymaganą konfigurację NVA w celu zintegrowania NVA z platformą Azure. Jeśli dostawca urządzenia WUS udostępnia wiele obsługiwanych opcji projektowania, rozważ następujące czynniki, aby podjąć decyzję:

• Czas zbieżności: Czas potrzebny każdemu projektowi sieci na przekierowanie ruchu z dala od uszkodzonego urządzenia NVA.

• Obsługa topologii: Konfiguracje urządzenia NVA obsługiwane przez poszczególne opcje projektowe, takie jak aktywne/aktywne, aktywne/rezerwowe lub skalowalne klastry NVA, które posiadają dodatkową jednostkę dla nadmiarowości.

• Symetria ruchu: Czy określony projekt wymusza, aby urządzenie NVA wykonywało translację adresów sieciowych źródła (SNAT) na pakietach, aby uniknąć trasowania asymetrycznego, czy też projekt wymusza symetrię ruchu w inny sposób

Uwaga / Notatka

Ten artykuł koncentruje się na projektach piasty i szprych. W tym artykule nie omówiono Azure Virtual WAN, ponieważ zapewnia ona bardziej szczegółowe wytyczne dotyczące wdrażania NVA, w zależności od tego, czy koncentrator usługi Virtual WAN obsługuje określoną NVA. Aby uzyskać więcej informacji, odwiedź stronę NVAs w hubie usługi Virtual WAN.

W poniższych sekcjach opisano typowe architektury, których można używać do integrowania urządzeń WUS z siecią piasty i szprych.

Omówienie architektur wysokiej dostępności

Rozwiązanie	Korzyści	Rozważania
Azure Load Balancer	To rozwiązanie obsługuje konfiguracje aktywne/aktywne i aktywne/rezerwowe oraz skalowanie poziome wirtualnych urządzeń sieciowych z krótkim czasem zbieżności.	Urządzenie WUS musi zapewnić port dla sond kondycji, zwłaszcza w przypadku wdrożeń aktywnych/rezerwowych. W przypadku urządzeń stanowych, takich jak zapory wymagające symetrii ruchu, przepływy do i z Internetu wymagają protokołu SNAT.
Azure Route Server	Urządzenie NVA musi obsługiwać BGP (Border Gateway Protocol). To rozwiązanie obsługuje aktywne/aktywne, aktywne/zapasowe i skalowane w poziomie urządzenia NVA.	Symetria ruchu wymaga protokołu SNAT w tym rozwiązaniu.
Moduł równoważenia obciążenia usługi Azure Gateway	Symetria ruchu jest gwarantowana bez protokołu SNAT. Urządzenia WUS mogą być współużytkowane przez dzierżawy. To rozwiązanie ma dobry czas zbieżności i obsługuje aktywne/aktywne, aktywne/pasywne oraz skalowanie wirtualnych urządzeń sieciowych.	To rozwiązanie obsługuje przepływy do i z Internetu, ale nie obsługuje przepływów East-West.
Dynamiczny prywatny adres IP i trasa zdefiniowana przez użytkownika	NVA nie wymaga specjalnych cech. To rozwiązanie gwarantuje symetryczny ruch.	To rozwiązanie dotyczy tylko projektów aktywnych/pasywnych. Ma wysoki czas zbieżności od jednej do dwóch minut.

Równoważnik obciążenia

Projekt równoważnika obciążenia używa dwóch równoważników obciążenia platformy Azure, aby udostępnić klaster NVA w pozostałej części sieci. Podejście odpowiada zarówno stanowym, jak i bezstanowym urządzeniom NVA.

• Wewnętrzny moduł równoważenia obciążenia przekierowuje ruch wewnętrzny z platformy Azure oraz środowisk lokalnych do wirtualnych urządzeń sieciowych. Ten wewnętrzny moduł równoważenia obciążenia jest skonfigurowany z regułami portów wysokiej dostępności, co powoduje, że każdy port protokołu TCP (Transmission Control Protocol) i UDP (User Datagram Protocol) jest przekierowywany do instancji NVA.

• Publiczny moduł równoważenia obciążenia uwidacznia urządzenia WUS w Internecie. Porty wysokiej dostępności są przeznaczone dla ruchu przychodzącego, dlatego każdy port TCP/UDP musi być otwarty w dedykowanej regule równoważenia obciążenia.

Na poniższym diagramie przedstawiono sekwencję przeskoków, które pakiety przemieszczają się z Internetu do serwera aplikacji w wirtualnej sieci w układzie szprychy. Te pakiety przechodzą przez zaporę NVA, aby kontrolować ruch do i z publicznego Internetu, nazywanego również ruchemNorth-South.

Ten diagram przedstawia piastę i dwie szprychy. Koncentrator zawiera podsieć bramy oraz podsieć urządzenia wirtualnego NVA. Podsieć bramy zawiera sieć VPN lub bramę usługi Azure ExpressRoute. Podsieć NVA zawiera wewnętrzny moduł równoważenia obciążenia platformy Azure i NVAs. Każda szprycha zawiera serwer aplikacji. Spoke2 zawiera notatkę, która informuje o trasie szprych 0.0.0.0/0 do 10.0.0.36 i wyłączeniu propagacji bramy. Ruch przychodzący przepływa z publicznego Internetu do NVAs za pośrednictwem publicznego modułu równoważenia obciążenia Azure. Następnie ten ruch przepływa do serwera aplikacji w usłudze Spoke2. Zwraca ruch z tego serwera aplikacji do wirtualnych urządzeń sieciowych NVAs za pośrednictwem wewnętrznego modułu równoważenia obciążenia platformy Azure. Następnie ten ruch przepływa do publicznego Internetu.

Pobierz plik programu Visio tej architektury.

Aby wysyłać ruch z węzłów do publicznego Internetu za pośrednictwem urządzeń NVA, ten projekt używa trasy zdefiniowanej przez użytkownika dla 0.0.0.0/0. Następny krok to adres IP wewnętrznego rozwiązania dla równoważenia obciążenia.

W przypadku ruchu między platformą Azure a publicznym Internetem każdy kierunek przepływu ruchu przechodzi przez inny moduł równoważenia obciążenia platformy Azure. Ten proces występuje nawet wtedy, gdy zapora NVA ma jedną kartę interfejsu sieciowego (NIC) dla obu sieci - publicznej i wewnętrznej, ponieważ pakiet przychodzący przechodzi przez publiczny moduł równoważenia obciążenia Azure, a pakiet wychodzący przechodzi przez wewnętrzny moduł równoważenia obciążenia Azure. Oba kierunki przepływu przechodzą przez różne moduły równoważenia obciążenia. Jeśli więc potrzebujesz symetrii ruchu, instancje NVA muszą wykonać SNAT, aby spowodować powrót ruchu i zapewnić symetrię ruchu. Większość zapór wymaga symetrii ruchu.

Na poniższym diagramie pokazano, jak używać tego samego projektu równoważnika obciążenia do sprawdzania ruchu pomiędzy platformą Azure a sieciami lokalnymi, czyli ruchu East-West, który obejmuje tylko wewnętrzny równoważnik obciążenia. Za pomocą tej metody można również wysyłać ruch między szprychami za pośrednictwem urządzeń WUS.

Ten diagram przedstawia piastę i dwie szprychy. Koncentrator zawiera podsieć bramy i podsieć NVA. Podsieć bramy zawiera bramę VPN lub bramę ExpressRoute. Podsieć NVA zawiera wewnętrzny moduł równoważenia obciążenia Azure i NVA. Każda szprycha zawiera serwer aplikacji. Spoke2 ma notatkę, która zawiera informację o trasie rozgałęzienia z 0.0.0.0/0 do 10.0.0.36 i wyłącza propagację bramy. Ruch przychodzący przepływa ze środowiska lokalnego do wirtualnych urządzeń sieciowych za pośrednictwem bramy sieciowej VPN lub usługi ExpressRoute, a następnie do wewnętrznego modułu równoważenia obciążenia w platformie Azure. Następnie ten ruch przepływa do serwera aplikacji w usłudze Spoke2. Ruch powrotny przepływa z tego serwera aplikacji do urządzeń wirtualnych sieciowych (NVAs) za pośrednictwem wewnętrznego modułu równoważenia obciążenia platformy Azure. Następnie ten ruch przepływa do środowiska lokalnego za pośrednictwem bramy sieci VPN lub usługi ExpressRoute.

Na poprzednich diagramach szprycha1 nie wie o zasięgu szprych2. W związku z tym, 0.0.0.0/0 UDR wysyła ruch przeznaczony dla spoke2 do wewnętrznego modułu równoważenia obciążenia sieci NVA w platformie Azure.

W przypadku ruchu między sieciami lokalnymi a platformą Azure lub między maszynami wirtualnymi w Azure, symetria ruchu jest gwarantowana w sieciowych urządzeniach wirtualnych (NVAs) z jedną kartą sieciową przez wewnętrzny moduł równoważenia obciążenia Azure. Gdy oba kierunki przepływu ruchu przechodzą przez ten sam moduł równoważenia obciążenia platformy Azure, moduł równoważenia obciążenia wybiera to samo wystąpienie urządzenia WUS w obu kierunkach. Jeśli projekt urządzenia sieciowego NVA z dwiema kartami sieciowymi ma wewnętrzny równoważnik obciążenia dla każdego kierunku komunikacji, funkcja SNAT zapewnia symetrię ruchu. Na poprzednim diagramie North-South przedstawiono przykład tego projektu.

W tym projekcie NVA z dwiema kartami sieciowymi muszą określić, gdzie wysyłać odpowiedzi na kontrole kondycji równoważnika obciążenia. Usługa Load Balancer zawsze używa tego samego adresu IP co źródło kontroli kondycji, czyli 168.63.129.16. Urządzenie NVA musi wysłać te odpowiedzi z kontroli stanu przez ten sam interfejs, na którym zostały odebrane. Ten proces zwykle wymaga wielu tabel routingu w systemie operacyjnym, ponieważ routing oparty na miejscu docelowym wysyła odpowiedzi za pośrednictwem tej samej karty sieciowej.

Moduł równoważenia obciążenia platformy Azure ma dobry czas zbieżności w poszczególnych awariach urządzenia NVA. Sondy kondycji można wysyłać co pięć sekund, a po trzech nieudanych sondach instancja zaplecza jest oznaczana jako poza usługą. Zwykle trwa to od 10 do 15 sekund, zanim moduł równoważenia obciążenia platformy Azure przekieruje ruch do innego wystąpienia NVA.

Ta konfiguracja obsługuje zarówno konfiguracje aktywne/aktywne, jak i aktywne/rezerwowe. W konfiguracjach aktywne/rezerwowe wystąpienia NVA muszą udostępniać port TCP lub UDP albo punkt końcowy HTTP, który odpowiada wyłącznie na sondy sprawdzające zdrowie równoważnika obciążenia dla wystąpienia aktualnie pełniącego aktywną rolę.

Moduły równoważenia obciążenia warstwy 7

Specyficzny projekt 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 usługa Azure Application Gateway, która może być również uważana za NVA.

W tym scenariuszu urządzenia WUS wymagają tylko wewnętrznego modułu równoważenia obciążenia dla ruchu z systemów obciążeń. Dual-NIC urządzenia czasami stosują to podejście, aby uniknąć problemów z routingiem podczas sprawdzania kondycji modułu równoważenia obciążenia platformy Azure. Ten projekt obsługuje tylko protokoły warstwy 7 obsługiwane przez moduł równoważenia obciążenia warstwy 7, czyli zazwyczaj HTTP i HTTPS.

Urządzenie NVA powinno obsługiwać ruch przychodzący dla protokołów, których moduł równoważenia obciążenia warstwy 7 nie obsługuje. Urządzenie NVA może także obsługiwać ruch wychodzący. Aby uzyskać więcej informacji, zobacz Zapora i brama aplikacji dla sieci wirtualnych.

Serwer trasowania

Route Server to usługa, która umożliwia urządzeniu WUS interakcję z siecią zdefiniowaną przez oprogramowanie platformy Azure za pośrednictwem protokołu BGP. NVAs uczą się, które prefiksy adresów IP istnieją w sieciach wirtualnych Azure. Mogą również wprowadzać trasy do obowiązujących tabel tras maszyn wirtualnych na platformie Azure.

Ten diagram przedstawia piastę i dwie szprychy. Koncentrator zawiera podsieć bramy, podsieć urządzenia wirtualnego NVA i podsieć serwera routingu. Podsieć bramy zawiera bramę VPN lub ExpressRoute. Podsieć NVA zawiera dwa wirtualne urządzenia sieciowe. Podsieć usługi Route Server zawiera serwer Route Server. Każda szprycha zawiera serwer aplikacji. Spoke2 ma notatkę, która odczytuje obowiązujące trasy szprych 0.0.0.0/0 do 10.0.0.37 i 0.0.0.0/0 do 10.0.0.38. Ruch przychodzący przepływa z ogólnodostępnego internetu do NVA1 za pośrednictwem publicznego równoważnika obciążenia platformy Azure. Następnie ten ruch przepływa do serwera aplikacji w usłudze Spoke2. Zwraca ruch z tego serwera aplikacji do urządzenia WUS1, a następnie do publicznego Internetu. Sąsiedztwo BGP łączy NVA1, NVA2 i Route Server. NVA2 i Route Server są połączone za pośrednictwem protokołu eBGP.

Na poprzednim diagramie każda instancja NVA łączy się z usługą Route Server przez BGP. Ten projekt nie wymaga tabeli tras w podsieciach spoke, ponieważ Route Server programuje trasy rozgłaszane przez NVAs. Jeśli w maszynach wirtualnych platformy Azure zaprogramowane są co najmniej dwie trasy, używają trasowania z wieloma ścieżkami o równym koszcie, aby wybrać jedną z instancji NVA dla każdego przepływu ruchu. W związku z tym należy uwzględnić SNAT w tym projekcie, jeśli potrzebujesz symetrii ruchu.

Ta metoda wstawiania obsługuje konfiguracje aktywne/aktywne i aktywne/rezerwowe. W konfiguracji aktywnej/aktywnej wszystkie wirtualne urządzenia sieciowe anonsują te same trasy do serwera tras. W konfiguracji aktywnej/rezerwowej jedno urządzenie NVA reklamuje trasy z krótszą ścieżką systemu autonomicznego (AS) niż drugie. Usługa Route Server obsługuje maksymalnie osiem adjacencji protokołu BGP. Jeśli zatem używasz klastra skalowalnego w poziomie z aktywnymi urządzeniami NVA, ten projekt obsługuje maksymalnie osiem instancji NVA.

Ta konfiguracja ma szybki czas zbieżności. Czas utrzymania aktywności i czas przechowywania adjacency BGP wpływa na czas zbieżności. Route Server ma domyślne czasomierze keepalive ustawione na 60 sekund i czasomierze przechowywania ustawione na 180 sekund. Ale NVAs mogą negocjować niższe timery podczas ustanawiania sąsiedztwa BGP. Ustawienie tych czasomierzy zbyt niskie może prowadzić do niestabilności protokołu BGP.

Ten projekt odpowiada wirtualnym urządzeniom sieciowym (NVAs), które muszą korzystać z routingu platformy Azure. Przykłady obejmują SD-WAN lub wirtualne urządzenia sieciowe IPsec, które zazwyczaj mają dobrą obsługę protokołu BGP. Te wirtualne urządzenia sieciowe muszą poznać prefiksy skonfigurowane w sieciach wirtualnych platformy Azure lub ogłaszać niektóre trasy za pośrednictwem prywatnych połączeń równorzędnych usługi ExpressRoute. Te typy urządzeń są zwykle bezstanowe, więc symetria ruchu nie jest problemem, a SNAT nie jest wymagana.

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

Moduł równoważenia obciążenia bramy umożliwia wstawianie wirtualnych urządzeń sieciowych (NVA) w ścieżce danych bez konieczności kierowania ruchu za pomocą tras zdefiniowanych przez użytkownika. W przypadku maszyn wirtualnych, które uwidaczniają obciążenia za pośrednictwem modułu równoważenia obciążenia platformy Azure lub publicznego adresu IP, można przezroczysto przekierowywać ruch przychodzący i wychodzący do klastra NVAs znajdujących się w innej sieci wirtualnej. Na poniższym diagramie przedstawiono ścieżkę, którą pokonują pakiety dla ruchu przychodzącego z publicznego Internetu, jeśli obciążenia udostępniają aplikację za pośrednictwem modułu równoważenia obciążenia platformy Azure.

Na tym diagramie przedstawiono sieć wirtualną NVA oraz sieć wirtualną aplikacji. Sieć wirtualna NVA zawiera równoważnik obciążenia bramy i urządzenia NVA. Sieć wirtualna aplikacji zawiera serwer internetowy. Przepływ użytkownika przechodzi z Internetu do serwera internetowego za pośrednictwem publicznego standardowego modułu równoważenia obciążenia platformy Azure. Przepływ kontrolowany przez bramowy moduł równoważenia obciążenia przechodzi od publicznego standardowego równoważnika obciążenia platformy Azure do bramowego modułu równoważenia obciążenia, a następnie do wirtualnych urządzeń sieciowych (NVAs). Ten przepływ odwraca kierunek i przechodzi z urządzeń NVA do Gateway Load Balancer, a następnie do publicznego standardowego modułu równoważenia obciążenia platformy Azure.

Ta metoda iniekcji NVA zapewnia następujące korzyści:

• Ta metoda nie wymaga SNAT do zagwarantowania symetrii ruchu.

• Możesz użyć tych samych NVAs do monitorowania ruchu do i z różnych sieci wirtualnych, co zapewnia wielodzierżawność z perspektywy NVAs.

• Komunikacja równorzędna sieci wirtualnych nie jest wymagana między siecią wirtualną urządzenia NVA a sieciami wirtualnymi obciążenia, co upraszcza konfigurację.

• Trasy zdefiniowane przez użytkownika nie są wymagane w sieci wirtualnej dla obciążeń, co również upraszcza konfigurację.

Możesz użyć iniekcji usługi za pośrednictwem Gateway Load Balancer dla ruchu przychodzącego do publicznego modułu równoważenia obciążenia platformy Azure, ruchu wychodzącego z platformy Azure oraz ruchu zwracającego. East-West ruch między maszynami wirtualnymi platformy Azure nie może używać Gateway Load Balancer do wstawiania sieciowych urządzeń wirtualnych (NVA).

W klastrze NVA sondy sprawdzania kondycji usługi Azure load balancer wykrywają błędy w poszczególnych wystąpieniach NVA, co zapewnia szybki czas zbieżności od 10 do 15 sekund.

Dynamiczne zarządzanie dynamicznymi publicznymi adresami IP oraz trasami użytkownika

Celem tego projektu jest posiadanie konfiguracji działającej bez nadmiarowości urządzenia NVA, którą można zmodyfikować w przypadku przestoju urządzenia NVA. Na poniższym diagramie pokazano, jak publiczny adres IP platformy Azure przypisuje się do aktywnego urządzenia NVA (NVA1 na diagramie). Trasy zdefiniowane przez użytkownika w szprychach używają aktywnego adresu IP urządzenia NVA (10.0.0.37) jako następnego przeskoku sieciowego.

Ten diagram przedstawia piastę i dwie szprychy. Koncentrator zawiera podsieć bramy i podsieć urządzenia NVA. Podsieć bramowa zawiera bramę VPN lub bramę ExpressRoute. Podsieć NVA zawiera dwa urządzenia NVA. Urządzenie WUS1 jest oznaczone jako aktywne, a urządzenie WUS2 jest oznaczone jako rezerwowe. Każda szprycha zawiera serwer aplikacji. Szprycha ma notatkę, która odczytuje tabelę tras szprych 0.0.0.0/0 do 10.0.0.37 i wyłącza propagację bramy. Ruch przychodzący przepływa z Internetu do NVA1 za pośrednictwem publicznego adresu IP. Ten ruch następnie przepływa do Spoke2. Przepływ ruchu powraca z Spoke2 do NVA1, a następnie do Internetu.

Jeśli aktywne urządzenie WUS stanie się niedostępne, rezerwowe urządzenie WUS wywołuje interfejs API platformy Azure, aby ponownie zamapować publiczny adres IP i trasy zdefiniowane przez użytkownika szprych na siebie lub przejąć prywatny adres IP. Wykonanie tych wywołań interfejsu API może potrwać kilka minut. Konstrukcja ta zapewnia najgorszy czas zbiegania się wśród opcji opisanych w tym artykule.

Ten projekt obsługuje tylko konfiguracje aktywne/rezerwowe, co może prowadzić do problemów ze skalowalnością. Jeśli musisz zwiększyć przepustowość, którą obsługują urządzenia NVAs, musisz rozbudować oba wystąpienia.

Ten projekt nie wymaga uwierzytelniania SNAT w celu zagwarantowania symetrii ruchu, ponieważ tylko jedno urządzenie WUS jest aktywne w danym momencie.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

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ć niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok

• Sieci obwodowe

Powiązany zasób

• Implementowanie bezpiecznej sieci hybrydowej przy użyciu usługi Azure Firewall