Scenario voor virtuele apparaten

Een veelvoorkomend scenario bij grotere Azure-klanten is de noodzaak om een tweelaagse toepassing te bieden die is blootgesteld aan internet, terwijl u toegang tot de back-laag hebt vanuit een on-premises datacenter. In dit document wordt een scenario beschreven met UDR (User Defined Routes), een VPN Gateway en virtuele netwerkapparaten om een tweelaagse omgeving te implementeren die aan de volgende vereisten voldoet:

  • Webtoepassing moet alleen toegankelijk zijn vanaf het openbare internet.
  • Webserver die de toepassing host, moet toegang hebben tot een back-mailtoepassingsserver.
  • Alle verkeer van internet naar de webtoepassing moet via een virtuele firewall worden gebruikt. Dit virtuele apparaat wordt alleen gebruikt voor internetverkeer.
  • Al het verkeer dat naar de toepassingsserver gaat, moet via een virtuele firewall worden uitgevoerd. 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 firewall virtuele apparaten kunnen beheren vanaf hun on-premises computers, met behulp van een derde virtuele firewall die uitsluitend voor beheerdoeleinden wordt gebruikt.

Dit is een standaardperimeternetwerk (ook wel DMZ genoemd) scenario met een DMZ en een beveiligd netwerk. Een dergelijk scenario kan in Azure worden gemaakt met 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.

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

De onderstaande oplossing gebruikt virtuele firewallapparatuur om een perimeternetwerk (DMZ)/protected network scenario te implementeren.

