Brandvägg och Application Gateway för virtuella nätverk

För att skydda Azure-programarbetsbelastningar använder du skyddsåtgärder, till exempel autentisering och kryptering, i själva programmen. Du kan också lägga till säkerhetslager i de virtuella datornätverk som är värdar för programmen. Lagren skyddar inkommande flöden från användare. De skyddar även utgående flöden till Internet som ditt program kan kräva. Den här artikeln beskriver Azure Virtual Network säkerhetstjänster som Azure Firewall och Azure Application Gateway, när du ska använda varje tjänst och nätverksalternativ som kombinerar båda.

• Azure Firewall är en hanterad nästa generations brandvägg som erbjuder NAT (Network Address Translation). Azure Firewall baserar paketfiltrering på Internet Protocol-adresser (IP) och Transmission Control Protocol- och TCP/UDP-portar (User Datagram Protocol), eller på programbaserade HTTP(S) eller SQL attribut. Azure Firewall även Microsofts hotinformation för att identifiera skadliga IP-adresser. Mer information finns i dokumentationen Azure Firewall.
• Azure Firewall Premium innehåller alla funktioner i Azure Firewall Standard och andra funktioner, till exempel TLS-inspektion och intrångsidentifiering och skyddssystem (IDPS).
• Azure Application Gateway är en hanterad lastbalanserare för webbtrafik och EN(S) fullständig omvänd proxy som kan kryptera och dekryptera Secure Socket Layer (SSL). Application Gateway använder också Web Application Firewall för att inspektera webbtrafik och identifiera attacker på HTTP-lagret. Mer information finns i dokumentationen Application Gateway.
• Azure Web Application Firewall (WAF) är ett valfritt tillägg till Azure Application Gateway. Den ger granskning av HTTP-begäranden och förhindrar skadliga attacker på webblagret, till exempel SQL eller skriptning mellan webbplatser. Mer information finns i dokumentationen Web Application Firewall.

Dessa Azure-tjänster kompletterar varandra. Den ena eller den andra kan vara bäst för dina arbetsbelastningar, eller så kan du använda dem tillsammans för optimalt skydd på både nätverks- och programlager. Använd följande beslutsträd och exemplen i den här artikeln för att fastställa det bästa säkerhetsalternativet för programmets virtuella nätverk.

Azure Firewall och Azure Application Gateway olika tekniker, och de stöder värdepapperisering av olika flöden:

Program Flow	Kan filtreras efter Azure Firewall	Kan filtreras efter WAF på Application Gateway
HTTP(S)-trafik från lokal plats/Internet till Azure (inkommande)	Ja	Ja
HTTP(S)-trafik från Azure till lokal plats/Internet (utgående)	Ja	Inga
Icke-HTTP(S)-trafik, inkommande/utgående	Ja	Inga

Beroende på vilka nätverksflöden ett program kräver kan designen variera beroende på program. Följande diagram innehåller ett förenklat beslutsträd som hjälper dig att välja den rekommenderade metoden för ett program. Beslutet beror på om programmet publiceras via HTTP(S) eller något annat protokoll:

Den här artikeln beskriver de rekommenderade designerna från flödesdiagrammet och andra som är tillämpliga i mindre vanliga scenarier:

• Azure Firewall ,när det inte finns några webbprogram i det virtuella nätverket. Den styr både inkommande trafik till programmen och utgående trafik.
• Application Gateway ,när endast webbprogram finns i det virtuella nätverket och nätverkssäkerhetsgrupper (NSG: er) ger tillräcklig utdatafiltrering. Det här scenariot rekommenderas vanligtvis inte på grund av de omfattande funktionerna i Azure Firewall över NSG:er. Den funktionen kan förhindra många attackscenarier (till exempel data exfiltrering), så det här scenariot dokumenteras inte i flödesdiagrammet ovan.
• Azure Firewall och Application Gateway parallellt, vilket är en av de vanligaste designerna. Använd den här kombinationen när Azure Application Gateway vill skydda HTTP(S)-program från webbattacker och Azure Firewall för att skydda alla andra arbetsbelastningar och filtrera utgående trafik.
• Application Gatewayframför Azure Firewall , när du vill att Azure Firewall ska inspektera all trafik, WAF för att skydda webbtrafik och programmet att känna till klientens IP-källadress. Med Azure Firewall Premium och TLS-inspektion stöder den här designen även SSL-scenariot från end-to-end.
• Azure Firewall framför Application Gateway, när du vill Azure Firewall att inspektera och filtrera trafik innan den når Application Gateway. Eftersom Azure Firewall inte kommer att dekryptera HTTPS-trafik är funktionerna som läggs till i Application Gateway begränsade. Det här scenariot dokumenteras inte i flödesdiagrammet ovan.

