Load Balance

DEPLOY Fortigate HA AZURE CLI (BASH) TEMPLATE ARM

Neste post iremos fazer o deploy de Fortigate (Version 7) em HA (Active/Passive) “Load Balance (ELB/ILB)”, utilizando um template modificado fornecido pela prória fortigate (adequado as preferencias para este artigo de exemplo).
Nesta topologia/arquitetura de rede colocamos o Fortigate EDGE para ser a rota default de todas as nossas vnets que estão no azure, com isso toda entrada ou saida de dados passa obrigatóriamente pelo Fortigate EDGE, essa arquitetura não esta certa nem errada, tudo vai depender do compliance de cada empresa, time de segurança, time de rede e claro do orçamento de cada um. Lembra muito o artigo que escrevi sobre Palo Alto

No final vou deixar os arquivos para download e algumas explicações sobre os arquivos .json

Uma breve explicação.

Vamos aos objetos criados no azure

Resource Group
rg-fw-edge-shared-brazilsouth

NAMETYPELOCATION
fwedge01_OsDisk_1_8e3e21f33b774e919ba304a2ec8a3b62DiskBrazil South
fwedge01_disk2_5e1d09faa5fa446eb56329f30ce3ff51DiskBrazil South
fwedge02_OsDisk_1_cbedf98d06474b009df9c9c13b972f55DiskBrazil South
fwedge02_disk2_c8449694114e4b849123c6f93103624fDiskBrazil South
elb-fwedge-01Load balancerBrazil South
ilb-fwedge-01Load balancerBrazil South
int-fwedge01-eth0Network interfaceBrazil South
int-fwedge01-eth1Network interfaceBrazil South
int-fwedge01-eth2Network interfaceBrazil South
int-fwedge01-eth3Network interfaceBrazil South
int-fwedge02-eth0Network interfaceBrazil South
int-fwedge02-eth1Network interfaceBrazil South
int-fwedge02-eth2Network interfaceBrazil South
int-fwedge02-eth3Network interfaceBrazil South
nsg-fwedge-sharedbrazilsouthNetwork security groupBrazil South
pip-fwedge-mgmt-aPublic IP addressBrazil South
pip-fwedge-mgmt-bPublic IP addressBrazil South
pip-lb-external-fwedge-01Public IP addressBrazil South
rt-fw-edge-shared-brazilsouthRoute tableBrazil South
fwedge01Virtual machineBrazil South
fwedge02Virtual machineBrazil South
vnet-fwedge-shared-brazilsouthVirtual networkBrazil South

Discos

Temos dois discos em cada Fortigate VM:
DiskOS 2GB SSD Premium
DiskDATA 30GB SSD Premium

Teremos uma VNET “vnet-fwedge-shared-brazilsouth” com as seguintes subnets (snets)

NameCIDR
snet-fwedge-shared-brazilsouth-External10.126.0.0/27
snet-fwedge-shared-brazilsouth-Internal10.126.0.32/27
snet-fwedge-shared-brazilsouth-HASync10.126.0.64/27
snet-fwedge-shared-brazilsouth-Management10.126.0.96/27
snet-fwedge-shared-brazilsouth-Protected10.126.0.128/27
snet-fwedge-shared-brazilsouth-LoadBalance10.126.0.160/27

Temos 4 interfaces de rede para cada VM

Interface NameVM AttachSnet NameIP IntCIDR
int-fwedge01-eth0fwedge01snet-fwedge-shared-brazilsouth-External10.126.0.510.126.0.0/27
int-fwedge01-eth1fwedge01snet-fwedge-shared-brazilsouth-Internal10.126.0.3710.126.0.32/27
int-fwedge01-eth2fwedge01snet-fwedge-shared-brazilsouth-HASync10.126.0.6910.126.0.64/27
int-fwedge01-eth3fwedge01snet-fwedge-shared-brazilsouth-Management10.126.0.10110.126.0.96/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-External10.126.0.610.126.0.0/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-Internal10.126.0.3810.126.0.32/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-HASync10.126.0.7010.126.0.64/27
int-fwedge02-eth0fwedge02snet-fwedge-shared-brazilsouth-Management10.126.0.10210.126.0.96/27

