De cloud verandert de manier waarop infrastructuur wordt ontworpen, inclusief het ontwerp van firewalls, omdat het netwerk niet meer fysiek of in virtuele LAN's is. Niet alle functies van een fysiek netwerk zijn beschikbaar in een virtueel netwerk (VNet). Dit omvat het gebruik van zwevende IP-adressen of broadcastverkeer en dat beïnvloedt de implementatie van maximaal beschikbare architecturen (HA). Load balancers voor Virtuele netwerkapparaten kunnen/moeten op een bepaalde manier worden geïmplementeerd om een maximaal beschikbare architectuur (HA) binnen een virtueel netwerk te krijgen. Deze gids biedt een gestructureerde benadering voor het ontwerpen van HA-firewalls in Azure met behulp van virtuele apparaten van derden.
Opties voor het ontwerpen van maximaal beschikbare virtuele netwerkapparaten
Bij het implementeren van HA-architecturen zijn er enkele opties om failover te bieden:
- Door Azure API beheerde routetabellen: deze optie maakt gebruik van twee routetabellen, één actief, één passief om het ip-adres van de actieve gateway over te schakelen voor alle services die worden uitgevoerd op een VNet/subnet.
- Zwevend IP-adres dat door Azure API wordt beheerd: deze optie maakt gebruik van een secundair IP-adres op de FW's die kunnen worden verplaatst tussen een actieve en een stand-by-FW.
- Load Balancer beheerd: deze optie maakt gebruik van een Azure Load Balancer om te fungeren als het gateway-IP-adres voor het subnet, waarmee het verkeer vervolgens wordt doorgestuurd naar de actieve FW. Dit kan zelfs het verkeer actief-actief doorsturen om te zorgen voor echte taakverdeling.
Het probleem met de eerste twee opties is dat failover zelf langzaam is. De FW moet de failover instrueren. Dit is in feite een 'herconfiguratie' van Azure-services via een nieuwe implementatie. Afhankelijk van de snelheid waarmee de implementatie wordt voltooid, worden de verkeersstromen enkele minuten inactief. Bovendien is het niet mogelijk om een actief-actief-configuratie toe te staan waarbij beide firewalls tegelijkertijd werken.
Daarom heeft de derde optie de meeste voorkeur. De uitvaltijd wordt geminimaliseerd omdat de load balancer vrijwel meteen een failover kan uitvoeren naar de stand-by firewall (in actief-passief) of de belasting eenvoudigweg kan verwijderen van de firewall met een probleem (in actief-actief). U kunt echter niet alleen load balancers gebruiken als 'standaardgateways' omdat ze van invloed zijn op de verkeersstroom en TCP-pakketten stateful moeten zijn.
Tweezijdige firewalls
De volgende afbeelding begint met twee firewalls (FW-1 en FW-2), met een externe load balancer en een back-endserver S1.
Deze architectuur is een eenvoudige installatie die wordt gebruikt voor binnenkomend verkeer. Een pakket treft de load balancer, die de doelfirewall uit de configuratie kiest. De gekozen firewall verzendt het verkeer vervolgens naar de back-endserver (web). Als FW-1 SNAT heeft ingeschakeld, ziet server S1 het verkeer dat afkomstig is van het interne IP-adres van FW-1, zodat ook het antwoord naar het pakket wordt verzonden naar FW-1. In dit scenario kan failover snel plaatsvinden naar FW-2. Voor uitgaand verkeer kunnen we nog een load balancer toevoegen aan de interne kant. Wanneer server S1 verkeer start, wordt hetzelfde principe toegepast. Verkeer raakt de interne LB (iLB), die een firewall kiest die vervolgens NAT vertaalt voor externe resolutie:
Driezijdige firewalls
Er treden problemen op wanneer we een andere interface toevoegen aan de firewall en u moet NAT-vertaling tussen interne zones uitschakelen. In dit geval raadpleegt u Subnet-B en Subnet-C:
De L3-routering tussen de interne zones (Subnet-B en Subnet-C) wordt gelijkmatig verdeeld zonder NAT. Deze instelling wordt duidelijker naar de verkeersstromen, inclusief de load balancers in een andere weergave. In het onderstaande diagram ziet u de weergave waarin de interne load balancers [iLB] zijn gekoppeld aan een specifieke NIC op de firewalls:
Met L3-verkeer (zonder NAT) ziet S2 het S1 IP-adres als het bronadres. S2 verzendt vervolgens het retourverkeer voor subnet B (waartoe S1-IP behoort) aan de iLB in Subnet-C. Omdat iLB in Subnet-B en iLB in Subnet-C hun sessiestatussen niet synchroniseert, kan het verkeer van het taakverdelingsalgoritmen uiteindelijk eindigen op FW-2. FW-2 weet standaard niets over het oorspronkelijke (groene) pakket, zodat de verbinding wordt uitgeschakeld.
Sommige firewallleveranciers proberen een verbindingsstatus tussen de firewalls te behouden, maar ze hebben bijna directe synchronisatie nodig om up-to-date te zijn op de verbindingsstatussen. Vraag bij de leverancier van uw firewall na of deze instelling wordt aanbevolen.
De beste manier om dit probleem te verhelpen is om het weg te nemen. In het bovenstaande voorbeeld betekent deze oplossing dat subnet-C wordt geëlimineerd, wat ons de voordelen van gevirtualiseerde VNets biedt.
Hosts in een subnet isoleren met netwerkbeveiligingsgroepen
Wanneer er twee virtuele machines in één subnet zijn, kunt u een netwerkbeveiligingsgroep toepassen waarmee het verkeer tussen de twee wordt geïsoleerd. Standaard is verkeer binnen een VNet volledig toegestaan. Als u een regel Alles negeren toevoegt aan de netwerkbeveiligingsgroep, worden alle virtuele machines van elkaar geïsoleerd.
VNets gebruiken dezelfde back-endrouters (virtueel)
VNet/subnetten maken gebruik van één back-endroutersysteem van Azure en daarom hoeft u geen router-IP voor elk subnet op te geven. Het routedoel kan ergens in hetzelfde VNet of zelfs erbuiten zijn.
Met de gevirtualiseerde netwerken kunt u de routes in elk subnet beheren. Deze routes kunnen ook verwijzen naar een enkel IP-adres in een ander subnet. In de bovenstaande afbeelding is dat de iLB in subnet-D, waarmee de taken over de twee firewalls worden verdeeld. Als S1 verkeer (groen) start, wordt het taakverdeling naar bijvoorbeeld FW-1. FW-1 maakt vervolgens verbinding met S2 (nog groen). S2 verzendt het antwoordverkeer naar het IP-adres van S1 (omdat NAT is uitgeschakeld). Vanwege de routetabellen gebruikt S2 hetzelfde iLB IP-adres als de gateway. De iLB kan overeenkomen met het verkeer naar de eerste sessie, zodat dit verkeer altijd wordt teruggezet naar FW-1. FW-1 stuurt deze vervolgens naar S1, waarbij een synchrone verkeersstroom tot stand wordt gebracht.
Deze installatie werkt alleen als de FW een routetabel (intern) heeft die subnet-B en subnet-C naar de standaardsubnet-GW wijst. Dat subnet GW is het eerste logisch beschikbare IP-adres in het subnetbereik in dat VNET.
Gevolgen voor services voor omgekeerde proxy's
Wanneer u een omgekeerde proxyservice implementeert, bevindt deze zich normaal gesproken achter de FW. U kunt het in plaats daarvan in overeenstemming brengen met de FW en het verkeer daadwerkelijk doorsturen via de FW. Het voordeel van deze installatie is dat de omgekeerde proxyservice het oorspronkelijke IP-adres van de verbindingsclient zou zien :
Voor deze configuratie moeten de routetabellen in Subnet-E via de interne load balancer verwijzen naar Subnet-B en Subnet-C. Sommige omgekeerde proxyservices hebben ingebouwde firewalls waarmee u de FW allemaal in deze netwerkstroom kunt verwijderen. De ingebouwde firewalls wijzen van omgekeerde proxy rechtstreeks naar Subnet-B/C-servers.
In dit scenario is SNAT ook vereist in de omgekeerde proxy om te voorkomen dat retourverkeer verder stroomt en wordt geweigerd door de firewalls naar Subnet-A.
VPN/ER
Azure biedt door BGP ingeschakelde/maximaal beschikbare VPN-/ER-services via de Azure Virtual Network Gateways. De meeste architecten houden deze voor back-end- of niet-internetgerichte verbindingen. Deze instelling betekent dat de routeringstabel ook geschikt moet zijn voor de subnetten achter deze verbindingen. Hoewel er geen groot verschil is in subnet-B/C-connectiviteit, is er sprake van het ontwerp van het retourverkeer, waarbij de afbeelding wordt voltooid:
In deze architectuur wordt het verkeer van de firewall van, bijvoorbeeld Subnet-B naar Subnet-X, verzonden naar de iLB, die het op zijn beurt naar een firewall verzendt. De interne route in de firewall stuurt het verkeer terug naar de subnetgateway (eerste beschikbare IP-adres in Subnet-D). U hoeft het verkeer niet rechtstreeks naar het gatewayapparaat zelf te verzenden, omdat een andere route op Subnet-D een route heeft voor Subnet-X die het naar de virtuele netwerkgateway verwijst. De werkelijke routering wordt afgehandeld door Azure-netwerken.
Retourverkeer dat afkomstig is van Subnet-X, wordt doorgestuurd naar de iLB in Subnet-D. GatewaySubnet heeft ook een aangepaste route die subnet-B-C naar de iLB verwijst. Subnet-D is niet via de iLB. Dit wordt behandeld als normale routering tussen VNet's.
Dit staat niet op de tekening, maar het zou zinvol zijn om een Subnet-B/C/D/gateway te gebruiken om ook een route voor Subnet-A toe te voegen die het naar de iLB verwijst. Deze regeling voorkomt dat de 'reguliere' VNET-routering om de FW's te omzeilen. Dit omdat Subnet-A gewoon een subnet in het VNet is volgens de Azure-netwerkstack. Subnet-A wordt niet anders behandeld, hoewel u het behandelt als DMZ/Internet/etc.
Samenvatting
Kort gezegd is de manier waarop u firewalls op uw on-premises netwerken (fysiek/VLAN) behandelt, met zoveel interfaces (virtueel of fysiek), niet hetzelfde als in Azure. Indien nodig is het nog steeds mogelijk (tot op zekere hoogte), maar er zijn wel betere manieren om de uitvaltijd te minimaliseren en actieve-actieve implementaties en schone routeringstabellen te hebben.
Meer informatie over het gebruik van load balancers als gateway voor al het verkeer is te vinden in Overzicht van poorten met hoge beschikbaarheid.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Roelf Zomerman | Senior Cloud Solution Architect
Volgende stappen
Meer informatie over de onderdeeltechnologieën:
Verwante resources
Gerelateerde architecturen verkennen:
- Een beveiligd hybride netwerk implementeren
- Hybride verbinding
- Een on-premises netwerk uitbreiden met VPN
- Kiezen tussen peering van virtuele netwerken en VPN-gateways
- Problemen met een hybride VPN-verbinding oplossen
- Hub-spoke-netwerktopologie in Azure
- Verbinding maken zelfstandige servers met behulp van Azure Network Adapter