GCP VPC Ağ Oluşturma ve Yapılandırma Rehberi

Tarafındankomut
0 Comments

Google Cloud Platform’da çalışmaya başladığınızda, ilk yapmanız gereken şeylerden biri sağlam bir ağ altyapısı kurmaktır. VPC (Virtual Private Cloud) yapılandırması, bulut ortamınızın omurgasını oluşturur ve yanlış yapılandırılmış bir ağ, güvenlik açıklarından performans sorunlarına kadar pek çok probleme yol açabilir. Bu yazıda GCP üzerinde VPC oluşturma, subnet yapılandırması, firewall kuralları ve pratik senaryolarla gerçek dünyada nasıl kullanacağınızı ele alacağız.

GCP VPC Temelleri

GCP VPC’si, AWS veya Azure’dan alışkın olduğunuz yapıdan biraz farklıdır. En önemli fark, GCP VPC’nin global olmasıdır. Yani tek bir VPC, birden fazla region’daki subnet’leri barındırabilir. Bu, multi-region mimariler kurarken büyük kolaylık sağlar çünkü her region için ayrı VPC oluşturup bunları peering ile bağlamak zorunda kalmazsınız.

GCP’de iki tür VPC modu vardır:

  • Auto mode: Otomatik olarak her region’da bir subnet oluşturur. Hızlı başlangıç için iyidir ama production ortamları için pek tavsiye edilmez.
  • Custom mode: Subnet’leri siz tanımlarsınız. IP aralıklarını, region’ları ve yapıyı tamamen kontrol edersiniz. Production için bu modu kullanın.

Başlamadan önce gcloud CLI’ın kurulu ve yapılandırılmış olduğundan emin olun:

# gcloud kurulum sonrası yapılandırma
gcloud auth login
gcloud config set project YOUR_PROJECT_ID
gcloud config set compute/region europe-west1
gcloud config set compute/zone europe-west1-b

# Mevcut yapılandırmayı kontrol et
gcloud config list

Custom Mode VPC Oluşturma

Production ortamı için her zaman custom mode VPC tercih edin. Auto mode’da IP bloklarını kontrol edemezsiniz ve 10.128.0.0/9 bloğunu otomatik kullanır ki bu, on-premise ağınızla çakışabilir.

# Custom mode VPC oluşturma
gcloud compute networks create production-vpc 
    --subnet-mode=custom 
    --bgp-routing-mode=regional 
    --description="Production ortami icin ana VPC"

# VPC'yi doğrula
gcloud compute networks describe production-vpc

--bgp-routing-mode parametresi önemlidir:

  • regional: Route’lar sadece aynı region’daki router’larla paylaşılır. Çoğu senaryo için yeterlidir.
  • global: Tüm region’lardaki Cloud Router’larla route’lar paylaşılır. Hybrid connectivity senaryolarında gereklidir.

Subnet Yapılandırması

VPC’yi oluşturduktan sonra subnet’leri tanımlamamız gerekiyor. İyi bir IP adresleme planı yapmak, ileride başınızı ağrıtmaz. Ben genellikle şu yaklaşımı kullanıyorum:

  • Production: 10.10.0.0/16
  • Staging: 10.20.0.0/16
  • Development: 10.30.0.0/16

Her ortam içinde de katmanlara göre subnet’leri ayırıyorum (web tier, app tier, data tier).

# Web tier subnet - europe-west1
gcloud compute networks subnets create prod-web-subnet 
    --network=production-vpc 
    --region=europe-west1 
    --range=10.10.1.0/24 
    --description="Web tier - europe-west1" 
    --enable-private-ip-google-access 
    --enable-flow-logs 
    --logging-aggregation-interval=interval-5-sec 
    --logging-flow-sampling=0.5 
    --logging-metadata=include-all

# App tier subnet - europe-west1
gcloud compute networks subnets create prod-app-subnet 
    --network=production-vpc 
    --region=europe-west1 
    --range=10.10.2.0/24 
    --description="App tier - europe-west1" 
    --enable-private-ip-google-access 
    --enable-flow-logs

# Database tier subnet - europe-west1
gcloud compute networks subnets create prod-db-subnet 
    --network=production-vpc 
    --region=europe-west1 
    --range=10.10.3.0/24 
    --description="Database tier - europe-west1" 
    --enable-private-ip-google-access

--enable-private-ip-google-access parametresine dikkat edin. Bu seçenek, harici IP adresi olmayan VM’lerin Google API’larına ve servislerine (Cloud Storage, BigQuery, vb.) erişmesini sağlar. Private subnetlerde bu ayarı mutlaka açın.

--enable-flow-logs ise ağ trafiğini loglayan özelliği aktifleştirir. Production’da güvenlik auditing ve troubleshooting için kritiktir. Evet, biraz ek maliyet getirir ama bir güvenlik olayında bu loglar altın değerinde olur.