Temos dois Load Balances

1x Internal Load Balance (ilb-fwedge-01) IP: 10.126.0.190
1x External Load Balance (elb-fwedge-01) IP: XXX.XXX.XXX.XXX

Temos 1 NSG (Network Security Group) (snet-fwedge-shared-brazilsouth-03 “Management”)

1x “nsg-fwedge-shared-brazilsouth-mgmt” com as seguintes regras

Allow-MGMT-HTTPS/SSH
Source: XXX.XXX.XXX.XXX/XX (IP ou IPs de origem que podem se conectar na interface MGMT)
Destination: 10.126.0.96/24 (Rede de gerencia MGMT)

Temos 3 IPs Publicos

pip-fwedge-mgmt-a (Management Fortigate A)
pip-fwedge-mgmt-b (Management Fortigate B)
pip-lb-external-fwedge-01 (IP Publico External Load Balance)

Temos 2 Virtual Machines

fwedge01 (Standard_F8s – 8vCPUs, 16 GB Memory)
fwedge02 (Standard_F8s – 8vCPUs, 16 GB Memory)

Temos um arquivo de Route Table “rt-fw-edge-shared-brazilsouth”, nele temos as seguintes rotas:

NameCIDRNext Hop typeNext Hop IP address
DefaultRoute0.0.0.0/0VirtualAppliance10.126.0.190

Agora vamos ao nosso script

#!/bin/bash
##Declarando variaveis

##Declarando Variaveis (Obrigatório)
export Subscription_Name="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ##inserir sua Subscription Azure
export RG_Name02="rg-fw-edge-shared-brazilsouth"
export Location_Region="brazilsouth"

###Script
###Selecionar subscription
az account set --subscription "${Subscription_Name}"

##Criando RG
az group create -n "${RG_Name02}" -l "${Location_Region}"

##Deploy Fortigate Template
az deployment group create -g "${RG_Name02}" --template-file template.json --parameters @parametersFile.json

##Desligando VMs
az vm stop -g "${RG_Name02}" -n "fwedge01"
az vm stop -g "${RG_Name02}" -n "fwedge02"

##Deallocate
az vm deallocate -g "${RG_Name02}" -n "fwedge01"
az vm deallocate -g "${RG_Name02}" -n "fwedge02"

###Criando Storage Accout (Para boot diag)
az storage account create -g "${RG_Name02}" -n "stgdiagfwedgefgt01" -l "${Location_Region}" --sku "Standard_LRS"

##Criando Snet Internal Load Balance (Subnet para load balance interno)
az network vnet subnet create -g "${RG_Name02}" --vnet-name "vnet-fwedge-shared-brazilsouth" -n "snet-fwedge-shared-brazilsouth-LoadBalance" --address-prefixes "10.126.0.160/27"

##alterando IP Internal Load Balance
az network lb frontend-ip update -g "${RG_Name02}" --lb-name "ilb-fwedge-01" -n "frontend-fwedge-internal-01" --vnet-name "vnet-fwedge-shared-brazilsouth" --subnet "snet-fwedge-shared-brazilsouth-LoadBalance" --private-ip-address "10.126.0.190"

###Habilitando Boot dioag VM01/02
az vm boot-diagnostics enable -n "fwedge01" -g "${RG_Name02}" --storage "stgdiagfwedgefgt01" 
az vm boot-diagnostics enable -n "fwedge02" -g "${RG_Name02}" --storage "stgdiagfwedgefgt01" 

##Fixando IP eht0 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth0" -n "ipconfig1" --private-ip-address "10.126.0.5"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth0" -n "ipconfig1" --private-ip-address "10.126.0.6"

