5.1 Configure virtual networks
Deploy a VM into a virtual network; configure external and internal load balancing; implement Application Gateway; design subnets; configure static, public, and private IP addresses; set up Network Security Groups (NSGs), DNS at the virtual network level, HTTP and TCP health probes, public IPs, User Defined Routes (UDRs), firewall rules, and direct server return
5.1.1 Deploy a VM into a virtual network
Når en VM opprettes i Azure, så må den plasseres i et virtuelt nettverk for å være i stand til å motta en IP-adresse og for å kunne kommunisere med andre ressurser i Azure.
Azure Fact: Per default kan du opprette 50 virtuelle nettverk (VNets) per abonnement innenfor én region. Grensen kan imidlertid økes til 500 ved å kontakte Azure Support.
Ved opprettelse av en VM i Azure-portalen, så må nettverkskonfigurasjon angis under steg 3 - Settings. Her velger du blant annet det virtuelle nettverket som VM-en skal knyttes til, og hvilket subnett herunder som VM-en skal stå i.
Det er her både mulig å velge et VNet som allerede er predefinert, eller å konfigurere opp et nytt VNet med ønsket range av IP-adresser og inndeling i subnett.
Merk: Det er nyttig å være obs på at det man strengt talt gjør her for å knytte en maskin til et VNet er å opprette et Network Interface Card (NIC) som inneholder en IP-adresse, og så kobler dette til VM-en. Dette er måten det gjøres på for alle versjon 2 VM-er fra Azure Resource Manager. Dette abstraheres i en viss grad bort i Azure-portalen, men er mer synlig når man utfører dette i PowerShell, som vist nedenfor.
Opprette en VM i et nytt virtuelt nettverk ved bruk av PowerShell
Fra PowerShell kan et VNet med 2 stk subnett opprettes på følgende vis:
# Definere subnett nr 1
$subnetConfig1 = New-AzureRmVirtualNetworkSubnetConfig -Name subnet1 -AddressPrefix 192.168.1.0/24
# Definere subnett nr 2
$subnetConfig2 = New-AzureRmVirtualNetworkSubnetConfig -Name subnet2 -AddressPrefix 192.168.2.0/24
# Opprette et virtuelt nettverk med to subnett
$vnet1 = New-AzureRmVirtualNetwork -ResourceGroupName $resourceGroup -Location $location `
-Name vNET1 -AddressPrefix 192.168.0.0/16 -Subnet $subnetConfig1,$subnetConfig2
Etter at det virtuelle nettverk har blitt definert og opprettet, så må man opprette et NIC som etterpå kobles til VM-en som man oppretter. Til NIC-et kan det også knyttes en NSG og en offentlig IP-adresse. Hvordan disse defineres med PowerShell er vist henholdsvis i Kap 5.1.6 og 5.1.9.
# Opprette NIC som kobles mot et subnett, en network security group og en offentlig IP
$nic = New-AzureRmNetworkInterface -Name nic1 -ResourceGroupName $resourceGroup -Location $location `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $ipPublic.Id -NetworkSecurityGroupId $nsg.Id
# Opprette VM-konfigurasjon som bl.a. inkluderer navn på NIC
$vmConfig = New-AzureRmVMConfig -VMName $vmName -VMSize Standard_DS2 | `
Set-AzureRmVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzureRmVMSourceImage -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -Version latest | `
Add-AzureRmVMNetworkInterface -Id $nic.Id
## Opprette VM
New-AzureRmVM -ResourceGroupName $resourceGroup -Location $location -VM $vmConfig
Det er også mulig å bruke Azure CLI eller en ARM Template for å opprette og administrere nettverksressurser.
Sette opp VM med flere NIC
For å knytte en VM mot flere forskjellige subnett, så må VM-en kobles til forskjellige NIC. Dette er gjerne en forutsetning dersom man ønsker å oppnå inndeling i ulike sikkerhetssoner som er vanlige fra en typisk on-premise IT-infrastruktur, slik som en DMZ, et eksternt og et internt nettverk.
Antall NIC som en VM kan knyttes til beror på størrelsen man velger for sin maskin.
NIC-et som blir regnet som default eller primært på maskinen, er det som er knyttet til maskinens offentlige IP-adresse.
Det er også viktig å vite at det ikke er mulig å tilegne en maskin flere NIC direkte gjennom Azure-portalen. Dette må gjøres enten via PowerShell, CLI eller ARM templates.
5.1.2 Configure external and internal load balancing
I tilfeller hvor man ønsker å publisere en applikasjon med økt redundans og skalerbarhet, kan Azure lastbalanserer brukes for automatisk å fordele trafikk mellom to eller flere VM-er.
En intern lastbalanserer gjør det mulig å å lastbalansere internt mellom VM-er i et regionalt VNet, hvor IP-adressen til lastbalansereren er privat. Ett enkelt endepunkt vil da i dette tilfelle bli delt mellom VM-ene.
En ekstern lastbalanserer som er vendt mot internett gjør det mulig å fordele innkommende internet-trafikk til ulike VM-er.
For å oppnå lastbalansering i Azure, kan også Microsoft Azure Traffic Manager benyttes. Traffic Manager gjør det mulig å lastbalansere mellom ulike endepunker, som Azure VM-er eller WebApps, som er lokalisert i forskjellige Azure-regioner eller i on-premise datasentre. Her har man også mulighet til å styre hvordan trafikk prioriteres og sørge for at brukere kobles til de endepunktene som befinner seg nærmest brukenes egen fysiske lokasjon.
5.1.3 Implement Application Gateway
Application Gateway tilbyr lastbalansering for nettverkstrafikk til en applikasjon i Azure som baserer seg på HTTP protokollen. Her brukes regler for routing på applikasjonsnivå som kan avlaste SSL-prosessering fra de lastbalanserte VM-ene.
5.1.4 Design subnets
VNet deles som nevnt opp i underliggende subnett for å kunne adskille ressurser i Azure både logisk og sikkerhetsmessig. Hvert subnett defineres med et IP-scope som er ledig i et VNet.
5.1.5 Configure static, public, and private IP addresses
En privat IP-adresse er allokert til en VM enten dynamisk eller statisk fra scopet som tilhører subnettet VM-en står i. Default så får nye VM-er tildelt en adresse dynamisk. Den private IP-adresssen brukes av VM-er for å kommunisere internt eller med andre ressurser som er koblet på nettverket gjennom en gateway-/ExpressRoute-løsning.
En offentlig IP-adresse brukes for å kommunisere med eksterne klienter, og blir tildelt direkte på vNIC-et til en VM eller en lastbalanserer.
5.1.6 Set up Network Security Groups (NSGs)
I utgangspunktet vil en VM i Azure med en offentlig IP være direkte eksponert fra internett, og kun beskyttet av maskinens egen interne brannmur (f.eks. Windows Firewall).
Network Security Groups gjør det mulig for oss i Azure å definere hva slags type trafikk, basert på porter og protokoller, som har lov til å gå mellom forskjellige subnett eller enkelt-NIC i et VNet, eksempelvis inn og ut av en VM. Disse fungerer som en ekstra og mer avansert sikkerhetsbeskyttelse utover det VM-en selv tilbyr.
Alle reglene som en NSG består av blir alltid evaluert etter prioritet. Så snart en regel matcher den gjeldende trafikken, vil den slå i kraft og avgjøre hvorvidt trafikken skal tillates eller ikke. Dersom det er knyttet en NSG både til subnettet en VM står i og til enkelt-NIC-et den er knyttet til, så vil trafikken måtte tillates i begge NSG-er for at den skal bli tillatt helt inn til VM-en det gjelder.
Det finnes også predefinerte regler i Azure for all trafikk som ikke kan slettes, men bare overskrives. Disse reglene åpner for all trafikk inn og ut av et VNet, all utgående trafikk mot internett og all innkommende trafikk mot en Azure lastbalanserer.
Alle VM-er bør tilegnes en NSG for å sikre tilgangen til maskinen som i utgangspunktet er direkte eksponert for trafikk fra internett. For å kunne koble seg på en VM fra internett med RDP på port 3389 så må det opprettes en innkommende regel som åpner for denne porten. Dersom en VM er tiltenkt å fungere som webserver, må det også opprettes en regel for innkommende trafikk på port 80. Eksempel på hvordan du oppretter en slik NSG ser du nedenfor:
Konfigurere NSG med PowerShell
# Opprette en NSG-regel for innkommende RDP-trafikk på port 3389
$nsgRuleRDP = New-AzureRmNetworkSecurityRuleConfig -Name NSGregelRDP -Protocol Tcp `
-Direction Inbound -Priority 1000 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange 3389 -Access Allow
# Opprette en NSG-regel for innkommende nettverkstrafikk på port 80
$nsgRuleWeb = New-AzureRmNetworkSecurityRuleConfig -Name NSGregelWWW -Protocol Tcp `
-Direction Inbound -Priority 1001 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange 80 -Access Allow
# Opprette network security group
New-AzureRmNetworkSecurityGroup -ResourceGroupName $resourceGroup -Location $location `
-Name NetworkSecurityGroup1 -SecurityRules $nsgRuleRDP,$nsgRuleWeb
Etter at kommandoene er kjørt, finnes NSG-en igjen i portalen:
NSG fact 1: Det kan kun tilegnes én NSG per VM, subnett eller NIC. NSG fact 2: Per default kan du ha 200 regler i en enkel NSG. Dette kan oppjusteres til 500 ved å kontakte Azure support. NSG fact 3: Du kan knytte en NSG til flere ressurser, også fra forskjellige ressursgrupper.
5.1.7 DNS at the virtual network level
Det finnes et eget DNS-system i Azure for å kunne gjøre oppslag på FQDN og få tilhørende IP-adresse tilbake. Riktignok er man i visse tilfeller, f.eks. i et hybrid oppsett, avhengig av en ekstern DNS-tjeneste for å gjøre de aktuelle oppslagene.
5.1.8 HTTP and TCP health probes
5.1.9 Public IPs
5.1.10 User Defined Routes (UDRs)
User Defined Routes (UDR) brukes for å kontrollere nettverkstrafikk gjennom å definere nettverksrouting. UDR-er kan angis per subnett.