Secondary IP Ranges Ekleme

GKE cluster kullanıyorsanız, Pod ve Service IP’leri için secondary range tanımlamanız gerekir:

# GKE için secondary range ekle
gcloud compute networks subnets update prod-app-subnet 
    --region=europe-west1 
    --add-secondary-ranges 
    pods-range=10.10.64.0/18,services-range=10.10.128.0/20

Bu aralıkları önceden planlamanızı öneririm. GKE cluster boyutunuza göre pod IP sayısını hesaplayın. /18, yaklaşık 16.000 pod IP’si demektir ki orta ölçekli cluster’lar için yeterlidir.

Firewall Kuralları

GCP’de firewall kuralları VPC seviyesinde tanımlanır ve VM’lere tag veya service account üzerinden uygulanır. Bu yaklaşım, kuralları belirli instance’lara bağlamak yerine mantıksal gruplar üzerinden yönetmenizi sağlar. Tag tabanlı yaklaşım esneklik sağlar ancak büyük ortamlarda service account tabanlı kurallar daha güvenlidir.

# Internetten HTTP/HTTPS trafiğine izin ver (web tier)
gcloud compute firewall-rules create allow-http-https 
    --network=production-vpc 
    --direction=INGRESS 
    --priority=1000 
    --action=ALLOW 
    --rules=tcp:80,tcp:443 
    --source-ranges=0.0.0.0/0 
    --target-tags=web-server 
    --description="HTTP ve HTTPS trafiklerine izin ver"

# Web tier'dan app tier'a erişim
gcloud compute firewall-rules create allow-web-to-app 
    --network=production-vpc 
    --direction=INGRESS 
    --priority=1000 
    --action=ALLOW 
    --rules=tcp:8080,tcp:8443 
    --source-tags=web-server 
    --target-tags=app-server 
    --description="Web sunucularindan app sunucularina erisim"

# App tier'dan database'e erişim
gcloud compute firewall-rules create allow-app-to-db 
    --network=production-vpc 
    --direction=INGRESS 
    --priority=1000 
    --action=ALLOW 
    --rules=tcp:5432,tcp:3306 
    --source-tags=app-server 
    --target-tags=database-server 
    --description="App sunucularindan database erisimi"

# SSH için IAP (Identity-Aware Proxy) erişimi
gcloud compute firewall-rules create allow-iap-ssh 
    --network=production-vpc 
    --direction=INGRESS 
    --priority=1000 
    --action=ALLOW 
    --rules=tcp:22 
    --source-ranges=35.235.240.0/20 
    --description="IAP uzerinden SSH erisimi"

Son kural çok önemlidir. Doğrudan internet’ten SSH erişimine izin vermek yerine, GCP’nin Identity-Aware Proxy özelliğini kullanarak SSH bağlantılarını yönlendirin. IAP’ın IP aralığı 35.235.240.0/20‘dir ve bu kuralla sadece IAP üzerinden SSH yapılabilir. Bastion host tutma ve genel IP açma zorunluluğunu ortadan kaldırır.

Cloud NAT Yapılandırması

Private subnet’lerdeki VM’lerin internete çıkması gerektiğinde (paket güncellemeleri, dış API çağrıları vb.) Cloud NAT kullanırsınız. NAT gateway, VM’lerinize genel IP atamanıza gerek kalmadan internet erişimi sağlar.

# Önce Cloud Router oluştur
gcloud compute routers create prod-router 
    --network=production-vpc 
    --region=europe-west1 
    --description="Production VPC Cloud Router"

# Cloud NAT yapılandır
gcloud compute routers nats create prod-nat 
    --router=prod-router 
    --region=europe-west1 
    --nat-all-subnet-ip-ranges 
    --auto-allocate-nat-external-ips 
    --min-ports-per-vm=64 
    --log-filter=ERRORS_ONLY

--min-ports-per-vm parametresi dikkat ister. Varsayılan değer 64’tür ve her port bir eşzamanlı bağlantıya karşılık gelir. Çok sayıda dış bağlantı yapan uygulamalarınız varsa (örneğin yoğun API çağrısı yapan servisler) bu değeri artırmanız gerekebilir. SNAT port tükenmesi yaşıyorsanız ilk bakacağınız yer burasıdır.

VPC Peering

Farklı projeler veya ortamlar arasında özel ağ bağlantısı kurmak için VPC Peering kullanılır. Örneğin, merkezi bir logging VPC’nize tüm ortamlardan erişim sağlamak isteyebilirsiniz.

# Production VPC'den Shared Services VPC'ye peering
gcloud compute networks peerings create prod-to-shared 
    --network=production-vpc 
    --peer-project=shared-services-project 
    --peer-network=shared-services-vpc 
    --export-custom-routes 
    --import-custom-routes

