Molnet ändrar hur infrastrukturen utformas, inklusive utformningen av brandväggar, eftersom nätverket inte längre är fysiskt eller i virtuella LAN. Alla funktioner i ett fysiskt nätverk är inte tillgängliga i ett virtuellt nätverk (VNet). Här ingår användning av flytande IP-adresser eller broadcast-trafik, och det påverkar implementeringen av HA-arkitekturer. Lastbalanserare för virtuella nätverksinstallationer (NVA:er) kan/måste implementeras på ett visst sätt för att uppnå en arkitektur med hög tillgänglighet (HA-arkitektur) i ett virtuellt nätverk. I den här guiden beskrivs ett strukturerat tillvägagångssätt för att utforma HA-brandväggar i Azure med hjälp av virtuella installationer från tredje part.
Alternativ för att utforma NVA:er med hög tillgänglighet
När du distribuerar HA-arkitekturer finns det några alternativ för att tillhandahålla redundans:
- Azure API-hanterade routningstabeller: Det här alternativet använder två routningstabeller, en aktiv, en passiv för att växla den aktiva gateway-IP-adressen för alla tjänster som körs på ett VNet/undernät.
- Azure API-hanterad flytande IP-adress: Det här alternativet använder en sekundär IP-adress på de FW:er som kan flyttas mellan en aktiv och en fristående FW.
- Load Balancer hanterad: Det här alternativet använder en Azure Load Balancer för att fungera som gateway-IP för undernätet, som sedan vidarebefordrar trafiken till den aktiva FW:n. Den kan till och med vidarebefordra trafiken aktivt-aktivt för att ge sann belastningsutjämning.
Problemet med de två första alternativen är att själva redundansväxlingen är långsam. FW måste instruera redundansväxlingen, som i princip är en "omkonfiguration" av Azure-tjänster via en ny distribution. Beroende på hur snabbt den distributionen slutförs är trafikflödena ur funktion i flera minuter. Dessutom tillåter det inte en aktiv-aktiv konfiguration där båda brandväggarna körs samtidigt.
Det är därför det tredje alternativet är mest föredraget. Stilleståndstiden minimeras eftersom lastbalanseraren kan redundansväxla nästan direkt till brandväggen i vänteläge (i aktiv-passiv) eller bara ta bort belastningen från den misslyckade brandväggen (i aktiv-aktiv). Men du kan inte bara använda lastbalanserare som "standardgatewayer" eftersom de påverkar trafikflödet och TCP-paket måste vara tillståndskänsliga.
Brandväggar med två ben
Följande bild börjar med två brandväggar (FW-1 och FW-2), med en extern lastbalanserare och en backend-server S1.
Den här arkitekturen är en enkel konfiguration som används för inkommande trafik. Ett paket träffar lastbalanseraren, som väljer målbrandväggen från konfigurationen. Den valda brandväggen skickar sedan trafiken till backend-servern (webbservern). Om FW-1 har SNAT aktiverat ser server S1 trafiken som kommer från den interna IP-adressen för FW-1, så den skickar även svaret till paketet till FW-1. Redundansväxlingen kan ske snabbt till FW-2 i det här scenariot. För utgående trafik kan vi lägga till ytterligare en lastbalanserare på den interna sidan. När server S1 startar trafik gäller samma princip. Trafiken träffar den interna lb (iLB), som väljer en brandvägg som sedan översätter NAT för extern lösning:
Brandväggar med tre ben
Problem uppstår när vi lägger till ett annat gränssnitt i brandväggen och du måste inaktivera NAT-översättning mellan interna zoner. I det här fallet kan du läsa Undernät-B och Undernät-C:
L3-routningen mellan de interna zonerna (undernät-B och undernät-C) belastningsutjämnas båda utan NAT. Den här konfigurationen blir tydligare när du tittar på trafikflödena, inklusive lastbalanserarna i en annan vy. Diagrammet nedan visar vyn där de interna lastbalanserarna[iLB] är länkade till ett specifikt nätverkskort (NIC) på brandväggarna:
Med L3-trafik (utan NAT) ser S2 S1 IP-adressen som källadress. S2 skickar sedan returtrafiken för undernätet B (som S1-IP tillhör) till iLB i Undernät-C. Eftersom iLB i Undernät-B och iLB i Undernät-C inte synkroniserar sina sessionstillstånd, beroende på belastningsutjämningsalgoritmtrafiken kan hamna på FW-2. FW-2 vet som standard ingenting om det första (gröna) paketet, så det släpper anslutningen.
Vissa brandväggsleverantörer försöker behålla ett anslutningstillstånd mellan brandväggarna, men de skulle behöva nästan omedelbar synkronisering för att vara uppdaterade om anslutningstillstånden. Fråga din brandväggsleverantör om de rekommenderar den här konfigurationen.
Det bästa sättet att åtgärda det här problemet är att eliminera det. I exemplet ovan innebär den här lösningen att du eliminerar Subnet-C, vilket ger oss fördelarna med virtualiserade virtuella nätverk.
Isolera värdar i ett undernät med nätverkssäkerhetsgrupper
När det finns två virtuella datorer i ett enda undernät kan du använda en NSG som isolerar trafik mellan de två. Som standard tillåts trafik i ett virtuellt nätverk helt. Om du lägger till en regel om att neka allt för nätverkssäkerhetsgruppen isoleras alla virtuella datorer från varandra.
Virtuella nätverk använder samma (virtuella) serverdelsroutrar
VNet/undernät använder ett enda serverdelsroutersystem från Azure och därför behöver du inte ange en router-IP för varje undernät. Routningsmålet kan finnas var som helst i samma VNET eller till och med utanför.
Med de virtualiserade nätverken kan du kontrollera vägarna i varje undernät. Dessa vägar kan också peka på en enskild IP i ett annat undernät. I bilden ovan är det iLB i undernät-D, som belastningsutjämnar de två brandväggarna. När S1 startar trafik (grön) lastbalanseras den till exempel FW-1. FW-1 ansluter sedan till S2 (fortfarande grön). S2 skickar svarstrafiken till IP-adressen för S1 (eftersom NAT är inaktiverat). På grund av routningstabellerna använder S2 samma iLB IP-adress som sin gateway. ILB kan matcha trafiken till den första sessionen, så den pekar alltid tillbaka trafiken till FW-1. FW-1 skickar den sedan till S1 och upprättar ett synkront trafikflöde.
För att den här konfigurationen ska fungera måste FW ha en routningstabell (internt) som pekar undernät-B och undernät-C till dess standardundernät GW. Det undernätet GW är den första logiskt tillgängliga IP-adressen i undernätsintervallet i det virtuella nätverket.
Påverkan på omvända proxytjänster
När du distribuerar en omvänd proxytjänst skulle den normalt ligga bakom FW:n. Du kan i stället placera den i linje med FW och faktiskt dirigera trafiken genom FW. Fördelen med den här konfigurationen är att den omvända proxytjänsten skulle se den ursprungliga IP-adressen för den anslutande klienten:
För den här konfigurationen måste routningstabellerna i Undernät-E peka undernät-B och undernät-C via den interna lastbalanseraren. Vissa omvända proxytjänster har inbyggda brandväggar som gör att du kan ta bort FW tillsammans i det här nätverksflödet. De inbyggda brandväggarna pekar från omvänd proxy direkt till Undernät-B/C-servrar.
I det här scenariot krävs SNAT även på den omvända proxyn för att undvika att returtrafik flödar igenom och nekas av brandväggarna till undernät-A.
VPN/ER
Azure tillhandahåller BGP-aktiverade/högtillgängliga VPN/ER-tjänster via Azure Virtual Network-gatewayer. De flesta arkitekter behåller dessa för serverdelsanslutningar eller anslutningar som inte är mot Internet. Den här konfigurationen innebär att routningstabellen måste hantera undernäten bakom dessa anslutningar också. Även om det inte finns någon stor skillnad för undernät-B/C-anslutning, finns det i utformningen av returtrafiken, vilket slutför bilden:
I den här arkitekturen skickas trafik som träffar brandväggen från, till exempel undernät-B till undernät-X till den interna lastbalanseraren, som i sin tur skickar den till någondera brandvägg. Den interna vägen inuti brandväggen skickar trafiken tillbaka till undernäts-GW (första tillgängliga IP i undernät-D). Du behöver inte skicka trafiken direkt till själva gatewayinstallationen, eftersom en annan väg på Undernät-D har en väg för Undernät-X som pekar den mot den virtuella nätverksgatewayen. Azure-nätverkstjänster tar hand om den faktiska routningen.
Returtrafik som kommer från Subnet-X vidarebefordras till iLB i Undernät-D. GatewaySubnet har också en anpassad väg som pekar undernät-B-C till iLB. Undernät-D är inte via iLB. Detta kommer att behandlas som vanlig routning mellan virtuella nätverk.
Även om det inte finns med i ritningen skulle det passa bra för undernät-B/C/D/Gateway att även innehålla en väg för undernät-A som pekar till iLB. Det här arrangemanget undviker den "vanliga" VNET-routningen för att kringgå de virtuella datorerna. Detta eftersom undernät-A bara är ett annat undernät i VNET enligt Azure-nätverksstacken. Det kommer inte att behandla undernät-A annorlunda, även om du behandlar det som DMZ/Internet/etc.
Sammanfattning
Kort sagt hanterar du inte brandväggar i dina lokala (fysiska/VLAN-baserade) nätverk, med lika många gränssnitt (virtuella eller fysiska), på samma sätt som i Azure. Om det behövs kan du ändå göra det (till viss grad), men det finns bättre sätt att minimera stilleståndstiden vid redundans: använd aktiv-aktiv-implementeringar och rena routningstabeller.
Mer information om hur du använder lastbalanserare som gatewayer för all trafik finns i översikten över portar med hög tillgänglighet.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Roelf Zomerman | Senior Cloud Solution Architect
Nästa steg
Läs mer om komponentteknikerna:
Relaterade resurser
Utforska relaterade arkitekturer: