AWS Site-to-Site VPN Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

Şirket ağını AWS’e bağlamak istediğinizde ilk aklınıza gelen çözüm genellikle Site-to-Site VPN oluyor. Doğru bir seçim, ancak “nasıl yapacağım?” sorusu biraz korkutucu gelebilir. Bu yazıda, bir şirket ofis ağını AWS VPC’ye bağlayan gerçek dünya senaryosu üzerinden Site-to-Site VPN kurulumunu adım adım anlatacağım. BGP routing, redundancy, troubleshooting… hepsini ele alacağız.

Senaryo ve Mimari

Varsayalım ki şirketinizin İstanbul ofisinde 10.0.0.0/16 subnet’i kullanan bir ağ var. AWS tarafında ise 172.16.0.0/16 CIDR bloğuyla bir VPC çalışıyor. Amacımız bu iki ağı şifreli bir tünel üzerinden birbirine bağlamak. Ofis tarafında Cisco ASA ya da Fortinet gibi bir firewall/router olduğunu varsayalım, ama AWS’in indirdiği konfigürasyon dosyaları neredeyse her cihaz için mevcut.

Mimari şu şekilde çalışıyor: AWS tarafında bir Virtual Private Gateway (VGW) oluşturuyorsunuz, müşteri tarafında ise Customer Gateway (CGW) tanımlıyorsunuz. Bu iki bileşen arasında Site-to-Site VPN bağlantısı kurulduğunda AWS size iki adet redundant tünel veriyor. Her tünelin kendi public IP’si var, yani birincil tünel çökse bile ikincisi devreye giriyor.

Ön Hazırlık

AWS tarafına geçmeden önce ofis/datacenter tarafında birkaç şeyi netleştirmeniz gerekiyor.

Müşteri tarafında ihtiyaç duyduklarınız:

  • BGP veya statik routing destekleyen bir router/firewall
  • Static public IP adresi (CGNAT arkasında olmayan)
  • IKEv1 veya IKEv2 desteği
  • IPSec desteği

Ofis public IP’nizi öğrenmek için:

curl -s https://checkip.amazonaws.com
# ya da
dig +short myip.opendns.com @resolver1.opendns.com

AWS CLI’yi kullanacaksanız önce credentials’ı ayarlayın:

aws configure
# AWS Access Key ID: AKIA...
# AWS Secret Access Key: ...
# Default region name: eu-west-1
# Default output format: json

Adım 1: Customer Gateway Oluşturma

Customer Gateway, AWS’e “karşı tarafın kim olduğunu” söylediğiniz yerdir. Ofis router’ınızın public IP’sini ve routing tipini burada belirtiyorsunuz.

# BGP kullanan CGW oluşturma
aws ec2 create-customer-gateway 
  --type ipsec.1 
  --public-ip 203.0.113.50 
  --bgp-asn 65000 
  --tag-specifications 'ResourceType=customer-gateway,Tags=[{Key=Name,Value=istanbul-office-cgw}]'

Eğer BGP kullanmayacaksanız ve statik routing tercih ediyorsanız BGP ASN kısmı yine de zorunlu ama gerçekte kullanılmıyor. Bu durumda --bgp-asn 65000 yazabilirsiniz, bağlantı oluştururken statik seçeneğini seçersiniz.

Komutun çıktısından CustomerGatewayId değerini not edin, sonraki adımda kullanacaksınız. Format şöyle görünür: cgw-0a1b2c3d4e5f67890

BGP kullanıyorsanız ASN değerini dikkatli seçin. AWS tarafı 64512 ASN’ini kullanıyor (default), sizin tarafınız farklı bir ASN kullanmalı. Private ASN range’i 64512-65534 arasındadır.

Adım 2: Virtual Private Gateway Oluşturma

VGW, AWS tarafındaki VPN endpoint’idir. VPC’nize attach edeceğiniz bu bileşen olmadan tüneller çalışmaz.

# VGW oluşturma
aws ec2 create-vpn-gateway 
  --type ipsec.1 
  --amazon-side-asn 64512 
  --tag-specifications 'ResourceType=vpn-gateway,Tags=[{Key=Name,Value=production-vgw}]'