# Karşı tarafta da peering oluşturulmalı (shared-services projesinde)
gcloud compute networks peerings create shared-to-prod 
    --network=shared-services-vpc 
    --peer-project=production-project 
    --peer-network=production-vpc 
    --export-custom-routes 
    --import-custom-routes

VPC Peering’de dikkat edilmesi gereken bir nokta: transitif peering desteklenmez. A-B peering ve B-C peering varsa, A ile C birbirleriyle konuşamaz. Bunu aşmak için Network Connectivity Center veya her VPC çifti arasında ayrı peering oluşturmanız gerekir. Çok sayıda VPC varsa bu karmaşıklaşabilir, bu durumda Shared VPC mimarisini değerlendirin.

Shared VPC Mimarisi

Büyük organizasyonlarda birden fazla takım veya proje olduğunda Shared VPC çok işe yarar. Host project’te ağ kaynakları tanımlanır, service project’ler bu ağı kullanır. Ağ yönetimi merkezileşirken projeler birbirinden izole kalır.

# Host project'i etkinleştir
gcloud compute shared-vpc enable HOST_PROJECT_ID

# Service project'i host project'e bağla
gcloud compute shared-vpc associated-projects add 
    SERVICE_PROJECT_ID 
    --host-project=HOST_PROJECT_ID

# Service project'e belirli subnet'lere erişim ver
gcloud compute networks subnets set-iam-policy 
    prod-web-subnet 
    --region=europe-west1 
    --project=HOST_PROJECT_ID 
    policy.json

policy.json dosyasında ilgili service account veya gruba roles/compute.networkUser rolü verilmelidir:

# IAM policy dosyasını oluştur
cat > policy.json << 'EOF'
{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "serviceAccount:[email protected]",
        "group:[email protected]"
      ]
    }
  ]
}
EOF

Private Google Access ve VPC Service Controls

Cloud SQL, Cloud Storage gibi Google servislerine private bağlantı kurmak için private.googleapis.com veya restricted.googleapis.com DNS kayıtlarını yapılandırmanız gerekebilir. Bu özellikle VPC Service Controls kullandığınızda önem kazanır.

# Private Google Access için DNS zone oluştur
gcloud dns managed-zones create googleapis 
    --dns-name=googleapis.com. 
    --description="Private Google APIs" 
    --visibility=private 
    --networks=production-vpc

# DNS kayıtlarını ekle
gcloud dns record-sets create private.googleapis.com. 
    --zone=googleapis 
    --type=A 
    --ttl=300 
    --rrdatas=199.36.153.8,199.36.153.9,199.36.153.10,199.36.153.11

# Wildcard kaydı
gcloud dns record-sets create "*.googleapis.com." 
    --zone=googleapis 
    --type=CNAME 
    --ttl=300 
    --rrdatas=private.googleapis.com.

Network Policies ve Route Yönetimi

Özel route senaryolarında custom static route’lar tanımlayabilirsiniz. Örneğin, on-premise’e giden trafiği VPN gateway üzerinden yönlendirmek için:

# On-premise ağı için özel route
gcloud compute routes create route-to-onprem 
    --network=production-vpc 
    --destination-range=192.168.0.0/16 
    --next-hop-vpn-tunnel=prod-vpn-tunnel 
    --next-hop-vpn-tunnel-region=europe-west1 
    --priority=100 
    --tags=app-server,database-server

# Mevcut route'ları listele
gcloud compute routes list --filter="network=production-vpc"

--priority değeri düşüldükçe öncelik artar (0 en yüksek öncelik). Default route’un önceliği 1000’dir, bunu göz önünde bulundurun.

VPC Ağını Test Etme ve Doğrulama

Yapılandırmayı tamamladıktan sonra her şeyin doğru çalıştığını test edin. GCP’nin Connectivity Tests aracı bunun için harika bir seçenektir:

# İki VM arasında bağlantı testi
gcloud network-management connectivity-tests create web-to-app-test 
    --source-instance=projects/PROJECT/zones/europe-west1-b/instances/web-vm-1 
    --destination-instance=projects/PROJECT/zones/europe-west1-b/instances/app-vm-1 
    --protocol=TCP 
    --destination-port=8080

# Test sonucunu kontrol et
gcloud network-management connectivity-tests describe web-to-app-test

# VPC flow loglarını BigQuery'ye export et (analiz için)
gcloud logging sinks create vpc-flow-logs-sink 
    bigquery.googleapis.com/projects/PROJECT_ID/datasets/network_logs 
    --log-filter='resource.type="gce_subnetwork" AND log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"'