###Fixando IP eth1 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth1" -n "ipconfig1" --private-ip-address "10.126.0.37"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth1" -n "ipconfig1" --private-ip-address "10.126.0.38"

###Fixando IP eth2 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth2" -n "ipconfig1" --private-ip-address "10.126.0.69"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth2" -n "ipconfig1" --private-ip-address "10.126.0.70"

###Fixando IP eth3 (VM01/02)
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge01-eth3" -n "ipconfig1" --private-ip-address "10.126.0.101"
az network nic ip-config update -g "${RG_Name02}" --nic-name "int-fwedge02-eth3" -n "ipconfig1" --private-ip-address "10.126.0.102"

###Anexando NSG MGMT a snet mgmt 
az network vnet subnet update -g "${RG_Name02}" -n "snet-fwedge-shared-brazilsouth-Management" --vnet-name "vnet-fwedge-shared-brazilsouth" --network-security-group "nsg-fwedge-shared-brazilsouth-mgmt"

###Deletando regras existentes (criadas pelo templete, pode-se alterar diretamente no template tb)
az network nsg rule delete -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "AllowAllInbound"
az network nsg rule delete -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "AllowAllOutbound"

##Criando regras NSG MGMT HTTPS
az network nsg rule create -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "Allow-MGMT-HTTPS" --priority "100" \
--source-address-prefixes "179.215.182.42/32" --source-port-ranges "*" \
--destination-address-prefixes "10.126.0.96/27" --destination-port-ranges "443" --access "Allow" \
--protocol "TCP" --description "Acesso liberado a snet management"

##Alterando regras NSG MGMT SSH
az network nsg rule create -g "${RG_Name02}" --nsg-name "nsg-fwedge-shared-brazilsouth-mgmt" -n "Allow-MGMT-SSH" --priority "101" \
--source-address-prefixes "179.215.182.42/32" --source-port-ranges "*" \
--destination-address-prefixes "10.126.0.96/27" --destination-port-ranges "22" --access "Allow" \
--protocol "TCP" --description "Acesso liberado a snet management"

###Anexando Subnet Internal a Route Table
az network vnet subnet update -g "${RG_Name02}" -n "snet-fwedge-shared-brazilsouth-Internal" --vnet-name "vnet-fwedge-shared-brazilsouth" --route-table "rt-fw-edge-shared-brazilsouth-internal" 

###Inciando as VM01/02
az vm start -g "${RG_Name02}" -n "fwedge01"
az vm start -g "${RG_Name02}" -n "fwedge02"

Agora tudo pronto, vamos acessar nosso FGT, iremos acesso pelo IP Publico “pip-fwedge-mgmt-a”

Entre com usuário e senha que contas no template

Vamos as configurações iniciais

Clique em “Begin”
Clique em “ok”
Clique e “ok”

Temos nosso Dashbord inicial

Vamos verificar nosso HA Sync

Vamos em System / HA

Tudo certo

Vamos agora em “Network” “Static Routes”

Por padrão teremos essas rotas (Isso pode ser editado/alterado no template)

Vamos fazer algumas modificações e deixar desta forma

Basicamente, iremos remover a rota “168.63.129.16/32” “10.126.0.1” “port1”

Ficará desta forma

Toda e qualquer nova rede que for criar e for feito peering com a rede do Firewall-EDGE 10.126.0.0/24 teremos que criar a “Static Route”

Vamos a um exemplo, em nosso ambiente azure temos a Vnet “10.188.0.0/24”, iremos fazer um peering com ela e add route static no FGT.

Sempre usaremos a port2, pois ela é nossa “LAN-Trust”, o gw 10.126.0.33 é o gw do azure (já expliquei em outros posts como funciona a rede no azure, que ele guarda para si os 3 primeiros IP de cada subnet)
Agora nossa Static Route ficará desta forma

Vamos agora criar um regra de acesso a internet
“Policy & Objects” “Firewall Policy”

Create New

Clique em “ok”

Agora nos temos uma regra que vem da nossa interface “LAN-Trust” para a nossa interface “WAN-UnTrust”

Agora vamos add essa vnet/subnet ao nosso Route Table

Assim ficou nosso arquivo

**(Esta vnet tem que possui peering com nossa rede do firewall edge)

Vamos ao teste

Criamos a seguinte vm “vm-lan-trust-01”
subnet 10.188.0.0/26
IP: 10.188.0.4

Estamos dentro da nossa VM Trust

vamos fazer um teste de curl para http//ifconfig.me e monitor em nosso firewall

Como podem ver em nossa VM Trust, trouxe o IP da interface WAN-UnTrust e todo trafego passou pelo nossa firewall

Agora um outro cenário, temos parceiros/clientes que precisam acessar nossas aplicações ou um ambiente de “Transfer” (Connect Direct IBM, SFTP, FTPS, SMB) para isso acontecer de forma segura podemos estabelecer Tuneis IPSec com nossas Parceiros/Clientes e desta forma liberar o acesso de forma segura.
Outra cenario seria a publicação de uma aplicação interna e expo-la para internet, temos varias possibilidade de forma segura em nossa ambiente.

Agora algumas explicações referente aos .json

Linha 5/6: usuário de acesso ao firewall
Linha 8/9: senha
Linha 12: prefixo do firewall
Linha 15: versão do licenciamento, neste exemplo seria PayAsGo (Pague pelo uso, se vc possui BYOL, altere para o valor que consta no template)
Linha 18: ultima versão do firmware
Linha 21: Size VM
Linha 36: nome do IP Publico do External LB
Linha 39: RG
Linha 42: IP Publico MGMT FGT A
Linha 45: RG
Linha 48: IP Publico MGMT FGT B
Linha 51: RG

Continuando

Linha 57: nome da vnet (o proprio template cria a vnet)
Linha 60: RG
Linha 63: CIDR da Vnet
Linha 66: Nome da Vnet External
Linha 69: CIDR da Subnet External

As outras são auto explicativas

***Nunca esquecer de add Static Route em nosso firewall, sempre add as subnet no arquivo Route Table, sempre fazer peering para novas Vnets.

Link para download

Seja Feliz!!!!!!!!!!!!!!!!!

Criando Web Site com alta disponibilidade Azure CLI (Bash)

Neste artigo iremos criar Web Site em alta disponibilidade, composto por duas VM Windows Server 2019 com IIS habilitado e um load balance, não iremos abordar aqui segurança como Application Gateway, WAF, API MAN, etc. Este artigo visa somente a criação via scritp de toda a infraestrutura (também não iremos abordar o deploy de qualquer aplicação neste artigo).

#!/bin/bash

##Declarando Variaveis (Obrigatório)

export Subscription_Name=”Santana-Corp”
export RG_Name=”WEBSERVER-PRD-EAST”
export Location=”eastus”
export Object_Name=”WEBSERVER”

##Storage Accout

export Storage=”stgdiag${Object_Name,,}”
export SKU_Storage=”Standard_LRS” ##Exemplo Standard_LRS##

##Grupo de Disponibiliade Availability Set

export Name_AV_SET=”AV-SET”-“${Object_Name}”

##Network Security Group NSG

export NSG_Name=”NSG”-“${Object_Name}”
export Fault_Domain=”3″
export Update_Domain=”20″
export Rule01=”HTTP”
export Rule02=”HTTPS”

##Vnet Existente (Variaveis para utilizar Vnet Existente)

export RG_Vnet=”Resource Group da Vnet existente”
export Subnet_Name=”Subnet da Vnet existente”
export Vnet_Name=”Vnet existente”

##Variaveis de Rede (Obrigatório)

export NIC_Name1=”NIC”-“${Object_Name}”1
export NIC_Name2=”NIC”-“${Object_Name}”2
export Accelerated=”False”
export PublicIP=”PUBLIC-IP”-“${Object_Name}”
export PublicIP_Method=”Static”
export ELB_Name=”ELB”-“${Object_Name}”
export SKU=”Basic”
export Frontend_Name=”FE”-“${Object_Name}”
export BackendPool_Name=”BEP”-“${Object_Name}”
export ProbeName01=”Probe-http”
export ProbeName02=”Probe-https”
export Protocol01=”tcp”
export Port01=”80″
export Port02=”443″

##Variavel para criacao da VM (Obrigatório)

export Image_SO=”Win2019Datacenter”
export VM_Name1=”VM”-“${Object_Name}”1
export VM_Name2=”VM”-“${Object_Name}”2
export User_Name=”azroot”
export PWD=”#!49_WelCome_Az@#”
export Size=”Standard_D2S_v3″
export SKU_STG=”Standard_LRS” ## Disco ##
export DiskName_01=”DISK”-“${Object_Name}”01
export DiskName_02=”DISK”-“${Object_Name}”02
export SizeDisk_01=”256″
export SizeDisk_02=”512″
export Disk_Data01=”DISK-DATA”-“${Object_Name}”1
export Disk_Data02=”DISK-DATA”-“${Object_Name}”2

##Variaveis TAGs (Não Obrigatório)

export Costacenter=”Centro de Custos”
export Value_Costcenter=”111245″
export Environment=”Environment”
export Environment_Value=”Produção”
export Depto=”Departamento”
export Depto_Value=”Recursos Humanos”

###Execução do Script

###Selecionar subscription

az account set –subscription “${Subscription_Name}”

###Criando Resource Group

az group create -n “${RG_Name}” -l “${Location}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Criando Storage Accout

az storage account create -g “${RG_Name}” -n “${Storage}” -l “${Location}” –sku “${SKU_Storage}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Criano IP Publico

az network public-ip create -g “${RG_Name}” -n “${PublicIP}” -l “${Location}” –allocation-method “${PublicIP_Method}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Criando Network Security Group NSG

az network nsg create -g “${RG_Name}” -n “${NSG_Name}” -l “${Location}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Criar regras NSG

az network nsg rule create -g “${RG_Name}” –nsg-name “${NSG_Name}” -n “${Rule01}” –protocol tcp –priority 100 –source-address-prefixes 0.0.0.0/0 –destination-port-range 80 –access allow
az network nsg rule create -g “${RG_Name}” –nsg-name “${NSG_Name}” -n “${Rule02}” –protocol tcp –priority 101 –source-address-prefixes 0.0.0.0/0 –destination-port-range 443 –access allow

###Criar Grupo de Disponibilidade

az vm availability-set create -g “${RG_Name}” -n “${Name_AV_SET}” –platform-fault-domain-count “${Fault_Domain}” –platform-update-domain-count “${Update_Domain}” -l “${Location}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Declarando varivel para utilizar Vnet existente (Obrigatório)

SUBNET_ID001=$(az network vnet subnet show –name “${Subnet_Name}” –vnet-name “${Vnet_Name}” -g “${RG_Vnet}” –query id –output tsv)
SUBNET_ID002=$(az network vnet subnet show –name “${Subnet_Name}” –vnet-name “${Vnet_Name}” -g “${RG_Vnet}” –query id –output tsv)
export IPConfig_Name=”ipconfig1″

###Criando NIC (Interface de rede)

az network nic create –name “${NIC_Name1}” -g “${RG_Name}” –subnet $SUBNET_ID001 –accelerated-networking “${Accelerated}” –network-security-group “${NSG_Name}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”
az network nic create –name “${NIC_Name2}” -g “${RG_Name}” –subnet $SUBNET_ID002 –accelerated-networking “${Accelerated}” –network-security-group “${NSG_Name}” –tags “${Costacenter}”=”${Value_Costcenter}” “${Environment}”=”${Environment_Value}” “${Depto}”=”${Depto_Value}”

