Azure Virtual Network Oluşturma ve Yapılandırma

Azure’da ilk Virtual Network’ünü kurmaya çalışırken saatlerce Portal’da dolaşıp kafanın karıştığı oldu mu? Ya da production ortamına yanlış subnet aralığı girip sonradan başa dönmek zorunda kaldın mı? Bu yazıda Azure Virtual Network kavramını sıfırdan ele alacağız. Hem Portal üzerinden hem de Azure CLI ve PowerShell ile gerçek dünya senaryoları üzerinden ilerleyeceğiz.

Azure Virtual Network Nedir ve Neden Önemli?

Azure Virtual Network (VNet), Azure kaynaklarının birbirleriyle, internet ile ve şirket içi ağlarla güvenli biçimde iletişim kurmasını sağlayan temel yapı taşıdır. Fiziksel bir veri merkezindeki switch ve router altyapısının bulut karşılığı olarak düşünebilirsin.

VNet olmadan Azure’daki VM’lerin, App Service’lerin veya veritabanlarının birbirleriyle konuşması ya son derece kısıtlı kalır ya da güvensiz public endpoint’ler üzerinden gerçekleşir. Yani VNet, Azure mimarisinin kalp atışıdır.

Birkaç temel kavramı netleştirelim:

  • Address Space: VNet’e atadığın CIDR bloğu. Örneğin 10.0.0.0/16 dersen 65.536 IP adresi kullanabilirsin.
  • Subnet: VNet içindeki alt ağlar. Kaynakları mantıksal olarak ayırmak için kullanılır.
  • NSG (Network Security Group): Subnet veya NIC seviyesinde trafiği filtreleyen güvenlik duvarı kuralları.
  • Route Table: Trafik yönlendirmesini özelleştirmek için kullanılan yönlendirme tabloları.
  • Peering: Farklı VNet’leri birbirine bağlama mekanizması.

Planlama Aşaması: IP Adres Aralığını Doğru Seçmek

Bu aşama çoğu sysadmin’in atladığı ama sonradan pişman olduğu kısımdır. Üretim ortamında bir VNet’in IP aralığını değiştirmek için tüm kaynakları silip yeniden oluşturman gerekir. O yüzden baştan doğru planla.

RFC 1918 private adres alanlarını kullan:

  • 10.0.0.0/8: Büyük kurumsal ortamlar için uygundur
  • 172.16.0.0/12: Orta ölçekli yapılar için tercih edilir
  • 192.168.0.0/16: Küçük test ve geliştirme ortamları için yeterlidir

Gerçek dünya senaryosu olarak şu yapıyı düşün: Bir e-ticaret şirketinin Azure altyapısını kuracaksın. Production, Staging ve Development ortamlarının birbirinden izole olması ama VPN üzerinden şirket ağına bağlanabilmesi gerekiyor.

Önerilen adres planı:

  • Production VNet: 10.10.0.0/16
  • Staging VNet: 10.20.0.0/16
  • Development VNet: 10.30.0.0/16
  • Şirket içi ağ: 192.168.0.0/16

Böylece hiçbir aralık çakışmıyor ve VPN ya da peering kurulumunda sorun yaşanmıyor.

Azure Portal ile VNet Oluşturma

Portal üzerinden ilerlemek özellikle kavramları anlamak için iyi bir başlangıç noktasıdır.

  1. Azure Portal’da “Virtual Networks” servisine git
  2. “+ Create” butonuna tıkla
  3. Temel ayarlar ekranında şunları doldur:

Subscription: Doğru aboneliği seç – Resource Group: Mevcut bir grup seç veya yeni oluştur. Ben genellikle rg-network-prod gibi anlamlı isimler kullanıyorum. – Name: vnet-prod-eastus gibi bir isimlendirme standardı belirle – Region: Kaynaklarının bulunduğu region ile aynı olsun

  1. IP Addresses sekmesinde address space ve subnet bilgilerini gir
  2. Security sekmesinde BastionHost, DDoS Protection ve Firewall ayarlarını yapılandır
  3. Tags ekleyerek maliyet takibini kolaylaştır

Azure CLI ile VNet Oluşturma

Otomasyon ve tekrarlanabilirlik açısından CLI her zaman önceliğimdir. Önce Azure CLI ile giriş yapalım ve resource group oluşturalım.

# Azure'a giriş yap
az login

# Doğru subscription'ı seç
az account set --subscription "Subscription-ID-veya-Adi"

# Resource Group oluştur
az group create 
  --name rg-network-prod 
  --location eastus 
  --tags Environment=Production Project=Ecommerce Owner=SysAdmin

