Scenario voor virtueel apparaat

Een veelvoorkomend scenario bij een grotere Azure-klant is de noodzaak om een toepassing met twee lagen beschikbaar te maken voor internet, terwijl toegang tot de back-servicelaag vanuit een on-premises datacenter mogelijk is. In dit document wordt een scenario beschreven met door de gebruiker gedefinieerde routes (UDR), een VPN Gateway en virtuele netwerkapparaten om een omgeving met twee lagen te implementeren die voldoet aan de volgende vereisten:

  • Webtoepassing moet alleen toegankelijk zijn vanaf het openbare internet.
  • De webserver die als host voor de toepassing wordt gebruikt, moet toegang hebben tot een back-endtoepassingsserver.
  • Al het verkeer van internet naar de webtoepassing moet via een virtueel firewallapparaat gaan. Dit virtuele apparaat wordt alleen gebruikt voor internetverkeer.
  • Al het verkeer dat naar de toepassingsserver gaat, moet via een virtueel firewallapparaat gaan. Dit virtuele apparaat wordt gebruikt voor toegang tot de back-endserver en toegang vanuit het on-premises netwerk via een VPN Gateway.
  • Beheerders moeten de virtuele firewallapparaten kunnen beheren vanaf hun on-premises computers door een derde virtueel firewallapparaat te gebruiken dat uitsluitend wordt gebruikt voor beheerdoeleinden.

Dit is een standaard perimeternetwerkscenario (ook wel DMZ genoemd) met een DMZ en een beveiligd netwerk. Een dergelijk scenario kan worden samengesteld in Azure met behulp van NSG's, virtuele firewallapparaten of een combinatie van beide. In de onderstaande tabel ziet u enkele voor- en nadelen tussen NSG's en virtuele firewallapparaten.

Voordelen Nadelen
NSG Geen kosten.
Geïntegreerd in Azure RBAC.
Regels kunnen worden gemaakt in Azure Resource Manager sjablonen.
De complexiteit kan variëren in grotere omgevingen.
Firewall Volledige controle over het gegevensvlak.
Centraal beheer via firewallconsole.
Kosten van firewallapparaat.
Niet geïntegreerd met Azure RBAC.

De onderstaande oplossing maakt gebruik van virtuele firewallapparaten voor het implementeren van een perimeternetwerk (DMZ)/beveiligd netwerkscenario.

Overwegingen