VGW’yi oluşturduktan sonra VPC’nize attach etmeniz gerekiyor:

# VGW'yi VPC'ye bağlama
aws ec2 attach-vpn-gateway 
  --vpn-gateway-id vgw-0a1b2c3d4e5f67890 
  --vpc-id vpc-0987654321abcdef0

Attach işlemi birkaç dakika sürebilir. Durumu kontrol etmek için:

aws ec2 describe-vpn-gateways 
  --vpn-gateway-ids vgw-0a1b2c3d4e5f67890 
  --query 'VpnGateways[0].VpcAttachments'

State: attached görene kadar bir sonraki adıma geçmeyin.

Adım 3: VPN Bağlantısı Oluşturma

Artık her iki taraf tanımlandığına göre aralarındaki bağlantıyı oluşturabilirsiniz. Burada routing tipini seçiyorsunuz.

# BGP ile dynamic routing kullanan VPN bağlantısı
aws ec2 create-vpn-connection 
  --type ipsec.1 
  --customer-gateway-id cgw-0a1b2c3d4e5f67890 
  --vpn-gateway-id vgw-0a1b2c3d4e5f67890 
  --options '{"StaticRoutesOnly":false,"TunnelOptions":[{"TunnelInsideCidr":"169.254.100.0/30","PreSharedKey":"MyStr0ngPSK#2024"},{"TunnelInsideCidr":"169.254.101.0/30","PreSharedKey":"MyOth3rPSK#2024"}]}' 
  --tag-specifications 'ResourceType=vpn-connection,Tags=[{Key=Name,Value=istanbul-to-aws-vpn}]'

Eğer statik routing kullanacaksanız StaticRoutesOnly değerini true yapın ve sonrasında statik rotaları eklemeniz gerekecek:

# Statik rota ekleme
aws ec2 create-vpn-connection-route 
  --vpn-connection-id vpn-0a1b2c3d4e5f67890 
  --destination-cidr-block 10.0.0.0/16

VPN bağlantısı oluşturulduktan sonra konfigürasyon dosyasını indirin. Bu dosya ofis router’ınız için hazır konfigürasyon içeriyor:

# Konfigürasyon dosyasını indirme
aws ec2 get-vpn-connection-device-sample-configuration 
  --vpn-connection-id vpn-0a1b2c3d4e5f67890 
  --vpn-connection-device-type-id 5fb390ba 
  --internet-key-exchange-version ikev2 
  --output text > vpn-config.txt

Hangi cihaz type ID’lerinin mevcut olduğunu görmek için:

aws ec2 get-vpn-connection-device-types 
  --query 'VpnConnectionDeviceTypes[*].[Vendor,Platform,Software,VpnConnectionDeviceTypeId]' 
  --output table

Adım 4: Route Table Güncellemeleri

VPN bağlantısı kurulduktan sonra AWS tarafındaki route table’ları güncellemeniz gerekiyor. Aksi takdirde trafiğin nereye gideceğini AWS bilemez.

BGP kullanıyorsanız route propagation özelliğini aktif edebilirsiniz. Bu sayede on-premise’den duyurulan rotalar otomatik olarak route table’a eklenir:

# Route propagation'ı aktif etme
aws ec2 enable-vgw-route-propagation 
  --route-table-id rtb-0a1b2c3d4e5f67890 
  --gateway-id vgw-0a1b2c3d4e5f67890

Statik routing kullanıyorsanız rotaları manuel eklemeniz gerekiyor:

# Manuel rota ekleme
aws ec2 create-route 
  --route-table-id rtb-0a1b2c3d4e5f67890 
  --destination-cidr-block 10.0.0.0/16 
  --gateway-id vgw-0a1b2c3d4e5f67890

Private subnet’lerde çalışan EC2 instance’larınızın VPN üzerinden gelen trafiğe yanıt verebilmesi için bu adım kritik önem taşıyor.

Adım 5: Security Group Ayarları