###Declaranado Variaveis para Fixar IP

NIC_ID001=$(az network nic show –name “${NIC_Name1}” -g “${RG_Name}” –query id –output tsv)
NIC_ID002=$(az network nic show –name “${NIC_Name2}” -g “${RG_Name}” –query id –output tsv)

###Declarando varivel para utilizar IP Fixo existente (Obrigatório)

IP_ID001=$(az network nic ip-config show -g “${RG_Name}” -n “${IPConfig_Name}” –nic-name “${NIC_Name1}” –query privateIpAddress –output tsv)
IP_ID002=$(az network nic ip-config show -g “${RG_Name}” -n “${IPConfig_Name}” –nic-name “${NIC_Name2}” –query privateIpAddress –output tsv)

###Fixando IP na interface de rede#Fixando IP

az network nic ip-config update -g “${RG_Name}” –nic-name “${NIC_Name1}” -n “${IPConfig_Name}” –private-ip-address $IP_ID001
az network nic ip-config update -g “${RG_Name}” –nic-name “${NIC_Name2}” -n “${IPConfig_Name}” –private-ip-address $IP_ID002

###Criando Virtual Machine Windows Server 2019

az vm create –name “${VM_Name1}” -g “${RG_Name}” -l “${Location}” –availability-set “${Name_AV_SET}” –boot-diagnostics-storage “${Storage}” –os-disk-name “${DiskName_01}” –os-disk-size-gb “${SizeDisk_01}” –image “${Image_SO}” –nics $NIC_ID001 –admin-username “${User_Name}” –admin-password “${PWD}” –size “${Size}” –storage-sku “${SKU_STG}”
az vm create –name “${VM_Name2}” -g “${RG_Name}” -l “${Location}” –availability-set “${Name_AV_SET}” –boot-diagnostics-storage “${Storage}” –os-disk-name “${DiskName_02}” –os-disk-size-gb “${SizeDisk_01}” –image “${Image_SO}” –nics $NIC_ID002 –admin-username “${User_Name}” –admin-password “${PWD}” –size “${Size}” –storage-sku “${SKU_STG}”

###Criando disco de dados

az disk create -g “${RG_Name}” -n “${Disk_Data01}” –size-gb “${SizeDisk_02}”
az disk create -g “${RG_Name}” -n “${Disk_Data02}” –size-gb “${SizeDisk_02}”

###Anexando Disco a VM existente

az vm disk attach -g “${RG_Name}” –vm-name “${VM_Name1}” –name “${Disk_Data01}”
az vm disk attach -g “${RG_Name}” –vm-name “${VM_Name2}” –name “${Disk_Data02}”

###Habilitando IIS Windows Server

az vm extension set –publisher Microsoft.Compute –version 1.8 –name CustomScriptExtension –vm-name “${VM_Name1}” -g “${RG_Name}” –settings ‘{“commandToExecute”:”powershell.exe Install-WindowsFeature -Name Web-Server”}’
az vm extension set –publisher Microsoft.Compute –version 1.8 –name CustomScriptExtension –vm-name “${VM_Name2}” -g “${RG_Name}” –settings ‘{“commandToExecute”:”powershell.exe Install-WindowsFeature -Name Web-Server”}’

###Criando Load Balance

az network lb create -g “${RG_Name}” -n “${ELB_Name}” –sku “${SKU}” –public-ip-address “${PublicIP}” –frontend-ip-name “${Frontend_Name}” –backend-pool-name “${BackendPool_Name}”

###Create health probe on port 80/443

az network lb probe create -g “${RG_Name}” –lb-name “${ELB_Name}” -n “${ProbeName01}” –protocol “${Protocol01}” –port “${Port01}”
az network lb probe create -g “${RG_Name}” –lb-name “${ELB_Name}” -n “${ProbeName02}” –protocol “${Protocol01}” –port “${Port02}”