U kunt de hierboven beschreven omgeving als volgt implementeren in Azure met behulp van verschillende functies die momenteel beschikbaar zijn.

  • Virtueel netwerk (VNet) . Een Azure VNet werkt op dezelfde manier als een on-premises netwerk en kan worden gesegmenteerd in een of meer subnetten om verkeersisolatie en scheiding van problemen te bieden.
  • Virtueel apparaat. Verschillende partners bieden virtuele apparaten in de Azure Marketplace die kunnen worden gebruikt voor de drie firewalls die hierboven worden beschreven.
  • Door de gebruiker gedefinieerde routes (UDR). Routetabellen kunnen UDR's bevatten die worden gebruikt door Azure-netwerken om de stroom van pakketten binnen een VNet te bepalen. Deze routetabellen kunnen worden toegepast op subnetten. Een van de nieuwste functies in Azure is de mogelijkheid om een routetabel toe te passen op het GatewaySubnet, waardoor al het verkeer dat het Azure VNet binnenkomt, vanaf een hybride verbinding naar een virtueel apparaat kan worden doorgestuurd.
  • Doorsturen via IP. Standaard worden pakketten alleen door de Azure-netwerken engine doorgestuurd naar virtuele netwerkinterfacekaarten (NIC's) als het IP-adres van de pakketbestemming overeenkomt met het IP-adres van de NIC. Als een UDR definieert dat een pakket moet worden verzonden naar een bepaald virtueel apparaat, zou de Azure-netwerken engine dat pakket daarom laten vallen. Om ervoor te zorgen dat het pakket wordt geleverd aan een virtuele machine (in dit geval een virtueel apparaat) die niet de werkelijke bestemming voor het pakket is, moet u Doorsturen via IP inschakelen voor het virtuele apparaat.
  • Netwerkbeveiligingsgroepen (NSG's). In het onderstaande voorbeeld wordt geen gebruik gemaakt van NSG's, maar u kunt wel NSG's gebruiken die zijn toegepast op de subnetten en/of NIC's in deze oplossing om het verkeer in en uit deze subnetten en NIC's verder te filteren.

IPv6-connectiviteit

In dit voorbeeld is er een abonnement dat het volgende bevat:

  • 2 resourcegroepen, niet weergegeven in het diagram.
    • ONPREMRG. Bevat alle resources die nodig zijn om een on-premises netwerk te simuleren.
    • AZURERG. Bevat alle resources die nodig zijn voor de virtuele Azure-netwerkomgeving.
  • Een VNet met de naam onpremvnet dat wordt gebruikt om een on-premises datacenter na te bootsen dat is gesegmenteerd zoals hieronder wordt vermeld.
    • onpremsn1. Subnet met een virtuele machine (VM) met Ubuntu om een on-premises server na te bootsen.
    • onpremsn2. Subnet met een VM met Ubuntu om een on-premises computer na te bootsen die wordt gebruikt door een beheerder.
  • Er is één virtueel firewallapparaat met de naam OPFW op onpremvnet dat wordt gebruikt om een tunnel naar azurevnet te onderhouden.
  • Een VNet met de naam azurevnet, gesegmenteerd zoals hieronder wordt vermeld.
    • azsn1. Extern firewallsubnet dat uitsluitend wordt gebruikt voor de externe firewall. Al het internetverkeer komt binnen via dit subnet. Dit subnet bevat alleen een NIC die is gekoppeld aan de externe firewall.
    • azsn2. Front-endsubnet dat als host voor een virtuele machine wordt uitgevoerd als een webserver die toegankelijk is via internet.
    • azsn3. Back-endsubnet dat als host wordt gebruikt voor een virtuele machine met een back-endtoepassingsserver die wordt gebruikt door de front-endwebserver.
    • azsn4. Beheersubnet dat uitsluitend wordt gebruikt voor beheertoegang tot alle virtuele firewallapparaten. Dit subnet bevat alleen een NIC voor elk virtueel firewallapparaat dat in de oplossing wordt gebruikt.
    • GatewaySubnet. Hybride Azure-verbindingssubnet dat is vereist voor ExpressRoute en VPN Gateway connectiviteit tussen Azure-VNets en andere netwerken te bieden.
  • Er zijn drie virtuele firewallapparaten in het azurevnet-netwerk.
    • AZF1. Externe firewall die wordt blootgesteld aan het openbare internet met behulp van een openbare IP-adresresource in Azure. U moet ervoor zorgen dat u een sjabloon van de Marketplace hebt, of rechtstreeks van de leverancier van uw apparaat, die een virtueel apparaat met 3 NIC's in voor ogen heeft.
    • AZF2. Interne firewall die wordt gebruikt om verkeer tussen azsn2 en azsn3 te beheren. Dit is ook een virtueel 3-NIC-apparaat.
    • AZF3. Beheerfirewall toegankelijk voor beheerders vanuit het on-premises datacenter en verbonden met een beheersubnet dat wordt gebruikt voor het beheren van alle firewallapparaten. U vindt sjablonen voor virtuele 2-NIC-apparaten in Marketplace of u kunt er rechtstreeks een aanvragen bij de leverancier van uw apparaat.

Door de gebruiker gedefinieerde routering (UDR)

Elk subnet in Azure kan worden gekoppeld aan een UDR-tabel die wordt gebruikt om te definiëren hoe verkeer dat in dat subnet wordt geïnitieerd, wordt gerouteerd. Als er geen UDR's zijn gedefinieerd, gebruikt Azure standaardroutes om verkeer van het ene subnet naar het andere te laten stromen. Ga naar What are User Defined Routes and IP Forwarding (Wat zijn door de gebruiker gedefinieerde routes en DOORsturen via IP) voor een beter begrip van UDR's.

Om ervoor te zorgen dat de communicatie wordt uitgevoerd via het juiste firewallapparaat, op basis van de bovenstaande laatste vereiste, moet u de volgende routetabel maken met UDR's in azurevnet.

azgwudr

In dit scenario wordt het enige verkeer dat van on-premises naar Azure stroomt, gebruikt om de firewalls te beheren door verbinding te maken met AZF3 en dat verkeer via de interne firewall, AZF2, moet gaan. Daarom is er slechts één route nodig in het GatewaySubnet, zoals hieronder wordt weergegeven.

Doel Volgende hop Uitleg
10.0.4.0/24 10.0.3.11 Hiermee kan on-premises verkeer beheerfirewall AZF3 bereiken

azsn2udr

Doel Volgende hop Uitleg
10.0.3.0/24 10.0.2.11 Hiermee staat u verkeer toe naar het back-endsubnet dat als host voor de toepassingsserver wordt gehost via AZF2
0.0.0.0/0 10.0.2.10 Staat toe dat al het andere verkeer wordt gerouteerd via AZF1

azsn3udr

Doel Volgende hop Uitleg
10.0.2.0/24 10.0.3.10 Staat toe dat verkeer naar azsn2 van de app-server naar de webserver stroomt via AZF2

U moet ook routetabellen maken voor de subnetten in onpremvnet om het on-premises datacenter na te bootsen.

onpremsn1udr

Doel Volgende hop Uitleg
192.168.2.0/24 192.168.1.4 Staat verkeer toe naar onpremsn2 via OPFW

onpremsn2udr

Doel Volgende hop Uitleg
10.0.3.0/24 192.168.2.4 Hiermee staat u verkeer toe naar het subnet met ondersteuning in Azure via OPFW
192.168.1.0/24 192.168.2.4 Staat verkeer toe naar onpremsn1 via OPFW

Doorsturen via IP

Doorsturen via UDR en IP zijn functies die u in combinatie kunt gebruiken om virtuele apparaten toe te staan om de verkeersstroom in een Azure-VNet te controleren. Een virtueel apparaat is niets meer dan een virtuele machine waarop een toepassing wordt uitgevoerd om netwerkverkeer op een bepaalde manier af te handelen, zoals een firewall of een NAT-apparaat.

Deze VM op het virtuele apparaat moet in staat zijn om binnenkomend verkeer te ontvangen dat niet is geadresseerd aan zichzelf. Om met een VM verkeer te kunnen ontvangen dat is geadresseerd aan andere bestemmingen, moet u Doorsturen via IP inschakelen voor die VM. Dit is een Azure-instelling, niet een instelling in het gastbesturingssysteem. Uw virtuele apparaat moet nog steeds een bepaald type toepassing uitvoeren om het binnenkomende verkeer te verwerken en het op de juiste wijze te routeeren.

Ga naar What are User Defined Routes and IP Forwarding (Wat zijn door de gebruiker gedefinieerde routes en doorsturen via IP) voor meer informatie over doorsturen via IP.

Stel bijvoorbeeld dat u de volgende installatie in een Azure-vnet hebt:

  • Subnet onpremsn1 bevat een VM met de naam onpremvm1.
  • Subnet onpremsn2 bevat een VM met de naam onpremvm2.
  • Een virtueel apparaat met de naam OPFW is verbonden met onpremsn1 en onpremsn2.
  • Een door de gebruiker gedefinieerde route die is gekoppeld aan onpremsn1 geeft aan dat al het verkeer naar onpremsn2 moet worden verzonden naar OPFW.

Als onpremvm1 op dit moment probeert een verbinding tot stand te brengen met onpremvm2, wordt de UDR gebruikt en wordt verkeer naar OPFW verzonden als de volgende hop. Houd er rekening mee dat de werkelijke pakketbestemming niet wordt gewijzigd. Er wordt nog steeds onpremvm2 als doel gebruikt.

Als doorsturen via IP niet is ingeschakeld voor OPFW, worden de pakketten door de virtuele netwerklogica van Azure niet meer gebruikt, omdat hierdoor alleen pakketten naar een virtuele machine kunnen worden verzonden als het IP-adres van de virtuele machine de bestemming voor het pakket is.

Met doorsturen via IP worden de pakketten door de logica van het virtuele Azure-netwerk doorgestuurd naar OPFW, zonder het oorspronkelijke doeladres te wijzigen. OPFW moet de pakketten verwerken en bepalen wat ermee moet worden doen.

Het bovenstaande scenario werkt alleen als u Doorsturen via IP inschakelen op de NIC's voor OPFW, AZF1, AZF2 en AZF3 die worden gebruikt voor routering (alle NIC's behalve de NIC's die zijn gekoppeld aan het beheersubnet).

Firewallregels

Zoals hierboven beschreven, zorgt doorsturen via IP er alleen voor dat pakketten naar de virtuele apparaten worden verzonden. Uw apparaat moet nog steeds bepalen wat er met deze pakketten moet worden gebeurd. In het bovenstaande scenario moet u de volgende regels maken in uw apparaten:

OPFW

OPFW vertegenwoordigt een on-premises apparaat met de volgende regels:

  • Route: al het verkeer naar 10.0.0.0/16 (azurevnet) moet worden verzonden via de tunnel ONPREMAZURE.
  • Beleid: Sta al het bidirectionele verkeer tussen poort2 en ONPREMAZURE toe.

AZF1

AZF1 vertegenwoordigt een virtueel Azure-apparaat met de volgende regels:

  • Beleid: Sta al het bidirectionele verkeer tussen poort1 en poort2 toe.

AZF2

AZF2 vertegenwoordigt een virtueel Azure-apparaat met de volgende regels:

  • Beleid: Sta al het bidirectionele verkeer tussen poort1 en poort2 toe.

AZF3

AZF3 vertegenwoordigt een virtueel Azure-apparaat met de volgende regels:

  • Route: al het verkeer naar 192.168.0.0/16 (onpremvnet) moet via poort1 worden verzonden naar het IP-adres van de Azure-gateway (bijvoorbeeld 10.0.0.1).

Netwerkbeveiligingsgroepen (NSG's)

In dit scenario worden er geen NSG's gebruikt. U kunt echter NSG's toepassen op elk subnet om binnenkomend en uitgaand verkeer te beperken. U kunt bijvoorbeeld de volgende NSG-regels toepassen op het externe FW-subnet.

Binnenkomende

  • Sta al het TCP-verkeer van internet naar poort 80 op een VM in het subnet toe.
  • Al het andere verkeer van internet weigeren.

Uitgaande

  • Al het verkeer naar internet weigeren.

Stappen op hoog niveau

Volg de onderstaande stappen op hoog niveau om dit scenario te implementeren.

  1. Meld u aan bij uw Azure-abonnement.
  2. Als u een VNet wilt implementeren om het on-premises netwerk na te bootsen, moet u de resources inrichten die deel uitmaken van ONPREMRG.
  3. De resources inrichten die deel uitmaken van AZURERG.
  4. De tunnel van onpremvnet naar azurevnet inrichten.
  5. Zodra alle resources zijn ingericht, meld u zich aan bij onpremvm2 en pingt u 10.0.3.101 om de connectiviteit tussen onpremsn2 en azsn3 te testen.