I den sista delen av den här artikeln beskrivs varianter av de tidigare grundläggande designerna. Dessa variationer är:

• Lokala programklienter.
• Nav- och ekernätverk.
• Azure Kubernetes Service (AKS).

Du kan lägga till andra omvända proxytjänster som en API Management gateway eller Azure Front Door. Eller så kan du ersätta Azure-resurserna med virtuella nätverksapparater från tredje part.

Azure Firewall endast

Om det inte finns några webbaserade arbetsbelastningar i det virtuella nätverket som kan dra nytta av WAF kan du endast använda Azure Firewall. Designen i det här fallet är enkel, men genom att granska paketflödet blir det enklare att förstå mer komplexa designer. I den här designen skickas all inkommande trafik till Azure Firewall via UDR:er (för anslutningar från lokala eller andra virtuella Azure-nätverk) eller till Azure Firewall:s offentliga IP-adress (för anslutningar från det offentliga Internet, som diagrammet nedan visar). Utgående trafik från virtuella Azure-nätverk skickas till brandväggen via UDR:er, som du ser i dialogrutan nedan.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Flöden	Går igenom Application Gateway/WAF	Går igenom Azure Firewall
HTTP(S)-trafik från Internet/onprem till Azure	Ej tillämpligt	Ja (se nedan)
HTTP(S)-trafik från Azure till Internet/onprem	Saknas	Ja
Icke-HTTP(S)-trafik från Internet/onprem till Azure	Saknas	Ja
Icke-HTTP(S)-trafik från Azure till Internet/onprem	Saknas	Ja

Azure Firewall kontrollerar inte inkommande HTTP(S)-trafik. Men den kommer att kunna tillämpa L3/L4-regler och FQDN-baserade programregler. Azure Firewall kontrollerar utgående HTTP(S)-trafik beroende på Azure Firewall och om du konfigurerar TLS-inspektion:

• Azure Firewall Standard inspekterar endast Layer 3-4-attribut för paketen i nätverksregler och HOST HTTP-huvudet i programregler.
• Azure Firewall Premium funktioner som att granska andra HTTP-huvuden (till exempel User-Agent) och aktivera TLS-inspektion för djupare paketanalys. Azure Firewall motsvarar inte en Web Application Firewall. Om du har webbarbetsbelastningar i din Virtual Network du starkt att använda WAF.

I följande paketvägsexempel visas hur en klient får åtkomst till ett program som är värd för en virtuell dator från det offentliga Internet. Diagrammet innehåller bara en virtuell dator för enkelhetens skull. För högre tillgänglighet och skalbarhet skulle du ha flera programinstanser bakom en lastbalanserare.

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Firewall:
   • Källans IP-adress: ClientPIP
   • Mål-IP-adress: AzFwPIP
2. Regeln Azure Firewall DESTINATION NAT (DNAT) översätter mål-IP-adressen till programmets IP-adress i det virtuella nätverket. Paketet Azure Firewall även käll-NAT:er (SNAT) om det gör DNAT. Mer information finns i Azure Firewall kända problem. Den virtuella datorn ser följande IP-adresser i det inkommande paketet:
   • Käll-IP-adress: 192.168.100.7
   • Mål-IP-adress: 192.168.1.4
3. Den virtuella datorn svarar på programbegäran och återför käll- och mål-IP-adresser. Det inkommande flödet kräver inte en användardefinierad väg (UDR)eftersom käll-IP-adressen Azure Firewall ip-adressen. UDR i diagrammet för 0.0.0.0/0 är för utgående anslutningar för att se till att paket till det offentliga Internet går via Azure Firewall.
   • Käll-IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.100.7
4. Slutligen Azure Firewall SNAT- och DNAT-åtgärderna och levererar svaret till klienten:
   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