VPN tüneli kurulduktan sonra bile EC2 instance’larınıza erişemiyorsanız Security Group’ları kontrol edin. Ofis subnet’inden gelen trafiğe izin vermeniz gerekiyor:

# Ofis subnet'inden SSH trafiğine izin
aws ec2 authorize-security-group-ingress 
  --group-id sg-0a1b2c3d4e5f67890 
  --protocol tcp 
  --port 22 
  --cidr 10.0.0.0/16

# Ofis subnet'inden ICMP (ping) trafiğine izin
aws ec2 authorize-security-group-ingress 
  --group-id sg-0a1b2c3d4e5f67890 
  --protocol icmp 
  --port -1 
  --cidr 10.0.0.0/16

Network ACL kullanıyorsanız onları da güncellemeyi unutmayın. Security Group’lar stateful ama Network ACL’ler stateless olduğu için hem inbound hem outbound kurallarını eklemeniz gerekiyor.

Ofis Router Konfigürasyonu

AWS’in indirdiğiniz konfigürasyon dosyası içindeki değerleri kullanarak ofis router’ınızı ayarlayın. Örnek olarak bir Linux sunucu üzerinde strongSwan kullanıyorsanız temel konfigürasyon şöyle görünür:

# strongSwan kurulumu (Ubuntu/Debian)
apt-get install -y strongswan strongswan-pki

# /etc/ipsec.conf düzenleme
cat > /etc/ipsec.conf << 'EOF'
config setup
    charondebug="ike 1, knl 1, cfg 0"

conn aws-tunnel-1
    authby=secret
    auto=start
    left=%defaultroute
    leftid=203.0.113.50
    right=TUNNEL_1_PUBLIC_IP
    type=tunnel
    ikelifetime=8h
    keylife=1h
    rekeymargin=3m
    keyingtries=%forever
    leftsubnet=10.0.0.0/16
    rightsubnet=172.16.0.0/16
    ike=aes128-sha1-modp1024
    esp=aes128-sha1-modp1024
    keyexchange=ikev1
    dpddelay=10s
    dpdtimeout=30s
    dpdaction=restart
EOF

Pre-shared key’i /etc/ipsec.secrets dosyasına ekleyin:

# /etc/ipsec.secrets
203.0.113.50 TUNNEL_1_PUBLIC_IP : PSK "MyStr0ngPSK#2024"

Konfigürasyon değişikliklerini uyguladıktan sonra:

# strongSwan'ı yeniden başlatma ve tüneli başlatma
systemctl restart strongswan
ipsec up aws-tunnel-1

# Tünel durumunu kontrol etme
ipsec status
ipsec statusall | grep aws-tunnel

Tünel Durumunu İzleme

AWS tarafından tünel durumunu kontrol etmek için CloudWatch metriklerini veya CLI’yi kullanabilirsiniz:

# VPN bağlantı durumunu kontrol etme
aws ec2 describe-vpn-connections 
  --vpn-connection-ids vpn-0a1b2c3d4e5f67890 
  --query 'VpnConnections[0].VgwTelemetry'

Bu komutun çıktısında her tünel için Status: UP veya Status: DOWN göreceksiniz. StatusMessage alanı sorun olduğunda ne olduğuna dair ipucu veriyor.

CloudWatch alarm oluşturmak için:

# Tünel DOWN olduğunda alarm
aws cloudwatch put-metric-alarm 
  --alarm-name vpn-tunnel-down 
  --alarm-description "VPN tunnel is down" 
  --metric-name TunnelState 
  --namespace AWS/VPN 
  --statistic Minimum 
  --period 60 
  --evaluation-periods 2 
  --threshold 1 
  --comparison-operator LessThanThreshold 
  --dimensions Name=VpnId,Value=vpn-0a1b2c3d4e5f67890 
  --alarm-actions arn:aws:sns:eu-west-1:123456789012:vpn-alerts

Troubleshooting

Sysadmin hayatının gerçeği: ilk kurulumda her zaman bir şeyler ters gider. İşte en sık karşılaşılan sorunlar ve çözümleri.

Tünel UP ama trafik geçmiyor:

Bu genellikle routing sorunudur. AWS tarafında kontrol listesi:

  • Route table’da on-premise CIDR için rota var mı?
  • Route propagation aktif mi?
  • Security Group’lar on-premise subnet’e izin veriyor mu?
  • Network ACL’ler doğru mu?

Ofis tarafında kontrol listesi:

  • Return route (AWS CIDR -> VGW) var mı?
  • Firewall kuralları çıkan ve dönen trafiğe izin veriyor mu?

Tünel hiç UP olmuyor:

IKE negotiation sorunudur genellikle. strongSwan loglarına bakın:

# strongSwan loglarını izleme
journalctl -u strongswan -f

# ya da
tail -f /var/log/syslog | grep charon

AWS tarafında Phase 1 veya Phase 2 parametre uyuşmazlığı olabilir. describe-vpn-connections çıktısındaki StatusMessage alanı genellikle net bilgi veriyor.

MTU sorunları:

VPN tünellerinde MTU sorunları çok yaygın. Büyük paketler geçemez, küçükler geçer. Test için:

# MTU test komutu
ping -M do -s 1400 172.16.1.10

# TCP MSS clamping (Linux)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN 
  -j TCPMSS --clamp-mss-to-pmtu

BGP ile Dinamik Routing Avantajları

Statik routing basit senaryolar için yeterli ama BGP’nin sağladığı avantajlar pratikte çok değerli:

  • Otomatik failover: İki tünelden biri çökerse BGP otomatik olarak diğerine geçer
  • Route propagation: Yeni subnet’ler eklediğinizde her seferinde manuel rota eklemeniz gerekmiyor
  • Path selection: Birden fazla bağlantı varsa en iyi yolu otomatik seçer

BGP neighbor durumunu kontrol etmek için (Cisco IOS örneği):

# Cisco IOS BGP komutları
show bgp summary
show ip bgp neighbors 169.254.100.1
show ip route bgp

Linux üzerinde BGP kullanıyorsanız FRRouting (FRR) iyi bir seçenek:

# FRR kurulumu
apt-get install -y frr

# BGP konfigürasyonu /etc/frr/frr.conf
vtysh -c "show ip bgp summary"
vtysh -c "show ip bgp neighbors 169.254.100.1 advertised-routes"

Maliyet Optimizasyonu

Site-to-Site VPN maliyeti iki bileşenden oluşuyor: bağlantı saati ücreti ve veri transfer ücreti. AWS’den ofise giden trafik ücretli, ofisten AWS’e gelen trafik ücretsiz.

Birden fazla ofis veya datacenter bağlayacaksanız Transit Gateway kullanmayı düşünün. Her VGW ayrı VPC’ye attach edilmek zorunda ama Transit Gateway ile hub-and-spoke mimarisi kurarak hem maliyeti hem de yönetim karmaşıklığını azaltabilirsiniz.

# Transit Gateway VPN attachment oluşturma
aws ec2 create-vpn-connection 
  --type ipsec.1 
  --customer-gateway-id cgw-0a1b2c3d4e5f67890 
  --transit-gateway-id tgw-0a1b2c3d4e5f67890 
  --options '{"StaticRoutesOnly":false}'

Development ortamları için VPN bağlantısını iş saatleri dışında kapatmak isterseniz bir Lambda fonksiyonu ile otomatize edebilirsiniz. Ancak dikkat edin, VPN bağlantısını silip yeniden oluşturduğunuzda tünel IP adresleri değişebilir ve ofis tarafı konfigürasyonunu güncellemeniz gerekebilir.

Monitoring ve Alerting

Production ortamında VPN bağlantısını aktif olarak izlemek şart. CloudWatch Dashboard oluşturun:

# Basit monitoring scripti
#!/bin/bash
VPN_ID="vpn-0a1b2c3d4e5f67890"
REGION="eu-west-1"

STATUS=$(aws ec2 describe-vpn-connections 
  --vpn-connection-ids $VPN_ID 
  --region $REGION 
  --query 'VpnConnections[0].VgwTelemetry[*].Status' 
  --output text)

