De cloud verandert de manier waarop infrastructuur is ontworpen, met inbegrip van 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 actieve gateway-IP-adres te wisselen voor alle services die worden uitgevoerd op een VNet/subnet.
- Door Azure API beheerde zwevende IP: deze optie maakt gebruik van een secundair IP-adres op de firewalls dat kan worden verplaatst tussen een actieve en een stand-by firewall.
- Beheerd door Load Balancer: deze optie maakt gebruik van een Azure Load Balancer om te fungeren als het gateway-IP-adres voor het subnet, waarna het verkeer wordt doorgestuurd naar de actieve firewall. 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 firewall moet de failover instructies geven, wat in feite een "herconfiguratie" is van Azure-services via een nieuwe implementatie. Afhankelijk van de snelheid waarmee de implementatie wordt voltooid, worden de verkeersstromen enkele minuten inactief. Bovendien is er geen mogelijkheid voor een actief-actief configuratie waarbij beide firewalls op hetzelfde moment actief zijn.
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 load balancers echter niet alleen gebruiken als 'standaardgateways', omdat deze 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 inkomende 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 voor FW-1 SNAT is ingeschakeld, ziet server S1 het verkeer dat afkomstig is van het interne IP-adres van FW-1. Het antwoord wordt dus ook naar FW-1 gestuurd. In dit scenario kan failover snel plaatsvinden naar FW-2. Voor uitgaand verkeer kunnen we nog een load balancer aan de interne zijde toevoegen. Wanneer server S1 verkeer start, is hetzelfde principe van toepassing. Verkeer raakt de interne LB (iLB), die een firewall kiest die NAT vervolgens omkeert voor externe oplossing:
Driezijdige firewalls
Er doen zich problemen voor wanneer we een andere interface aan de firewall toevoegen en u NAT-vertaling tussen interne zones moet uitschakelen. Zie in dit geval Subnet-B en Subnet-C:
De L3-routering tussen de interne zones (Subnet-B en Subnet-C) wordt gelijkmatig verdeeld zonder NAT. Deze installatie wordt duidelijker als u de verkeersstromen bekijkt, 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 IP-adres S1 als het bronadres. S2 verzendt vervolgens het retourverkeer voor subnet B (waarvan S1-IP deel uitmaken) naar de iLB in Subnet-C. Omdat iLB in Subnet-B en iLB in Subnet-C hun sessiesituaties niet synchroniseert, kan het verkeer op FW-2 eindigen, afhankelijk van het taakverdelingsalgoritme. FW-2 weet standaard niets over het eerste (groene) pakket, waardoor de verbinding wordt laten vallen.
Sommige firewallleveranciers proberen een verbindingstoestand tussen de firewalls te behouden, maar ze moeten vrijwel direct synchroniseren om de verbindingstoestanden up-to-date te houden. 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 het elimineren van Subnet-C, waardoor we de voordelen van gevirtualiseerde VNets kunnen benutten.
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 gebruiken één back-endroutersysteem van Azure en daarom hoeft u geen router-IP op te geven voor elk subnet. 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 start (groen), wordt dit verdeeld 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, dus dit verkeer wordt altijd terug naar FW-1. FW-1 verzendt deze vervolgens naar S1 om een synchrone verkeersstroom tot stand te brengt.
Deze installatie werkt alleen als de fw een routetabel (intern) heeft die Subnet-B en Subnet-C verwijst naar de standaard-GW van het subnet. Die 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, zou deze normaal gesproken achter de fw staan. U kunt deze in plaats daarvan in overeenstemming met de fw zetten en het verkeer daadwerkelijk door de fw leiden. Het voordeel van deze installatie is dat de omgekeerde proxyservice het oorspronkelijke IP-adres van de verbindende client zou zien:
Voor deze configuratie moeten de routetabellen op Subnet-E Subnet-B en Subnet-C door de interne load balancer. Sommige services voor omgekeerde proxy's hebben ingebouwde firewalls waarmee u de firewall 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 installatie betekent dat de routeringstabel ook ruimte moet bieden aan de subnetten achter deze verbindingen. Hoewel er geen groot verschil is met de subnet-B/C-connectiviteit, zit er in het ontwerp van het retourverkeer, wat de volgende afbeelding voltooit:
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. Het GatewaySubnet heeft ook een aangepaste route die Subnet-B-C naar de iLB wijst. 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 rangschikking vermijdt de 'normale' VNET-routering om de FWs 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 als DMZ/internet/enzovoort behandelt.
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.
Volgende stappen
Meer informatie over de onderdeeltechnologieën:
Gerelateerde architecturen verkennen:
- Veilig hybride netwerk implementeren
- Hybride verbinding
- Een on-premises netwerk uitbreiden met VPN
- Kiezen tussen virtuele netwerkpeering en VPN-gateways
- Problemen met een hybride VPN-verbinding oplossen
- Een sternetwerktopologie in Azure
- Zelfstandige servers verbinden met de Azure-netwerkadapter
- Aangepaste gegevenssoevereiniteit & vereisten voor data-ernst
- SQL Server 2008 R2-failovercluster in Azure