###Create load balancer rule for port 80/443

az network lb rule create -g “${RG_Name}” –lb-name “${ELB_Name}” -n “${Rule01}” –protocol “${Protocol01}” –frontend-port “${Port01}” –backend-port “${Port01}” –frontend-ip-name “${Frontend_Name}” –backend-pool-name “${BackendPool_Name}” –probe-name “${ProbeName01}”
az network lb rule create -g “${RG_Name}” –lb-name “${ELB_Name}” -n “${Rule02}” –protocol “${Protocol01}” –frontend-port “${Port02}” –backend-port “${Port02}” –frontend-ip-name “${Frontend_Name}” –backend-pool-name “${BackendPool_Name}” –probe-name “${ProbeName02}”

###Adicionando Inteface REDE ao pool de backend Load Balance

az network nic ip-config address-pool add -g “${RG_Name}” –nic-name “${NIC_Name1}” -n “${IPConfig_Name}” –lb-name “${ELB_Name}” –address-pool “${BackendPool_Name}”
az network nic ip-config address-pool add -g “${RG_Name}” –nic-name “${NIC_Name2}” -n “${IPConfig_Name}” –lb-name “${ELB_Name}” –address-pool “${BackendPool_Name}”

###fim do scrip.

Infraestrutura de rede (Vnet) com Azure Firewall na Borda.

Neste artigo venho apresentar uma topologia utilizando Cloud Azure, com 7 Vnets ligadas por peering, gateway de VPN com BGP e Azure Firewall.

Nesta topologia todas as subnets estão com route table 0.0.0.0/0 para o IP da interface do nosso Azure Firewall

0.0.0.0/0 –> 10.128.0.68

Desta maneira temos total segregação da rede (Azure Vnet), onde cada projeto/departamento tem sua propria vnet.
Desta forma a vnet por exemplo do RH não fala com a Vnet de Marketing (Somente se for criada regras de Firewall) e o porque de utilizar desta forma.

Na minha visão tem que ser “cada um no seu quadrado”, não porque estamos em cloud que esse pensamento deve mudar, desta maneira tornamos nosso ambiente mais seguro, protegemos nossas cargas de trabalhos, deixamos cada ambiente totalmente isolado, segredado e seguro.

Na borda nos temos Azure Firewall com default route, onde ele controla tudo que entra e sai da nossa rede.

Topologia Azure Firewall

Exemplos de regras na pratica

Temos nesta topologia dois servidores de DNS (Windows Server 2019):

AZUEASTDNS01 e AZUEASTDNS02 (dentro do dominio glbx.corp)

AZUEASTDNS01.glbx.corp (10.128.8.4)
AZUEASTDNS02.glbx.corp (10.128.9.4)

Esses servidores são os DNS Server padrão de todas as nossas vnets

Veja como ficaria a regra de Azure Firewall para que toda “Resolução de Nomes” seja liberada: (Neste exemplo não estamos utilizando Firewall Manager)

Foi criada a seguinte regra

Name: dns vnet resoler
Protocol: TCP/UDP
Source: 10.128.0.0/16 (Estou utilizando este CIDR neste exemplo)
Destination Address: 10.128.8.4,10.128.9.4 (Nossos servidores DNS)
Destination Port: 53

Firewall Rule DNS Vnet

Conforme regra criada acima, todas as vnet que estão fazendo peering, e com route default 0.0.0.0/0 para o IP no nosso Azure Firewall, iram conseguir resolver nomes utilizando nossos servidores DNSs.

Vamos a outro exemplo pratico.

Em nosso ambiente temos dois servidores web (Windows Server 2019 com IIS) que hospeda a intranet da empresa, na frente deste servidores temos um load balance fazendo o balanceamento da carga, que possui o IP 10.128.11.196

