Molnet ändrar hur infrastrukturen utformas, inklusive utformningen av brandväggar, eftersom nätverket inte längre är fysiskt eller i virtuella LOKALA nätverk. 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 vägtabeller: Det här alternativet använder två vägtabeller, en aktiv och en passiv för att växla aktiv gateway-IP för alla tjänster som körs i 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 Azure Load Balancer för att fungera som gateway-IP för undernätet, som sedan vidarebefordrar trafiken till den aktiva FW:en. 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. Den virtuella nätverksinstallationen måste instruera redundansen, vilket 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 fungerar samtidigt.
Därför är det tredje alternativet det bästa alternativet. 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åndsfulla.
Brandväggar med två ben
Följande bild börjar med två FWs (FW-1 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 når den interna lben (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 behöver inaktivera NAT-översättning mellan interna zoner. I det här fallet kan du se 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ät 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 sessions tillstånd, kan beroende på belastningsutjämningsalgoritmens trafik hamna på FW-2. FW-2 vet som standard inte något om det första (gröna) paketet, så anslutningen tas bort.
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 undernät-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 VNet helt och hållet. 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 backend-routersystem 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) belastningsutjämnas den till exempelvis 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 vägtabellerna använder S2 samma iLB IP som dess gateway. ILB kan matcha trafiken till den första sessionen, så den kommer alltid att peka trafiken tillbaka 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 vägtabell (internt) som pekar på undernät-B och undernät-C till dess standardundernät GW. Undernätets 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 ligger den normalt bakom brandväggen. Du kan i stället placera den i linje med den FW och dirigera trafiken via den. Fördelen med den här konfigurationen är att den omvända proxytjänsten ser den ursprungliga IP-adressen för den anslutande klienten:
För den här konfigurationen måste vägtabellerna på 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 brandväggen 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 även måste hantera undernäten bakom dessa anslutningar. Även om det inte är stor skillnad på undernät-B/C-anslutning, finns det i utformningen av returtrafiken, vilket ger en bild:
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 i undernät D har en väg för undernät-X som pekar den till Virtual Network Gateway. Azure-nätverkstjänster tar hand om den faktiska routningen.
Returtrafik som kommer från undernät-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 "vanlig" VNET-routning för att kringgå FWs. Detta eftersom undernät-A bara är ett annat undernät i VNET enligt Azure-nätverksstacken. Det behandlar inte 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.
Nästa steg
Läs mer om komponentteknikerna:
Utforska relaterade arkitekturer:
- Implementera ett säkert hybridnätverk
- Hybridanslutning
- Utöka ett lokal nätverk med VPN
- Välj mellan peering för virtuella nätverk och VPN-gatewayer
- Felsöka en VPN-hybridanslutning
- Nätverkstopologi av typen hub-spoke i Azure
- Ansluta fristående servrar med hjälp av Azure-nätverkskort
- Anpassade krav på datasuveränitet
- SQL Server 2008 R2-redundanskluster i Azure