Chmura zmienia sposób projektowania infrastruktury, w tym projektowania zapór, ponieważ sieć nie jest już fizyczna ani wirtualna sieci LAN. Nie wszystkie funkcje sieci fizycznej są dostępne w sieci wirtualnej (VNet). Obejmuje to używanie przestawnych adresów IP czy ruchu emisji i ma to wpływ na implementację architektur wysokiej dostępności. W celu zapewnienia architektury wysokiej dostępności w ramach sieci wirtualnej mogą/muszą być wdrażane w określony sposób moduły równoważenia obciążenia dla wirtualnych urządzeń sieciowych. W tym przewodniku przedstawiono podejście strukturalne do projektowania zapór wysokiej dostępności na platformie Azure przy użyciu urządzeń wirtualnych innych dostawców.
Opcje projektowania wirtualnych urządzeń sieciowych o wysokiej dostępności
W przypadku wdrażania architektur wysokiej dostępności istnieje kilka opcji zapewniania trybu failover:
- Tabele tras zarządzanych przez interfejs API platformy Azure: ta opcja używa dwóch tabel tras, jednej aktywnej, jednej pasywnej, aby przełączyć aktywny adres IP bramy dla wszystkich usług uruchomionych w sieci wirtualnej/podsieci.
- Pływający adres IP zarządzany przez interfejs API platformy Azure: ta opcja używa pomocniczego adresu IP na FWs, które można przenosić między aktywnym i rezerwowym klawiszem FW.
- Zarządzane przez usługę Load Balancer: ta opcja używa usługi Azure Load Balancer do działania jako adresu IP bramy dla podsieci, która następnie przekazuje ruch do aktywnej usługi FW. Ruch może być nawet przekazywany w konfiguracji aktywne-aktywne, aby zapewnić rzeczywiste równoważenie obciążenia.
Problem z dwiema pierwszymi opcjami polega na tym, że przechodzenie do trybu failover jest powolne. FW musi poinstruować tryb failover, który jest zasadniczo "rekonfiguracją" usług platformy Azure za pomocą nowego wdrożenia. W zależności od tego, jak szybko zostanie ukończone wdrożenie, przez kilka minut przepływy ruchu nie będą działać. Ponadto nie zezwala na konfigurację aktywne-aktywne, w której oba zapory działają w tym samym czasie.
Dlatego trzecia opcja jest najbardziej preferowana. Czas przestoju jest zminimalizowany, ponieważ moduł równoważenia obciążenia może niemal natychmiast przejść do trybu failover przez przełączenie się na zaporę zapasową (w trybie aktywne-pasywne) lub po prostu usunąć obciążenie z zapory dotkniętej awarią (w trybie aktywne-aktywne). Nie można jednak używać tylko modułów równoważenia obciążenia jako "bram domyślnych", ponieważ wpływają one na przepływ ruchu, a pakiety TCP muszą być stanowe.
Zapory z dwoma rozwidleniami
Na poniższej ilustracji na początku widać dwie zapory (FW-1 i FW-2) z zewnętrznym modułem równoważenia obciążenia i serwerem zaplecza S1.
Ta architektura jest prostą konfiguracją używaną dla ruchu przychodzącego. Pakiet trafia do modułu równoważenia obciążenia, który wybiera zaporę docelową na podstawie swojej konfiguracji. Następnie wybrana zapora wysyła ruch do serwera zaplecza (internetowego). Jeśli protokół FW-1 ma włączoną funkcję SNAT, serwer S1 będzie widzieć ruch pochodzący z wewnętrznego adresu IP FW-1, dlatego również wyśle odpowiedź do pakietu do FW-1. W tym scenariuszu przejście w tryb failover do zapory FW-2 może nastąpić szybko. W przypadku ruchu wychodzącego możemy dodać kolejny moduł równoważenia obciążenia po stronie wewnętrznej. Gdy serwer S1 uruchamia ruch, zostanie zastosowana ta sama zasada. Ruch trafia do wewnętrznego modułu równoważenia obciążenia (iLB), który wybiera zaporę, która następnie tłumaczy translator adresów sieciowych na potrzeby rozpoznawania zewnętrznego:
Zapory z trzema rozwidleniami
Występują problemy podczas dodawania innego interfejsu do zapory i trzeba wyłączyć tłumaczenie translatora adresów sieciowych między strefami wewnętrznymi . W tym przypadku zobacz Podsieć-B i Subnet-C:
Routing warstwy trzeciej między strefami wewnętrznymi (Subnet-B i Subnet-C) będzie w obu przypadkach podlegać równoważeniu obciążenia bez translacji NAT. Ta konfiguracja staje się jaśniejsza w przypadku przepływów ruchu, w tym modułów równoważenia obciążenia w innym widoku. Na poniższym diagramie przedstawiono widok, w którym wewnętrzne moduły równoważenia obciążenia [iLB] są połączone z konkretną kartą sieciową w zaporach:
W przypadku ruchu L3 (bez translatora adresów sieciowych) S2 będzie widoczny adres IP S1 jako adres źródłowy. S2 następnie wyśle ruch powrotny dla podsieci B (do której należy S1-IP) do modułu iLB w podsieci Subnet-C. Ponieważ moduły iLB w podsieci Subnet-B i iLB w podsieci Subnet-C nie synchronizują stanów sesji, w zależności od ruchu algorytmu równoważenia obciążenia może zakończyć się na FW-2. Domyślnie FW-2 nie wie nic o początkowym (zielonym) pakiecie, więc spowoduje usunięcie połączenia.
Niektórzy dostawcy zapory próbują zachować stan połączenia między zaporami, ale potrzebują niemal natychmiastowej synchronizacji, aby były aktualne w stanach połączenia. Należy skontaktować się z dostawcą zapory, aby dowiedzieć się, czy ta konfiguracja jest zalecana.
Najlepszym sposobem postępowania z tym problemem jest wyeliminowanie go. W powyższym przykładzie to rozwiązanie oznacza wyeliminowanie podsieci Subnet-C, co przynosi korzyści z zwirtualizowanych sieci wirtualnych.
Izolowanie hostów w podsieci za pomocą sieciowych grup zabezpieczeń
W przypadku dwóch maszyn wirtualnych w jednej podsieci można zastosować sieciowe grupy zabezpieczeń, które izolują ruch między nimi. Domyślnie ruch wewnątrz sieci wirtualnej jest całkowicie dozwolony. Dodanie reguły Odmów wszystkim dla sieciowej grupy zabezpieczeń izoluje wszystkie maszyny wirtualne od siebie.
Sieci wirtualne używają tych samych routerów (wirtualnych) zaplecza
Sieć wirtualna/podsieci używają pojedynczego systemu routera zaplecza z platformy Azure i w związku z tym nie ma potrzeby określania adresu IP routera dla każdej podsieci. Lokalizacja docelowa trasy może znajdować się w dowolnym miejscu w tej samej sieci wirtualnej lub nawet poza nią.
W przypadku sieci zwirtualizowanych można sterować trasami w każdej podsieci. Te trasy mogą również wskazywać pojedynczy adres IP w innej podsieci. Na ilustracji powyższej byłby to moduł iLB w podsieci Subnet-D, który równoważy obciążenie dwóch zapór. Gdy S1 uruchamia ruch (zielony), obciążenie zostanie zrównoważone, na przykład FW-1. Następnie zapora FW-1 połączy się z S2 (nadal zielony). S2 wyśle ruch odpowiedzi do adresu IP S1 (ponieważ translator adresów sieciowych jest wyłączony). Ze względu na tabele tras usługa S2 używa tego samego adresu IP modułu równoważenia obciążenia co brama. Moduł iLB może być zgodny z ruchem do sesji początkowej, więc zawsze będzie wskazywać ten ruch z powrotem do FW-1. FW-1 następnie wysyła go do S1, ustanawiając synchroniczny przepływ ruchu.
Aby ta konfiguracja działała, usługa FW musi mieć tabelę tras (wewnętrznie) wskazującą podsieć Subnet-B i Subnet-C na domyślną bramę podsieci. Brama podsieci jest pierwszym logicznie dostępnym adresem IP w zakresie podsieci w tej sieci wirtualnej.
Wpływ na usługi odwrotnego serwera proxy
W przypadku wdrażania usługi zwrotnego serwera proxy zwykle będzie ona znajdować się za usługą FW. Zamiast tego można umieścić go w kolejce z FW i faktycznie kierować ruch przez FW. Zaletą tej konfiguracji jest to, że usługa zwrotnego serwera proxy będzie widzieć oryginalny adres IP klienta łączącego:
W przypadku tej konfiguracji tabele tras w podsieci Subnet-E muszą wskazywać podsieć Subnet-B i Subnet-C za pośrednictwem wewnętrznego modułu równoważenia obciążenia. Niektóre usługi zwrotnego serwera proxy mają wbudowane zapory, które umożliwiają usunięcie FW wszystkie razem w tym przepływie sieci. Wbudowane zapory wskazują od zwrotnego serwera proxy bezpośrednio do serwerów Subnet-B/C.
W tym scenariuszu na odwrotnym serwerze proxy wymagany będzie też SNAT, aby uniknąć kierowania ruchu zwrotnego do podsieci Subnet-A przez zaporę, gdzie byłby odrzucany.
Sieć VPN/ER
Platforma Azure zapewnia usługi sieci VPN/ER z obsługą protokołu BGP/o wysokiej dostępności za pośrednictwem usług bram Azure Virtual Network Gateway. Większość architektów ogranicza ich używanie do obszaru zaplecza lub połączeń niestykających się z Internetem. Ta konfiguracja oznacza, że tabela routingu musi również pomieścić podsieci za tymi połączeniami. Chociaż nie ma dużej różnicy w połączeniu z podsiecią subnet-B/C, istnieje w projekcie ruchu powrotnego, kończąc obraz:
W tej architekturze ruch trafiający do zapory z, na przykład, podsieci Subnet-B do podsieci Subnet-X zostałby wysłany do modułu iLB, który z kolei wysłałby go do jednej z zapór. Trasa wewnętrzna wewnątrz zapory spowoduje wysłanie ruchu z powrotem do bramy podsieci (pierwszy dostępny adres IP w podsieci Subnet-D). Nie musisz wysyłać ruchu bezpośrednio do samego urządzenia bramy, ponieważ inna trasa w podsieci Subnet-D będzie miała trasę dla podsieci Subnet-X wskazującej ją na bramę sieci wirtualnej. Usługa Azure Networking zajmie się rzeczywistym routingiem.
Ruch powrotny pochodzący z podsieci Subnet-X zostanie przekazany do modułu iLB w podsieci Subnet-D. Podsieć GatewaySubnet będzie również mieć trasę niestandardową, która wskazuje podsieć Subnet-B-C do modułu iLB. Podsieć-D nie jest za pośrednictwem modułu iLB. Ten przypadek będzie traktowany jako zwykły routing między sieciami wirtualnymi.
Chociaż nie ma tego na rysunku, miałoby sens, aby podsieci Subnet-B/C/D/bramy obejmowały też trasę dla podsieci Subnet-A ze skierowaniem do modułu iLB. Takie rozwiązanie pozwala uniknąć "zwykłego" routingu sieci wirtualnej w celu obejścia FWs. Jest to związane z tym, że zgodnie ze stosem sieciowym platformy Azure podsieć Subnet-A jest po prostu kolejną podsiecią w sieci wirtualnej. Nie będzie traktować podsieci Subnet-A inaczej, chociaż traktujesz ją jako DMZ/Internet/etc.
Podsumowanie
W skrócie sposób traktowania zapór w sieciach lokalnych (opartych na sieci fizycznej/sieciach wirtualnych) przy takiej samej liczbie interfejsów (wirtualnych lub fizycznych) nie jest taki sam jak w przypadku platformy Azure. W razie potrzeby nadal można, w pewnym stopniu (choć istnieją lepsze sposoby minimalizowania przestojów w przypadku awarii), używać implementacji aktywne-aktywne i czyścić tabele routingu.
Więcej informacji na temat używania modułów równoważenia obciążenia jako bram dla całego ruchu można znaleźć w temacie High availability ports overview (Omówienie portów o wysokiej dostępności).
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Roelf Zomerman | Starszy architekt rozwiązań w chmurze
Następne kroki
Dowiedz się więcej o technologiach składników:
- Co to jest usługa Azure Load Balancer?
- Co to jest usługa Azure Virtual Network?
- Co to jest usługa VPN Gateway?
Powiązane zasoby
Zapoznaj się z powiązanymi architekturami:
- Implementowanie bezpiecznej sieci hybrydowej
- Połączenie hybrydowe
- Rozszerzanie sieci lokalnej przy użyciu sieci VPN
- Wybieranie między sieciami równorzędnymi sieci wirtualnych i bramami sieci VPN
- Rozwiązywanie problemów z hybrydowym połączeniem sieci VPN
- Topologia sieci piasty i szprych na platformie Azure
- Połączenie autonomicznych serwerów przy użyciu karty sieciowej platformy Azure