Connectivity Tests, firewall kurallarını ve route’ları simüle ederek trafiğin neden geçemediğini veya geçtiğini analiz eder. Troubleshooting sırasında günler kazandırabilir.

Gerçek Dünya Senaryosu: Üç Katmanlı Uygulama Ağı

Şimdiye kadar öğrendiklerimizi bir araya getirelim. Klasik bir web uygulaması için tam ağ yapısını otomatize eden bir script:

#!/bin/bash
# Production üç katmanlı uygulama VPC kurulumu

set -euo pipefail

PROJECT_ID="my-production-project"
REGION="europe-west1"
VPC_NAME="production-vpc"

echo "VPC olusturuluyor..."
gcloud compute networks create ${VPC_NAME} 
    --project=${PROJECT_ID} 
    --subnet-mode=custom 
    --bgp-routing-mode=regional

echo "Subnetler olusturuluyor..."
# Web tier
gcloud compute networks subnets create web-subnet 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --region=${REGION} 
    --range=10.10.1.0/24 
    --enable-private-ip-google-access 
    --enable-flow-logs

# App tier
gcloud compute networks subnets create app-subnet 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --region=${REGION} 
    --range=10.10.2.0/24 
    --enable-private-ip-google-access 
    --enable-flow-logs

# Database tier
gcloud compute networks subnets create db-subnet 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --region=${REGION} 
    --range=10.10.3.0/24 
    --enable-private-ip-google-access

echo "Firewall kurallari olusturuluyor..."
gcloud compute firewall-rules create fw-allow-health-checks 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --direction=INGRESS 
    --priority=1000 
    --action=ALLOW 
    --rules=tcp 
    --source-ranges=130.211.0.0/22,35.191.0.0/16 
    --target-tags=web-server,app-server

gcloud compute firewall-rules create fw-deny-all-ingress 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --direction=INGRESS 
    --priority=65534 
    --action=DENY 
    --rules=all 
    --description="Varsayilan olarak tum ingress trafiklerini reddet"

echo "Cloud NAT yapılandiriliyor..."
gcloud compute routers create ${VPC_NAME}-router 
    --project=${PROJECT_ID} 
    --network=${VPC_NAME} 
    --region=${REGION}

gcloud compute routers nats create ${VPC_NAME}-nat 
    --project=${PROJECT_ID} 
    --router=${VPC_NAME}-router 
    --region=${REGION} 
    --nat-all-subnet-ip-ranges 
    --auto-allocate-nat-external-ips

echo "VPC kurulumu tamamlandi!"
gcloud compute networks subnets list 
    --project=${PROJECT_ID} 
    --filter="network=${VPC_NAME}"

Health check IP aralıklarına (130.211.0.0/22 ve 35.191.0.0/16) izin vermeyi unutmayın. Load Balancer kullanıyorsanız bu kuralsız health check’ler çalışmaz ve backend’leriniz hep “unhealthy” görünür.

Maliyet Optimizasyonu İpuçları

VPC’nin kendisi ücretsiz olsa da bazı özellikler maliyet yaratır:

  • VPC Flow Logs: Log hacmine göre ücretlendirilir. --logging-flow-sampling=0.5 ile sampling oranını düşürün. Kritik subnetlerde 0.5, diğerlerinde 0.1 iyi bir başlangıçtır.
  • Cloud NAT: İşlenen veri ve NAT gateway sayısına göre ücretlendirilir. Gereksiz NAT gateway’lerini kaldırın.
  • VPC Peering: Peering üzerinden geçen trafik için inter-region’da veri transferi ücreti alınır. Aynı region’daki peering trafiği ücretsizdir.
  • Egress trafiği: İnternete çıkan trafik ücretlidir. Mümkün olduğunca Google ağı içinde kalın.

Sonuç

GCP VPC yapılandırması, ilk bakışta karmaşık görünse de mantığını kavradıktan sonra oldukça sistematik bir yapıya oturur. Custom mode VPC ile başlayın, IP adreslerinizi iyi planlayın, katmanlı bir subnet yapısı kurun ve firewall kurallarınızı tag veya service account bazlı yönetin.

En sık yapılan hatalar şunlardır: Auto mode VPC kullanmak, Private Google Access’i unutmak, firewall kurallarını çok geniş tutmak ve Flow Logs’u hiç açmamak. Bu dört noktaya dikkat ederseniz, sağlam ve güvenli bir ağ altyapısına sahip olursunuz.

Bir sonraki adım olarak Cloud Armor ile DDoS koruması, Private Service Connect ile managed servislere özel bağlantı ve Network Intelligence Center ile ağ görünürlüğü konularına bakmanızı öneririm. Ağ güvenliği ve gözlemlenebilirlik, production ortamlarında hiç ihmal edilmemesi gereken konulardır.

Bir yanıt yazın

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