echo "Tunnel statuses: $STATUS"

if echo "$STATUS" | grep -q "DOWN"; then
  echo "WARNING: At least one tunnel is DOWN!"
  # SNS notification veya PagerDuty tetikleyebilirsiniz
  aws sns publish 
    --topic-arn arn:aws:sns:eu-west-1:123456789012:ops-alerts 
    --message "VPN Tunnel DOWN: $VPN_ID" 
    --subject "ALERT: VPN Tunnel Down"
fi

Bu scripti cron ile 5 dakikada bir çalıştırabilirsiniz:

# Crontab'a ekleme
echo "*/5 * * * * /usr/local/bin/check-vpn-status.sh >> /var/log/vpn-monitor.log 2>&1" | crontab -

Güvenlik Önerileri

Site-to-Site VPN kurarken güvenlik tarafını atlamamak gerekiyor:

  • Pre-shared key’leri güçlü tutun: En az 32 karakter, özel karakterler içermeli
  • IKEv2 tercih edin: IKEv1’e göre daha güvenli ve daha hızlı müzakere süreci
  • PSK’ları düzenli rotate edin: AWS konsolu üzerinden tünel seçeneklerini modify ederek PSK değiştirebilirsiniz
  • AWS Secrets Manager kullanın: PSK’ları plaintext dosyalarda saklamak yerine Secrets Manager’a koyun
  • VPN connection logs’u aktif edin: Kimin ne zaman bağlandığını takip edin
  • Least privilege: VPN trafiğinin yalnızca gerekli portlara ve servislere erişebildiğinden emin olun

AWS tarafında tünel seçeneklerini güvenlik odaklı ayarlamak için:

# Tünel seçeneklerini güncelleme (IKEv2, güçlü şifreleme)
aws ec2 modify-vpn-tunnel-options 
  --vpn-connection-id vpn-0a1b2c3d4e5f67890 
  --vpn-tunnel-outside-ip-address TUNNEL_1_OUTSIDE_IP 
  --tunnel-options '{
    "IKEVersions": [{"Value": "ikev2"}],
    "Phase1EncryptionAlgorithms": [{"Value": "AES256"}],
    "Phase2EncryptionAlgorithms": [{"Value": "AES256"}],
    "Phase1IntegrityAlgorithms": [{"Value": "SHA2-256"}],
    "Phase2IntegrityAlgorithms": [{"Value": "SHA2-256"}],
    "Phase1DHGroupNumbers": [{"Value": 14}],
    "Phase2DHGroupNumbers": [{"Value": 14}]
  }'

Sonuç

AWS Site-to-Site VPN kurulumu ilk bakışta karmaşık görünse de adımları doğru takip ettiğinizde oldukça sistematik bir süreç. Customer Gateway ve Virtual Private Gateway oluşturma, bağlantıyı kurma, route table’ları güncelleme ve ofis tarafı konfigürasyonunu yapma… Bunların her birini doğru sırayla yaparsanız tüneller genellikle sorunsuz ayağa kalkıyor.

Pratikte en çok zaman harcadığım kısım routing sorunları ve MTU problemleri oldu. Tünel UP görünüyor ama trafik geçmiyor diyorsanız önce route table’ları kontrol edin, sonra Security Group’ları, ardından MTU testine geçin. Bu sırayla gidince sorunu genellikle ilk iki adımda buluyorsunuz.

BGP’ye yatırım yapmaya değer. Statik routing başlangıç için kolay görünse de zamanla yönetimi zorlaşıyor. Özellikle birden fazla subnet veya birden fazla lokasyon olduğunda BGP’nin otomatik route yönetimi sizi tonlarca manuel işten kurtarıyor. Yüksek erişilebilirlik gerektiren production ortamlar için ise iki tüneli de UP tutmaya çalışın ve CloudWatch alarmlarını baştan kurun, bir sorun çıktığında gece 3’te önünüze baksın istemezsiniz.

Bir yanıt yazın

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