I den här Azure Firewall både inkommande anslutningar från det offentliga Internet och utgående anslutningar från programmets undernäts-VM med hjälp av UDR.

• IP-adressen är en av de instanser som Azure Firewall distribuerar under omslaget, här med 192.168.100.7 frontend-IP-adressen 192.168.100.4 . Dessa enskilda instanser är normalt osynliga för Azure-administratören. Men att se skillnaden är användbart i vissa fall, till exempel när du felsöker nätverksproblem.

• Om trafiken kommer från ett lokalt virtuellt privat nätverk (VPN) eller en Azure ExpressRoute-gateway i stället för Internet, startar klienten anslutningen till den virtuella datorns IP-adress. Den startar inte anslutningen till brandväggens IP-adress och brandväggen gör ingen käll-NAT per standard.

Application Gateway endast

Den här designen omfattar en situation där det bara finns webbprogram i det virtuella nätverket, och att inspektera utgående trafik med NSG:er är tillräckligt för att skydda utgående flöden till Internet.

Den största skillnaden jämfört med den tidigare designen med endast Azure Firewall är att Application Gateway fungerar som en routningsenhet med NAT. Den fungerar som en fullständig omvänd programproxy. Det innebär Application Gateway stoppar webbsessionen från klienten och upprättar en separat session med en av dess serverdelsservrar. Inkommande HTTP(S)-anslutningar från Internet måste skickas till den offentliga IP-adressen för Application Gateway, anslutningar från Azure eller lokalt till den privata IP-adressen. Returtrafik från de virtuella Azure-datorerna följer standard-VNet-routning tillbaka till Application Gateway (mer information finns i paket genomgången längre ned). Utgående Internetflöden från virtuella Azure-datorer går direkt till Internet.

I följande tabell sammanfattas trafikflöden:

Flöden	Går igenom Application Gateway/WAF	Går igenom Azure Firewall
HTTP(S)-trafik från Internet/onprem till Azure	Yes	Ej tillämpligt
HTTP(S)-trafik från Azure till Internet/onprem	No	Ej tillämpligt
Icke-HTTP(S)-trafik från Internet/onprem till Azure	No	Ej tillämpligt
Icke-HTTP(S)-trafik från Azure till Internet/onprem	No	Ej tillämpligt

Följande paketvägsexempel visar hur en klient kommer åt det VM-värdbaserade programmet från det offentliga Internet.

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Application Gateway:
   • Källans IP-adress: ClientPIP
   • Mål-IP-adress: AppGwPIP