Şimdi production VNet’i oluşturalım:

# VNet oluştur
az network vnet create 
  --resource-group rg-network-prod 
  --name vnet-prod-eastus 
  --address-prefix 10.10.0.0/16 
  --location eastus 
  --tags Environment=Production

# Web tier subnet ekle
az network vnet subnet create 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-web 
  --address-prefix 10.10.1.0/24

# Application tier subnet ekle
az network vnet subnet create 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-app 
  --address-prefix 10.10.2.0/24

# Database tier subnet ekle
az network vnet subnet create 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-db 
  --address-prefix 10.10.3.0/24

# Management subnet ekle (Bastion için)
az network vnet subnet create 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name AzureBastionSubnet 
  --address-prefix 10.10.4.0/27

Azure Bastion subnet’inin adı kesinlikle AzureBastionSubnet olmalı ve minimum /27 boyutunda olmalı. Bunu değiştirme denemesi seni hata mesajlarıyla boğar.

Network Security Group Yapılandırması

NSG olmadan VNet’in içi güvensizdir. Her subnet için ayrı NSG oluşturmak ve uygun kurallar tanımlamak gerekir.

# Web tier NSG oluştur
az network nsg create 
  --resource-group rg-network-prod 
  --name nsg-web-prod 
  --location eastus

# HTTP trafiğine izin ver
az network nsg rule create 
  --resource-group rg-network-prod 
  --nsg-name nsg-web-prod 
  --name Allow-HTTP 
  --protocol Tcp 
  --direction Inbound 
  --priority 100 
  --source-address-prefix Internet 
  --source-port-range "*" 
  --destination-address-prefix "*" 
  --destination-port-range 80 
  --access Allow

# HTTPS trafiğine izin ver
az network nsg rule create 
  --resource-group rg-network-prod 
  --nsg-name nsg-web-prod 
  --name Allow-HTTPS 
  --protocol Tcp 
  --direction Inbound 
  --priority 110 
  --source-address-prefix Internet 
  --source-port-range "*" 
  --destination-address-prefix "*" 
  --destination-port-range 443 
  --access Allow

# NSG'yi subnet'e bağla
az network vnet subnet update 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-web 
  --network-security-group nsg-web-prod

Database tier için çok daha kısıtlayıcı bir NSG kuralı yazalım. Sadece application subnet’inden gelen trafiğe izin verelim:

# DB tier NSG oluştur
az network nsg create 
  --resource-group rg-network-prod 
  --name nsg-db-prod 
  --location eastus

# Sadece app subnet'inden SQL trafiğine izin ver
az network nsg rule create 
  --resource-group rg-network-prod 
  --nsg-name nsg-db-prod 
  --name Allow-SQL-From-App 
  --protocol Tcp 
  --direction Inbound 
  --priority 100 
  --source-address-prefix 10.10.2.0/24 
  --source-port-range "*" 
  --destination-address-prefix "*" 
  --destination-port-range 1433 
  --access Allow

# İnternet'ten gelen tüm trafiği reddet
az network nsg rule create 
  --resource-group rg-network-prod 
  --nsg-name nsg-db-prod 
  --name Deny-Internet-Inbound 
  --protocol "*" 
  --direction Inbound 
  --priority 4000 
  --source-address-prefix Internet 
  --source-port-range "*" 
  --destination-address-prefix "*" 
  --destination-port-range "*" 
  --access Deny

# NSG'yi DB subnet'e bağla
az network vnet subnet update 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-db 
  --network-security-group nsg-db-prod

PowerShell ile VNet Yönetimi

Bazı ekipler PowerShell ile çalışmayı tercih eder. Staging ortamı için PowerShell kullanarak VNet oluşturalım:

# Azure'a bağlan
Connect-AzAccount

# Değişkenleri tanımla
$resourceGroup = "rg-network-staging"
$location = "eastus"
$vnetName = "vnet-staging-eastus"

# Resource group oluştur
New-AzResourceGroup -Name $resourceGroup -Location $location -Tag @{
    Environment = "Staging"
    Project = "Ecommerce"
    Owner = "SysAdmin"
}

# Subnet konfigürasyonlarını hazırla
$webSubnet = New-AzVirtualNetworkSubnetConfig `
    -Name "subnet-web" `
    -AddressPrefix "10.20.1.0/24"

$appSubnet = New-AzVirtualNetworkSubnetConfig `
    -Name "subnet-app" `
    -AddressPrefix "10.20.2.0/24"