Para os colaboradores acessarem a infraestrutura da empresa, existe uma VPN IPSec com BGP comunicando o ambiente OnPremises e o ambiente do Azure

A regra para liberar o acesso dos colaboradores ao nosso ambiente “intranet” seria assim:

Name: acesso rede interna – intranet
Protocol: TCP
Source: 10.127.0.0/22 (Este CIDR é da rede OnPremises)
Destination Address: 10.128.11.196 (IP do Load Balance)
Destinaton Port: 80/443

Nossos colaboradores seguiram este caminho

Notebook –> Firewall OnPremises –> Rota BGP –> Gateway Azure –> Route Default Azure –> Azure Firewall –> IP do Load Balance

Nossa intranet utiliza banco de dados Azure Database SQL (PaaS), para este modelo criamos um Azure Database SQL (PaaS) com private link e bloqueamos totalmente o acesso externo (Internet) ele só é acessivel via rede interna.

Link para utilização de private link com DNS Personal (Neste exemplo utilizamos desta forma)

https://docs.microsoft.com/pt-br/azure/private-link/private-endpoint-dns

Regra de Firewall

Name: acesso rede interna – intranet
Protocol: TCP
Source: 10.128.10.4,10.128.11.4
Destination Address: 10.128.4.10 (IP do Private Link que criamos)
Destinaton Port: 1433

Com esta regra nossa aplicação “intranet” conseguirá acessar o banco de dados PaaS via rede interna.

Outro exemplo pratico, neste cenário iremos expor uma aplicação para internet

Iremos expor nosso Site Institucional para a internet, temos este ambiente

Frontend: Application Gateway com IP Privado, peering com nossa vnet master, porém na subnet onde esta hospedado nossa application gateway não possui route default 0.0.0.0/0 para nosso AzureFirewall

Iremos utilizar o recurso de NAT para expor nosso site com destino um Appplication Gateway (não irei ensinar neste exemplo com criar/configurar um application gatewaY)

Name: acesso site institucional
Protocol: TCP
Source: * (qualquer lugar da internet)
Destination Address: 20.72.175.158 (IP previamente criado a atachado ao azure firewall)
Destinaton Port: 443
Translate Adress: 10.128.4.10 (IP privado do Application Gateway)
Translate Port: 443

Com a regra de firewall criada acima nosso site institucional ficará exposto para a internet com proteção de anti-DDoS do Azure que esta em nossa borda e por Application Gateway (WAF) na frente da aplicação.

Essa topologia não esta certa nem errada, eu acredito que é possivel deixar seu ambiente totalmente segredado, seguro, com um ponto unico de acesso e ainda conseguir utilizar todos os recurso do Azure de forma segura.

Bom é isso pessoal, fiquem a vontade para criticar/sugestionar

Outra coisa importante que se deve levar em conta, se no seu ambiente se faz necessário estabelecer comunicação com outras empresas, parceiros cliente etc….pense em utilizar a o proprio gateway de VPN BGP, porém pense que seu cliente da VPN IPSec não poderá utilizar a mesma rede que seu ambiente, neste exemplo o CIDR 10.128.0.0/16 e nem 10.127.0.0/22, para resolver essa questão você pode estabelecer a VPN IPSec em seu ambiente OnPremises e fazer o roteamento dos pacotes para seu ambiente no Azure (recomendo somente se não for critico, pois se seu ambiente OnPremises ficar indisponivel a VPN ficará também), outra solução seria criar um nova Vnet (Para deixar o ambiente segredado) e criar um Virtual Appliance como por exemplo “Fortigate” (Pode ser Palo Alto, SonicWall, PFSense), com a Vnet criada, faça o peering com a vnet master para propagação BGP, e NÃO deixe como rota default as subnets do fortigate para o AzureFirewall, depois disso bastas estabelecer o tunnel IPSec com seu parceiro e criar as devidas rotas na tabela de roteamento e as regras no Azure Firewall.