2. Den Application Gateway instans som tar emot begäran stoppar anslutningen från klienten och upprättar en ny anslutning med en av backend-ändarna. I backend ser Application Gateway instansen som källans IP-adress. Den Application Gateway in ett X-Forwarded-For HTTP-huvud med den ursprungliga klientens IP-adress.
   • Käll-IP-adress: 192.168.200.7 (den privata IP-adressen för Application Gateway instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-rubrik: ClientPIP
3. Den virtuella datorn svarar på programbegäran och återför käll- och mål-IP-adresser. Den virtuella datorn vet redan hur den Application Gateway, så den behöver ingen UDR.
   • Käll-IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
4. Slutligen svarar Application Gateway-instansen klienten:
   • Källans IP-adress: AppGwPIP
   • Mål-IP-adress: ClientPIP

Azure Application Gateway lägger till metadata i paketets HTTP-huvuden, till exempel huvudet X-Forwarded-For som innehåller den ursprungliga klientens IP-adress. Vissa programservrar behöver källklient-IP-adressen för att kunna hantera geoplatsspecifikt innehåll eller för loggning. Mer information finns i Så här fungerar en programgateway.

• IP-adressen är en av de instanser som Azure Application Gateway distribuerar under omslaget, här med 192.168.200.7 frontend-IP-adressen 192.168.200.4 . Dessa enskilda instanser är normalt osynliga för Azure-administratören. Men att se skillnaden är användbart i vissa fall, till exempel när du felsöker nätverksproblem.

• Flödet är liknande om klienten kommer från ett lokalt nätverk via en VPN- eller ExpressRoute-gateway. Skillnaden är att klienten har åtkomst till den privata IP-adressen för Application Gateway i stället för den offentliga adressen.

Brandvägg och Application Gateway parallellt

På grund av enkelheten och flexibiliteten är Application Gateway och Azure Firewall parallellt ofta det bästa scenariot.

Implementera den här designen om det finns en blandning av webb- och icke-webbarbetsbelastningar i det virtuella nätverket. Azure WAF skyddar inkommande trafik till webbarbetsbelastningarna och Azure Firewall inspekterar inkommande trafik för de andra programmen. Den Azure Firewall omfattar utgående flöden från båda arbetsbelastningstyperna.

Inkommande HTTP(S)-anslutningar från Internet ska skickas till den offentliga IP-adressen för Application Gateway-, HTTP(S)-anslutningar från Azure eller lokalt till dess privata IP-adress. Standard-VNet-routning skickar paketen från Application Gateway till de virtuella måldatorerna, samt från de virtuella måldatorerna tillbaka till Application Gateway (mer information finns i genomgången av paketet längre ned). För inkommande icke-HTTP(S)-anslutningar ska trafiken riktas mot den offentliga IP-adressen för Azure Firewall (om den kommer från det offentliga Internet), eller så skickas den via Azure Firewall av UDR:er (om den kommer från andra virtuella Azure-nätverk eller lokala nätverk). Alla utgående flöden från virtuella Azure-datorer vidarebefordras till Azure Firewall av UDR:er.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Flöden	Går igenom Application Gateway/WAF	Går igenom Azure Firewall
HTTP(S)-trafik från Internet/onprem till Azure	Ja	Inga
HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja
Icke-HTTP(S)-trafik från Internet/onprem till Azure	Inga	Ja
Icke-HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja

Den här designen ger mycket mer detaljerad utgående filtrering än NSG:er. Om program behöver anslutning till ett Azure Storage-konto kan du använda fullständigt kvalificerade domännamnsbaserade filter (FQDN). Med FQDN-baserade filter skickar program inte data till falska lagringskonton. Det scenariot kunde inte förhindras bara med hjälp av NSG:er. Den här designen används ofta där utgående trafik kräver FQDN-baserad filtrering. En exempel situation är när du begränsar utgående trafik från ett Azure Kubernetes Services-kluster.

Följande diagram illustrerar trafikflödet för inkommande anslutningar från en extern klient:

Följande diagram illustrerar trafikflödet för utgående anslutningar från nätverkets virtuella datorer till Internet. Ett exempel är att ansluta till backend-system eller hämta uppdateringar av operativsystemet:

Paketflödesstegen för varje tjänst är desamma som i de tidigare fristående designalternativen.

Application Gateway före brandväggen

Med det här alternativet går inkommande webbtrafik genom både Azure Firewall och WAF. WAF ger skydd på webbprogramnivån. Azure Firewall fungerar som en central loggnings- och kontrollpunkt och inspekterar trafiken mellan Application Gateway och backend-servrarna. Den Application Gateway och Azure Firewall är inte parallellt, utan den ena efter den andra.

Med Azure Firewall Premiumkan den här designen stödja scenarier från Azure Firewall till slut där TLS-inspektion används för att göra IDPS på den krypterade trafiken mellan Application Gateway och webbdelen.

Den här designen är lämplig för program som behöver kunna inkommande IP-adresser för klientkällor, till exempel för att hantera geoplatsspecifikt innehåll eller för loggning. Azure Firewall den inkommande trafiken genom att ändra den ursprungliga IP-källadressen. Application Gateway framför Azure Firewall det inkommande paketets käll-IP-adress i huvudet X-forwarded-for, så att webbservern kan se den ursprungliga IP-adressen i det här huvudet. Mer information finns i Så här fungerar en programgateway.

Inkommande HTTP(S)-anslutningar från Internet måste skickas till den offentliga IP-adressen för Application Gateway-, HTTP(S)-anslutningar från Azure eller lokalt till den privata IP-adressen. Från Application Gateway UDR:er ser du till att paketen dirigeras via Azure Firewall (mer information finns i paketvägen längre ned). För inkommande icke-HTTP(S)-anslutningar ska trafiken rikta in sig på den offentliga IP-adressen för Azure Firewall (om den kommer från det offentliga Internet), eller så skickas den via Azure Firewall av UDR:er (om de kommer från andra virtuella Azure-nätverk eller lokala nätverk). Alla utgående flöden från virtuella Azure-datorer vidarebefordras till Azure Firewall av UDR:er.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Flöden	Går igenom Application Gateway/WAF	Går igenom Azure Firewall
HTTP(S)-trafik från Internet/onprem till Azure	Ja	Ja
HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja
Icke-HTTP(S)-trafik från Internet/onprem till Azure	Inga	Ja
Icke-HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja

För webbtrafik från en lokal plats eller från Internet till Azure Azure Firewall att inspektera flöden som WAF redan har tillåtit. Beroende på om Application Gateway krypterar servertrafik (trafik från Application Gateway till programservrarna) har du två olika möjliga scenarier:

1. Den Application Gateway krypterar trafik enligt nollförtroendeprinciper (TLS-krypteringfrån slutpunkt till slutpunkt), och Azure Firewall tar emot krypterad trafik. Fortfarande kommer Azure Firewall Standard att kunna tillämpa inspektionsregler, till exempel L3/L4-filtrering i nätverksregler eller FQDN-filtrering i programregler med hjälp av SNI-huvudet (TLS Servernamnindikator). Azure Firewall Premium ger bättre insyn med IDPS, till exempel URL-baserad filtrering.
2. Om Application Gateway skickar okrypterad trafik till programservrarna ser Azure Firewall inkommande trafik i klartext. TLS-kontroll behövs inte i Azure Firewall.
3. Om IDPS är aktiverat i Azure Firewall kontrollerar den att HTTP-värdhuvudet matchar mål-IP-adressen. För detta ändamål behöver den namnmatchning för det FQDN som anges i värdhuvudet. Den här namnmatchning kan uppnås med Azure DNS Private Zones och standardinställningarna Azure Firewall DNS-inställningar med Azure DNS. Du kan också göra det med anpassade DNS-servrar som måste konfigureras i Azure Firewall inställningar. (Mer information finns i Azure Firewall DNS Inställningar.) Om det inte finns administrativ åtkomst till Virtual Network där Azure Firewall distribueras är den senare metoden den enda möjligheten. Ett exempel är när Azure Firewalls distribueras i Virtual WAN Säkra hubbar.

För resten av flöden (inkommande icke-HTTP(S)-trafik och eventuell utgående trafik) tillhandahåller Azure Firewall IDPS-inspektion och TLS-inspektion där det är lämpligt. Den tillhandahåller även FQDN-baserad filtrering i nätverksregler som baseras på DNS.

Nätverkstrafiken från det offentliga Internet följer det här flödet:

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Application Gateway:
   • Källans IP-adress: ClientPIP
   • Mål-IP-adress: AppGwPIP
2. Den Application Gateway instansen stoppar anslutningen från klienten och upprättar en ny anslutning med en av backend-klienterna. UDR till i Application Gateway-undernätet vidarebefordrar paketet till Azure Firewall, samtidigt som 192.168.1.0/24 mål-IP-adressen bevaras till webbappen:
   • Käll-IP-adress: 192.168.200.7 (privat IP-adress för Application Gateway instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-rubrik: ClientPIP
3. Azure Firewall SNAT-trafiken eftersom trafiken går till en privat IP-adress. Den vidarebefordrar trafiken till den virtuella programdatorn om reglerna tillåter det. Mer information finns i Azure Firewall SNAT.
   • Käll-IP-adress: 192.168.200.7 (den privata IP-adressen för Application Gateway instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-rubrik: ClientPIP
4. Den virtuella datorn svarar på begäran och återför käll- och mål-IP-adresser. Den UDR som avbildar paketet som skickas tillbaka till Application Gateway och omdirigerar det till Azure Firewall, samtidigt som 192.168.200.0/24 mål-IP-adressen bevaras mot Application Gateway.
   • Käll-IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
5. Även här Azure Firewall inte SNAT-trafiken eftersom den går till en privat IP-adress och vidarebefordrar trafiken till Application Gateway.
   • Käll-IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
6. Slutligen svarar Application Gateway-instansen klienten:
   • Källans IP-adress: AppGwPIP
   • Mål-IP-adress: ClientPIP

Utgående flöden från de virtuella datorerna till det offentliga Internet går Azure Firewall, enligt definitionen i UDR till 0.0.0.0/0 .

Application Gateway efter brandväggen

Med den här Azure Firewall du filtrera och ta bort skadlig trafik innan den når Application Gateway. Den kan till exempel använda funktioner som hotinformationsbaserad filtrering. En annan fördel är att programmet får samma offentliga IP-adress för både inkommande och utgående trafik.

Det finns begränsade fördelar i det här scenariot eftersom Azure Firewall endast ser krypterad trafik till Application Gateway. Det kan finnas scenarier där den här designen är att föredra. Ett fall är om en annan WAF finns tidigare i nätverket (till exempel med Azure Front Door). Eller så är designen att föredra om många offentliga IP-adresser krävs.

HTTP(S) inkommande flöden från det offentliga Internet ska rikta in sig på den offentliga IP-adressen för Azure Firewall, och Azure Firewall kommer DNAT paketen till den privata IP-adressen för Application Gateway. Från andra virtuella Azure-nätverk eller lokala nätverk ska HTTP(S)-trafik skickas till IP-adressen för Application Gateway och vidarebefordras via Azure Firewall med UDR:er. Standard-VNet-routning ser till att returtrafik från de virtuella Azure-datorerna går tillbaka till Application Gateway och från Application Gateway till Azure Firewall om DNAT-regler användes. För trafik från en on-prem eller Azure UDR i Application Gateway undernät ska användas (mer information finns i pakethanden längre ned). All utgående trafik från de virtuella Azure-datorerna till Internet skickas via Azure Firewall av UDR:er.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Flöden	Går igenom Application Gateway/WAF	Går igenom Azure Firewall
HTTP(S)-trafik från Internet/onprem till Azure	Yes	Ja (se nedan)
HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja
Icke-HTTP(S)-trafik från Internet/onprem till Azure	Inga	Ja
Icke-HTTP(S)-trafik från Azure till Internet/onprem	Inga	Ja

För inkommande HTTP(S)-trafik skulle Azure Firewall normalt inte dekryptera trafik. Det skulle i stället tillämpa IDPS-principer som inte kräver TLS-kontroll, t.ex. IP-baserad filtrering eller användning av HTTP-huvuden.

Programmet kan inte se den ursprungliga källans IP-adress för webbtrafiken. Azure Firewall SNAT:er paketen när de kommer in i det virtuella nätverket. Undvik problemet genom att Azure Front Door framför brandväggen. Azure Front Door in klientens IP-adress som ett HTTP-huvud innan den kommer in i det virtuella Azure-nätverket.

Nätverkstrafik från det offentliga Internet följer det här flödet:

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Firewall:
   • Källans IP-adress: ClientPIP
   • Mål-IP-adress: AzFWPIP
2. Den Azure Firewall TILL webbporten, vanligtvis TCP 443, till den privata IP-adressen för Application Gateway instansen. Azure Firewall även SNAT när du gör DNAT. Mer information finns i Azure Firewall kända problem:
   • Käll-IP-adress: 192.168.100.7 (den privata IP-adressen för Azure Firewall instansen)
   • Mål-IP-adress: 192.168.200.4
3. Den Application Gateway upprättar en ny session mellan den instans som hanterar anslutningen och en av backend-servrarna. Klientens ursprungliga IP-adress finns inte i paketet:
   • Käll-IP-adress: 192.168.200.7 (den privata IP-adressen för Application Gateway instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-rubrik: 192.168.100.7
4. Den virtuella datorn svarar Application Gateway käll- och mål-IP-adresser:
   • Käll-IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
5. Den Application Gateway svarar på SNAT-källans IP-adress för Azure Firewall instansen. Även om anslutningen kommer från en Application Gateway instans som , ser Azure Firewall den interna IP-adressen för Application Gateway som .7.4 käll-IP-adress:
   • Käll-IP-adress: 192.168.200.4
   • Mål-IP-adress: 192.168.100.7
6. Slutligen Azure Firewall SNAT och DNAT och svarar klienten:
   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

Även om Application Gateway inte har några lyssnare konfigurerade för program behöver den fortfarande en offentlig IP-adress så att Microsoft kan hantera den.

Lokala klienter

Föregående design visar alla programklienter som kommer från det offentliga Internet. Lokala nätverk har även åtkomst till program. De flesta av föregående informations- och trafikflöden är desamma som för Internetklienter, men det finns några viktiga skillnader:

• En VPN-gateway eller ExpressRoute-gateway finns framför Azure Firewall eller Application Gateway.
• WAF använder den privata IP-adressen för Application Gateway.
• Azure Firewall stöder inte DNAT för privata IP-adresser. Det är därför du måste använda UDR:er för att skicka inkommande trafik Azure Firewall från VPN- eller ExpressRoute-gatewayerna.
• Se till att kontrollera varningar kring tvingad tunnelingför Azure Application Gateway och för Azure Firewall. Även om din arbetsbelastning inte behöver utgående anslutning till det offentliga Internet kan du inte mata in en standardväg som för Application Gateway som pekar på det lokala nätverket, eller så bryter du 0.0.0.0/0 kontrolltrafiken. För Azure Application Gateway måste standardvägen peka på det offentliga Internet.

I följande diagram visas Azure Application Gateway och Azure Firewall parallell design. Programklienter kommer från ett lokalt nätverk som är anslutet till Azure via VPN eller ExpressRoute:

Även om alla klienter finns lokalt eller i Azure måste Azure Application Gateway och Azure Firewall ha offentliga IP-adresser. Med de offentliga IP-adresserna kan Microsoft hantera tjänsterna.

Topologi av typen hub-spoke

Designen i den här artikeln gäller fortfarande i en topologi med nav och ekrar. Delade resurser i ett centralt virtuellt hubbnätverk ansluter till program i separata virtuella ekernätverk via peering för virtuella nätverk.

Här är några saker att tänka på för den här topologin:

• Den Azure Firewall distribueras i det centrala virtuella hubbnätverket. Programteam hanterar dock ofta komponenter som Azure Application-gatewayer eller Azure API Management-gatewayer. Dessa komponenter distribueras i de virtuella ekernätverken.
• Var särskilt uppmärksam på UDR:er i ekernätverken: När en programserver i en eker tar emot trafik från en specifik Azure Firewall-instans, som adressen i föregående exempel, bör den skicka tillbaka trafik till 192.168.100.7 samma instans. Om en UDR i ekerenheten anger nästa hopp av trafik adresserad till hubben till Azure Firewall IP-adressen ( i diagrammen ovan) kan returnerade paket hamna på en annan Azure Firewall-instans, vilket orsakar asymmetrisk 192.168.100.4 routning. Om du har UDR:er i de virtuella ekernätverken för att skicka trafik till delade tjänster i hubben via Azure Firewall innehåller dessa UDR:er inte prefixet för Azure Firewall-undernätet.
• Den tidigare rekommendationen gäller Application Gateway nätverksundernät och andra virtuella nätverksapparater eller omvända proxys som kan distribueras i det virtuella hubbnätverket.
• Du kan inte ange nästa hopp för Application Gateway eller Azure Firewall via statiska vägar med nästa Virtual Network hopptyp. Den här nästa hopptypen är endast giltig i det lokala virtuella nätverket och inte mellan VNet-peerings. Mer information om användardefinierade vägar och nästa hopptyper finns i Trafikroutning för virtuellt nätverk.

Diagrammet nedan visar hur en eker skickar tillbaka SNATted-trafik tillbaka till ALB för en Azure Firewall. Den här konfigurationen orsakar asymmetrisk routning:

Lös problemet genom att definiera UDR:er i ekernätverket utan Azure Firewall-undernätet, men endast med de undernät där de delade tjänsterna finns. I det här exemplet ska rätt UDR i ekrarna endast innehålla 192.168.1.0/24. Den får inte innehålla hela 192.168.0.0/16, som markerats i rött.

Integrering med andra Azure-produkter

Du kan integrera Azure Firewall och Azure Application Gateway andra Azure-produkter och -tjänster.

API Management Gateway

Integrera omvända proxytjänster som API Management gateway i den tidigare designen för att tillhandahålla funktioner som API-begränsning eller autentiseringsproxy. Integreringen API Management en gateway ändrar inte designen så mycket. Den största skillnaden är att det i stället för Application Gateway en omvänd proxy finns två omvända proxyservrar som är kedjade bakom varandra.

Mer information finns i Designguide för att integrera API Management och Application Gateway i ett virtuellt nätverk och programmönstret API-gatewayer för mikrotjänster.

Azure Kubernetes Service

För arbetsbelastningar som körs i ett AKS-kluster kan du Azure Application Gateway oberoende av klustret. Eller så kan du integrera det med AKS-klustret med hjälp Azure Application Gateway Ingress Controller. När du konfigurerar vissa objekt på Kubernetes-nivå (till exempel tjänster och ingresser) anpassas Application Gateway automatiskt utan att extra manuella steg krävs.

Azure Firewall en viktig roll i AKS-klustersäkerhet. Den erbjuder de funktioner som krävs för att filtrera utgående trafik från AKS-klustret baserat på FQDN, inte bara IP-adress. Mer information finns i Kontrollera utgående trafik för AKS-klusternoder.

När du kombinerar Application Gateway och Azure Firewall för att skydda ett AKS-kluster är det bäst att använda alternativet för parallell design. Den Application Gateway med WAF bearbetar inkommande anslutningsbegäranden till webbprogram i klustret. Azure Firewall tillåter endast explicit tillåtna utgående anslutningar.

Azure Front Door

Azure Front Door överlappar delvis Azure Application Gateway. Båda tjänsterna erbjuder till exempel brandväggar för webbaserade program, SSL-avlastning och URL-baserad routning. En viktig skillnad är att Azure Application Gateway finns i ett virtuellt nätverk, Azure Front Door är en global, decentraliserad tjänst.

Ibland kan du förenkla utformningen av virtuella nätverk genom att Application Gateway med en decentraliserad Azure Front Door. De flesta designer som beskrivs här är giltiga, förutom alternativet att placera Azure Firewall framför Azure Front Door.

Ett intressant användningsfall är Azure Firewall framför Application Gateway i ditt virtuella nätverk. Som vi nämnde tidigare innehåller huvudet som matas in av Application Gateway brandväggsinstansens X-Forwarded-For IP-adress, inte klientens IP-adress. En lösning är att använda Azure Front Door framför brandväggen för att mata in klientens IP-adress som ett huvud innan trafiken kommer in i det virtuella nätverket och når X-Forwarded-For Azure Firewall.

Mer information om skillnaderna mellan de två tjänsterna, eller när du ska använda var och en av dem, finns i Vanliga frågor och svar för Azure Front Door.

Andra virtuella nätverks installationer

Microsoft-produkter är inte det enda valet för att implementera brandvägg för webbaserade program eller nästa generations brandväggsfunktioner i Azure. En mängd olika Microsoft-partner tillhandahåller virtuella nätverkstillverkade enheter (NVA). Begreppen och designerna är i stort sett desamma som i den här artikeln, men det finns några viktiga överväganden:

• Partner-NVA:er för nästa generations brandvägg kan erbjuda mer kontroll och flexibilitet för NAT-konfigurationer som inte stöds av Azure Firewall. Exempel är DNAT från en lokal plats eller DNAT från Internet utan SNAT.
• Azure-hanterade NVA:er (som Application Gateway och Azure Firewall) minskar komplexiteten jämfört med NVA:er där användarna behöver hantera skalbarhet och återhämtning över många installationer.
• När du använder NVA:er i Azure ska du använda konfigurationer för aktiv-aktiv och automatisk skalning, så dessa installationer är inte en flaskhals för program som körs i det virtuella nätverket.

Nästa steg

Läs mer om komponentteknikerna:

• Vad är Azure Application Gateway?
• Vad är Azure Firewall?
• Vad är Azure Front Door?
• Azure Kubernetes Service
• Vad är Azure Virtual Network?
• Vad är Azure-brandväggen för webbaserade program?

Relaterade resurser

Utforska relaterade arkitekturer:

• Implementera ett säkert hybridnätverk
• Webbprogram som hanteras på ett säkert sätt
• Skydda din Microsoft Teams-kanalrobot och webbapp bakom en brandvägg
• Portalen för konsumenthälsa i Azure
• Säkerhetsaspekter för mycket känsliga IaaS-appar i Azure
• SaaS med flera klientorganisationer på Azure
• Företagsdistribution med hjälp av App Services-miljön
• Företagsdistribution med hög tillgänglighet med hjälp av App Services-miljön
• Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service)