Overwegingen

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

  • 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 het verkeer te isoleren en problemen te scheiden.
  • 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 UR's bevatten die door Azure-netwerken worden gebruikt 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, zodat al het verkeer dat vanuit een hybride verbinding naar een virtueel apparaat naar het Azure VNet komt, kan worden doorgestuurd.
  • IP-doorsturen. Standaard worden pakketten alleen doorgestuurd met de Azure-netwerk engine naar virtuele netwerkinterfacekaarten (NIC's) als het IP-adres van de pakketbestemming overeenkomt met het IP-adres van NIC. Als een UDR definieert dat een pakket moet worden verzonden naar een bepaald virtueel apparaat, wordt dat pakket daarom door de Azure-netwerkings engine neer laten vallen. Om ervoor te zorgen dat het pakket wordt bezorgd bij een VM (in dit geval een virtueel apparaat) dat niet de werkelijke bestemming van het pakket is, moet u IP-doorsturen voor het virtuele apparaat inschakelen.
  • Netwerkbeveiligingsgroepen (NSG's). In het onderstaande voorbeeld wordt geen gebruik gemaakt van NSG's, maar u kunt 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, die niet worden 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 azure virtuele 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 computer (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 door een beheerder wordt gebruikt.
  • 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 vermeld.
    • azsn1. Externe firewall subnet dat uitsluitend voor de externe firewall wordt gebruikt. Al het internetverkeer komt binnen via dit subnet. Dit subnet bevat alleen een NIC die is gekoppeld aan de externe firewall.
    • azsn2. Front end subnet hosting a VM running as a web server that will be accessed from the Internet.
    • azsn3. Backend subnet hosting a VM running a backend application server that will be accessed by the front end web server.
    • azsn4. Beheerssubnet dat uitsluitend wordt gebruikt om beheertoegang te bieden tot alle virtuele firewallapparaten. Dit subnet bevat alleen een NIC voor elk virtueel firewallapparaat dat in de oplossing wordt gebruikt.
    • GatewaySubnet. Azure hybrid connection subnet required for ExpressRoute and VPN Gateway to provide connectivity between Azure VNets and other networks.
  • Er zijn 3 firewall virtuele apparaten in het azurevnet-netwerk.
    • AZF1. Externe firewall die is blootgesteld aan het openbare internet met behulp van een openbare IP-adresbron in Azure. U moet ervoor zorgen dat u een sjabloon hebt van de Marketplace, of rechtstreeks van de leverancier van uw apparaat, die een virtueel 3-NIC-apparaat bevat.
    • AZF2. Interne firewall die wordt gebruikt om het 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 beheerssubnet dat wordt gebruikt voor het beheren van alle firewallapparatuur. U vindt 2-NIC-NIC-sjablonen voor virtuele apparaten in de 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 gestart, wordt gerouteerd. Als er geen UDR's zijn gedefinieerd, gebruikt Azure standaardroutes om het verkeer van het ene subnet naar het andere te laten stromen. Ga naar Wat zijn door de gebruiker gedefinieerde routes en IP-doorsturenvoor meer informatie over UR's.

Om ervoor te zorgen dat de communicatie via het juiste firewallapparaat wordt uitgevoerd, moet u op basis van de bovenstaande laatste vereiste de volgende routetabel maken met UR'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 AZF3en dat verkeer moet worden uitgevoerd via de interne firewall, AZF2. Daarom is er slechts één route nodig in het GatewaySubnet, zoals hieronder wordt weergegeven.

Bestemming Volgende hop Uitleg
10.0.4.0/24 10.0.3.11 On-premises verkeer kan beheerfirewall AZF3 bereiken

azsn2udr

Bestemming Volgende hop Uitleg
10.0.3.0/24 10.0.2.11 Hiermee kunt u verkeer naar het backend-subnet dat de toepassingsserver host via AZF2
0.0.0.0/0 10.0.2.10 Hiermee kan al het andere verkeer worden omgeleid via AZF1

azsn3udr

Bestemming Volgende hop Uitleg
10.0.2.0/24 10.0.3.10 Hiermee kan verkeer naar azsn2 van de app-server naar de webserver stromen via AZF2

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

onpremsn1udr

Bestemming Volgende hop Uitleg
192.168.2.0/24 192.168.1.4 Hiermee kan verkeer onpremsn2 viaOPFW

onpremsn2udr

Bestemming Volgende hop Uitleg
10.0.3.0/24 192.168.2.4 Hiermee kunt u verkeer naar het backed subnet in Azure via OPFW
192.168.1.0/24 192.168.2.4 Hiermee kan verkeer onpremsn1 via OPFW

IP-doorsturen

UDR en IP Forwarding zijn functies die u in combinatie kunt gebruiken om virtuele apparaten te gebruiken om de verkeersstroom in een Azure VNet te bepalen. Een virtueel apparaat is niets meer dan een VM waarmee een toepassing wordt uitgevoerd die wordt gebruikt voor het verwerken van netwerkverkeer op een bepaalde manier, zoals een firewall of een NAT-apparaat.

Dit virtuele apparaat VM moet inkomende verkeer kunnen ontvangen dat niet aan zichzelf is gericht. Als u wilt toestaan dat een VM verkeer ontvangt dat is geadresseerd aan andere bestemmingen, moet u IP-doorsturen voor de VM inschakelen. Dit is een Azure-instelling, geen 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 manier te routen.

Ga naar Wat zijn door de gebruiker gedefinieerde routes en IP-doorsturen voor meer informatie over IP-doorsturen.

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

  • Subnet onpremsn1 bevat een VM met de naam onpremvmm1.
  • Subnet onpremsn2 bevat een VM met de naam onpremvmm2.
  • 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 op dit moment onpremvm1 probeert een verbinding tot stand te brengen met onpremvm2,wordt de UDR gebruikt en wordt het verkeer naar OPFW verzonden als de volgende hop. Houd er rekening mee dat de werkelijke pakketbestemming niet wordt gewijzigd, maar dat onpremvmm2 de bestemming is.

Als IP-doorsturen niet is ingeschakeld voor OPFW,worden de pakketten door de azure-logica voor virtuele netwerken niet meer verzonden, omdat hiermee alleen pakketten naar een VM kunnen worden verzonden als het IP-adres van de VM de bestemming van het pakket is.

Met IP Forwarding worden de pakketten door de virtuele netwerklogica van Azure doorgestuurd naar OPFW, zonder het oorspronkelijke doeladres te wijzigen. OPFW moet de pakketten verwerken en bepalen wat u ermee moet doen.

Als het bovenstaande scenario werkt, moet u IP-doorsturen inschakelen op de NPC's voor OPFW,AZF1,AZF2en AZF3 die worden gebruikt voor routering (alle NIC's behalve die die zijn gekoppeld aan het beheersubnet).

Firewallregels

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

OPFW

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

  • Route:Alle verkeer naar 10.0.0.0/16(azurevnet)moet worden verzonden via tunnel ONPREMAZURE.
  • Beleid:Alle bidirectioneel verkeer tussen poort2 en ONPREMAZURE toestaan.

AZF1

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

  • Beleid:Alle bidirectioneel verkeer tussen poort1 en poort2 toestaan.

AZF2

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

  • Beleid:Alle bidirectioneel verkeer tussen poort1 en poort2 toestaan.

AZF3

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

  • Route:Al het verkeer naar 192.168.0.0/16(onpremvnet)moet worden verzonden naar het IP-adres van de Azure Gateway (dat wil zeggen 10.0.0.1) tot en met poort1.

Netwerkbeveiligingsgroepen (NSG's)

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

Inkomend

  • Sta alle TCP-verkeer vanaf internet toe om 80 over te maken op een VM in het subnet.
  • Alle overige verkeer van internet weigeren.

Uitgaande

  • Alle verkeer naar internet weigeren.

Stappen op hoog niveau

Als u dit scenario wilt implementeren, volgt u de onderstaande stappen op hoog niveau.

  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 inrichten van onpremvnet naar azurevnet.
  5. Wanneer alle resources zijn ingericht, meld u zich aan bij onpremvmm2 en pingt u 10.0.3.101 om de connectiviteit tussen onpremsn2 en azsn3te testen.