$dbSubnet = New-AzVirtualNetworkSubnetConfig `
    -Name "subnet-db" `
    -AddressPrefix "10.20.3.0/24"

# VNet'i tüm subnet'lerle birlikte oluştur
$vnet = New-AzVirtualNetwork `
    -ResourceGroupName $resourceGroup `
    -Location $location `
    -Name $vnetName `
    -AddressPrefix "10.20.0.0/16" `
    -Subnet $webSubnet, $appSubnet, $dbSubnet

Write-Host "VNet başarıyla oluşturuldu: $($vnet.Name)" -ForegroundColor Green
Write-Host "Address Space: $($vnet.AddressSpace.AddressPrefixes)" -ForegroundColor Cyan

VNet Peering Kurulumu

Gerçek dünya senaryomuzda production ve staging ortamlarının belirli senaryolarda birbiriyle konuşması gerekiyor. VNet Peering bu işi çözer.

# Production'dan Staging'e peering kur
az network vnet peering create 
  --resource-group rg-network-prod 
  --name peer-prod-to-staging 
  --vnet-name vnet-prod-eastus 
  --remote-vnet /subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-network-staging/providers/Microsoft.Network/virtualNetworks/vnet-staging-eastus 
  --allow-vnet-access true 
  --allow-forwarded-traffic false 
  --allow-gateway-transit false

# Staging'den Production'a peering kur (her iki taraf da yapılandırılmalı)
az network vnet peering create 
  --resource-group rg-network-staging 
  --name peer-staging-to-prod 
  --vnet-name vnet-staging-eastus 
  --remote-vnet /subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-prod-eastus 
  --allow-vnet-access true 
  --allow-forwarded-traffic false 
  --allow-gateway-transit false

Peering’in iki yönlü olduğunu unutma. Sadece bir taraftan kurman yeterli değil, her iki VNet’te de peering objesi oluşturulmalı. Bu hatayı çok sık görüyorum.

Service Endpoint ve Private Endpoint Yapılandırması

Azure Storage veya SQL Database gibi servislere VNet üzerinden özel erişim sağlamak güvenlik açısından kritiktir. Service Endpoint ile subnet’ten Azure servisine trafik Azure backbone üzerinden gider.

# Storage için Service Endpoint ekle
az network vnet subnet update 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-app 
  --service-endpoints Microsoft.Storage Microsoft.Sql

# Storage account'u bu VNet ile kısıtla
az storage account network-rule add 
  --resource-group rg-network-prod 
  --account-name mystorageaccount 
  --vnet-name vnet-prod-eastus 
  --subnet subnet-app

# Varsayılan erişimi reddet
az storage account update 
  --resource-group rg-network-prod 
  --name mystorageaccount 
  --default-action Deny

Private Endpoint ise daha ileri seviye bir izolasyon sağlar. Storage account için Private Endpoint oluşturalım:

# Private Endpoint için subnet'te private endpoint network policies'i devre dışı bırak
az network vnet subnet update 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-app 
  --disable-private-endpoint-network-policies true

# Private Endpoint oluştur
az network private-endpoint create 
  --resource-group rg-network-prod 
  --name pe-storage-prod 
  --vnet-name vnet-prod-eastus 
  --subnet subnet-app 
  --private-connection-resource-id /subscriptions/SUBSCRIPTION_ID/resourceGroups/rg-network-prod/providers/Microsoft.Storage/storageAccounts/mystorageaccount 
  --group-id blob 
  --connection-name conn-storage-prod 
  --location eastus

Route Table ile Trafik Yönlendirme

Tüm outbound trafiğin bir Azure Firewall veya NVA (Network Virtual Appliance) üzerinden geçmesini istiyorsan custom route table kullanman gerekir.

# Route table oluştur
az network route-table create 
  --resource-group rg-network-prod 
  --name rt-prod-eastus 
  --location eastus 
  --disable-bgp-route-propagation false

# Varsayılan route'u firewall'a yönlendir
az network route-table route create 
  --resource-group rg-network-prod 
  --route-table-name rt-prod-eastus 
  --name route-to-firewall 
  --address-prefix 0.0.0.0/0 
  --next-hop-type VirtualAppliance 
  --next-hop-ip-address 10.10.0.4

# Route table'ı web subnet'e bağla
az network vnet subnet update 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --name subnet-web 
  --route-table rt-prod-eastus

VNet Durumunu Kontrol Etme ve Sorun Giderme

Yapılandırmayı tamamladıktan sonra her şeyin doğru çalıştığını doğrulamak için şu komutları kullan:

# VNet detaylarını görüntüle
az network vnet show 
  --resource-group rg-network-prod 
  --name vnet-prod-eastus 
  --output table

# Tüm subnet'leri listele
az network vnet subnet list 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --output table

# NSG kurallarını kontrol et
az network nsg rule list 
  --resource-group rg-network-prod 
  --nsg-name nsg-web-prod 
  --output table

# Peering durumunu kontrol et
az network vnet peering list 
  --resource-group rg-network-prod 
  --vnet-name vnet-prod-eastus 
  --output table

# Effective route'ları kontrol et (bir VM'nin NIC'i için)
az network nic show-effective-route-table 
  --resource-group rg-network-prod 
  --name vm-web-001-nic 
  --output table

# Effective NSG kurallarını kontrol et
az network nic list-effective-nsg 
  --resource-group rg-network-prod 
  --name vm-web-001-nic

IP Flow Verify, ağ bağlantısı sorunlarını debug etmek için Network Watcher üzerinden erişilen çok güçlü bir araçtır. Belirli bir kaynaktan hedefe trafik geçip geçmeyeceğini NSG kurallarına göre test eder. Üretim ortamında bir VM’den diğerine bağlanamıyorsan ilk başvurman gereken araç budur.

İsimlendirme Standartları ve Tagging

Deneyimle öğrendiğim en önemli şeylerden biri: İsimlendirme standartları sonradan hayat kurtarır. Azure için şu formatı benimsiyorum:

  • VNet: vnet-[ortam]-[region] – Örnek: vnet-prod-eastus
  • Subnet: subnet-[tier] – Örnek: subnet-web, subnet-db
  • NSG: nsg-[tier]-[ortam] – Örnek: nsg-web-prod
  • Resource Group: rg-[fonksiyon]-[ortam] – Örnek: rg-network-prod

Tagging konusunda ise minimum şu etiketleri kullan:

  • Environment: Production, Staging, Development
  • Project: Projenin kısa adı
  • Owner: Sorumlu kişi veya ekip
  • CostCenter: Faturalama merkezi kodu
  • CreatedBy: Manuel mi, Terraform mi, ARM mı?

Yaygın Hatalar ve Çözümleri

Address space çakışması: Farklı VNet’ler arasında peering kurarken veya VPN bağlantısı yaparken adres aralıkları çakışmamalı. az network vnet list ile mevcut aralıkları kontrol et.

AzureBastionSubnet boyutu: /29 verip Bastion deploy etmeye çalışmak yaygın bir hata. Minimum /27 gerekli.

Service Endpoint vs Private Endpoint karışıklığı: Service Endpoint subnet’ten Azure servisine genel IP üzerinden ama Azure backbone’dan gider. Private Endpoint ise servisin VNet içinde özel bir IP almasını sağlar. Production için Private Endpoint tercih et.

NSG’de Deny kuralı unutmak: NSG’de explicit Deny koymasan bile Azure varsayılan olarak izin verilmemiş trafiği engeller. Ama hub-spoke mimarilerde bazen beklenmedik davranışlar görebilirsin, kurallarını açık yaz.

Sonuç

Azure Virtual Network’ü doğru yapılandırmak, bulut altyapının güvenliği ve performansı açısından temel bir gerekliliktir. Bu yazıda ele aldığımız konuları özetleyelim:

  • Doğru IP adres planlaması yapmadan başlamamalısın. Sonradan değiştirmek çok maliyetli.
  • Her tier için ayrı subnet kullanmak güvenlik ve yönetim kolaylığı sağlar.
  • NSG kurallarını en az yetki prensibiyle (principle of least privilege) yapılandır.
  • VNet Peering iki taraflı yapılandırılmalı ve her iki peering objesi de oluşturulmalıdır.
  • Production ortamlarında Service Endpoint yerine Private Endpoint kullan.
  • İsimlendirme standartları ve tagging’i baştan belirle, sonradan uygumak çok daha zahmetli.
  • Network Watcher araçlarını (IP Flow Verify, Effective Routes) sorun gidermede aktif kullan.

Altyapını Infrastructure as Code ile yönetiyorsan Terraform veya Bicep kullanarak bu yapıyı code repository’de tutmayı kesinlikle öneririm. Hem versiyon kontrolü hem de disaster recovery senaryoları için hayat kurtarır. Bir sonraki yazıda bu VNet yapısını üzerine inşa edilen hub-spoke ağ mimarisini detaylıca ele alacağız.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir