Veri merkeziniz AWS'teki iş yüklerine, bir yıldır sessizce çalışan bir site-to-site VPN üzerinden ulaşıyor. Bir gece AWS rutin bakım sırasında bir tünel uç noktasını değiştiriyor ve VPC'ye giden tüm bağlantılar kopuyor. Güvenlik duvarında yalnızca tünel 1 yapılandırılmıştı. Tünel 2 ise oluşturulduğu günden beri DOWN görünüyordu.
Çoğu diyagramda site-to-site VPN tek bir çizgidir. Pratikte iki IPsec tüneli, iki BGP oturumu ve bir MTU bütçesidir; kesintiler de o çizginin gizlediği parçalardan çıkar. Bu yazı IPsec'in yapı taşlarını, bir AWS örneğini, statik yönlendirme ile BGP karşılaştırmasını, yedekliliği, MTU ve MSS'i, izlemeyi ve özel bir hattın ne zaman daha uygun olduğunu ele alıyor.
Site-to-site VPN ile uzaktan erişim VPN'i
Site-to-site VPN iki ağı birleştirir: Tünelleri her iki uçtaki ağ geçitleri tutar, arkalarındaki host'ların ise hiçbir VPN yazılımına ihtiyacı yoktur. Uzaktan erişim VPN'i ise tek bir cihazı bağlar; her dizüstü bilgisayarda bir istemci ve oturum açan bir kullanıcı vardır. Asıl ihtiyaç kişilerin iç uygulamalara erişmesiyse, bir zero trust mimarisindeki kimlik tabanlı bir proxy çoğu zaman ikisinden de daha uygundur.
IPsec'in yapı taşları
IKEv2 (RFC 7296) eşlerin kimliğini doğrular ve anahtarları müzakere eder. ESP (RFC 4303) trafiği şifreler.
| Parça | Ne yapar | Yaygın tercih |
|---|---|---|
| IKE SA (1. aşama) | Eşlerin kimliğini doğrular ve IKE'yi korur; UDP 500, NAT arkasında 4500 | AES-GCM, SHA-2, DH grubu 14, 19 ya da 20; 8 saat |
| Child SA (2. aşama) | Her yön için bir ESP güvenlik ilişkisi (security association) | AES-GCM; 1 saat, süresi dolmadan yeniden anahtarlanır |
| ESP | Her paketi şifreler: IP protokolü 50, NAT traversal ile UDP 4500 | Tünel modu |
| Ölü eş tespiti (DPD) | Sessiz kalan bir tüneli temizleyen ya da yeniden başlatan canlılık kontrolleri | 30 ila 40 saniye |
| Rota tabanlı tünel | Yönlendirmenin ve BGP'nin kullanabildiği bir tünel arayüzü | BGP için gerekli |
IKEv2 normalde IKE SA'yı ve ilk child SA'yı dört mesajda kurar (IKE_SA_INIT ve IKE_AUTH). IKEv1, 2023'te RFC 9395 ile kullanımdan kaldırıldı. Algoritmalar tarafında RFC 8247, DH grubu 14'ün uygulanmasını zorunlu tutar ve grup 19'u önerir; 2, 5, 23 ve 24 numaralı gruplar kullanılmamalı, grup 22 ise kesinlikle kullanılmamalıdır.
Bağlantı başına iki tünel: bir AWS örneği
AWS Site-to-Site VPN, customer gateway cihazınızı AWS tarafındaki bir ağ geçidine bağlar. AWS tünel seçenekleri dokümantasyonuna göre her bağlantının iki tüneli vardır; her birinin kendi genel IP'si vardır ve farklı Availability Zone'larda sonlanırlar.
AWS, yamalar ve donanımın kullanımdan kaldırılması için tünel uç noktalarını her seferinde bir tünel olmak üzere değiştirir; bu yüzden yalnızca tek bir tünel kullanan bir cihaz, o uç nokta her değiştirildiğinde bağlantısını kaybedebilir. Tünellerden biri günde bir saatten fazla kapalı kaldığında AWS Health aylık bir bildirim gönderir.
Her tünelin 169.254.0.0/16 aralığından alınmış bir iç /30'u vardır. İlk kullanılabilir adresi AWS, ikincisini cihazınız alır ve BGP bu ikisi arasında çalışır. Başlatma eylemini (startup action) start olarak ayarlamadığınız sürece (yalnızca IKEv2) IKE'yi cihazınız başlatır. AWS, cihazınız teklifleri hangi sırayla gönderirse göndersin, onları izin verilen listesindeki en düşük değerden başlayarak değerlendirir; bu yüzden IKEv1'i, SHA-1'i ve 2, 5 ile 22 ila 24 numaralı DH gruplarını her iki tarafta da kaldırın.
| Virtual private gateway | Transit gateway | |
|---|---|---|
| Bağladığı | Tek bir VPC | Çok sayıda VPC, VPN ve Direct Connect |
| Tünel başına bant genişliği | 1,25 Gbps | 1,25 Gbps; Large Bandwidth Tunnels ile 5 Gbps |
| Tüneller arasında ECMP | Hayır | Evet, BGP ile |
| Cihazınızdan gelen BGP rotaları | 100 | 1.000 |
| Ek maliyet | Yok | Transit gateway ücretleri |
İki tünelin birebir aynı kalması için onları kodla tanımlayın. Terraform'da tünel 1:
resource "aws_vpn_connection" "dc" {
vpn_gateway_id = aws_vpn_gateway.main.id
customer_gateway_id = aws_customer_gateway.dc.id
type = "ipsec.1"
static_routes_only = false
tunnel1_inside_cidr = "169.254.10.0/30"
tunnel1_ike_versions = ["ikev2"]
tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
tunnel1_phase1_integrity_algorithms = ["SHA2-384"]
tunnel1_phase1_dh_group_numbers = [20]
tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
tunnel1_phase2_dh_group_numbers = [20]
tunnel1_dpd_timeout_seconds = 30
tunnel1_dpd_timeout_action = "restart"
tunnel1_startup_action = "start"
# tunnel2_*: the same values with 169.254.10.4/30
}
Statik yönlendirme mi, BGP mi
Statik yönlendirmede prefix'lerinizi bağlantı üzerinde listelersiniz ve yük devretmeyi cihazınızın sağlık kontrollerine bırakırsınız. BGP'de her tünel bir eBGP oturumu çalıştırır ve ölü bir tünelin rotaları, oturumu düştüğünde geri çekilir. AWS, cihazın desteklediği her durumda BGP'yi önerir; ECMP de BGP gerektirir. Dört kural:
- Farklı özel ASN'ler kullanın. AWS tarafının varsayılanı 64512'dir. Lokasyonunuza kendi özel ASN'sini verin: 64512 ila 65534 ya da 4200000000 ila 4294967294 (RFC 6996).
- Özet rotalar duyurun. Bir virtual private gateway cihazınızdan en fazla 100 rota kabul eder ve bu sabit bir sınırdır.
- CIDR'ları asla çakıştırmayın. VPC'nin yerel rotası, daha spesifik olsa bile her VPN rotasından önce gelir. Adres alanını lokasyonlar genelinde planlayın ya da bir tarafta NAT kullanın.
- Seçim sırasını bilin. Aynı prefix için bir virtual private gateway önce Direct Connect'i, sonra statik VPN rotalarını, sonra BGP rotalarını tercih eder; ardından en kısa AS path'e, en son da en düşük MED'e bakar.
ECMP olmadan AWS, dönüş trafiğini her seferinde tek bir tünelden gönderir ve bu tüneli MED ile işaretler. AWS rota önceliği rehberi, asimetrik yönlendirmeye izin vermeyi ve AS path'leri eşit tutmayı önerir. Stateful güvenlik duvarınız bununla baş edemiyorsa tünel 2'de AS path prepend yapın ve local preference değerini düşürün; bu durumda AWS'in çıkış yolu değiştiğinde akışlar kopabilir. AWS örnek yapılandırması, RFC 4271'in önerdiği 90 saniye yerine 10 saniyelik keepalive ve 30 saniyelik hold time kullanır.
Yedeklilik tasarımları
İki tünel AWS tarafındaki arızaları karşılar. Yine de cihazınızı, ISP'nizi ve lokasyonunuzu paylaşırlar.
| Tasarım | Tünel | Dayandığı durum | Dayanamadığı durum |
|---|---|---|---|
| Tek cihaz, tek ISP | 2 | AWS uç nokta bakımı | Cihaz ya da ISP arızası |
| İki cihaz, tek ISP | 4 | Cihaz arızası ya da yaması | ISP kesintisi |
| İki cihaz, iki ISP | 4 | Cihaz ya da ISP arızası | Lokasyonun kaybı |
| İki bağlantı, transit gateway ECMP | 4 ya da daha fazla | Aynısı, daha fazla bant genişliğiyle | Tek tünelin sınırını aşan tek bir akış |
İki cihazla her cihazın kendi VPN bağlantısı olur ve ikisi de aynı prefix'leri duyurur. ECMP her akışı hash ile tek bir tünele atar; böylece dört tünel toplamda yaklaşık 5 Gbps sağlar, ama tek bir TCP bağlantısı yine en fazla 1,25 Gbps'e ulaşır ve stateful bir güvenlik duvarı simetri için kaynak NAT'a ihtiyaç duyabilir. Çok sayıda lokasyon olduğunda transit gateway, bir hub-and-spoke ağın merkezi olur.
MTU ve MSS clamping
Tünellenen her paket yeni bir IP başlığı ve ESP ek yükü taşır. AWS en fazla 1.446 baytlık MTU'yu ve 1.406 baytlık TCP MSS'i destekler; Path MTU Discovery ve jumbo frame desteği yoktur. AWS customer gateway en iyi uygulamalarına göre kesin değerler kullandığınız algoritmalara bağlıdır:
| Şifreleme ve bütünlük | NAT-T | Tünel MTU'su | TCP MSS (IPv4) |
|---|---|---|---|
| AES-GCM-16 | Kapalı | 1446 | 1406 |
| AES-GCM-16 | Açık | 1438 | 1398 |
| AES-CBC, SHA-1 ya da SHA2-256 | Kapalı | 1438 | 1398 |
| AES-CBC, SHA-1 ya da SHA2-256 | Açık | 1422 | 1382 |
| AES-CBC, SHA2-512 | Açık | 1406 | 1366 |
Tünel MTU'sunu ayarlayın ve TCP SYN paketlerinin MSS değerini her iki yönde de sınırlayın (clamp), çünkü her taraf kendi değerini duyurur. Bir Linux ağ geçidinde:
ip link set dev vti1 mtu 1446
iptables -t mangle -A FORWARD -o vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
iptables -t mangle -A FORWARD -i vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
Yanlış bir değerin klasik belirtisi: Ping ve SSH çalışır, ama dosya kopyalamaları takılır. AWS'in cihaz gereksinimleri sayfası 1.399 bayt önerir; bu da çalışır, ama birkaç bayt israf eder.
Tünelleri izlemek
- Tünel durumu. CloudWatch her tünel için TunnelState yayınlar; BGP bağlantılarında 1, oturumun kurulduğu anlamına gelir. Tünellerden biri 1'in altına düştüğünde alarm verin. TunnelDataIn ve TunnelDataOut, trafiği hangi tünelin taşıdığını gösterir.
- Loglar. Site-to-Site VPN logları IKE durumlarını, DPD olaylarını, BGP durumunu ve rota değişikliklerini kaydeder.
- Sizin tarafınız. Her tünel için BGP durumunu ve alınan prefix'leri izleyin. Kurulmuş ama sıfır prefix alan bir oturum yine de bir kesintidir.
Bir tünel ayağa kalkmıyorsa katman katman kontrol edin: IKE SA, IPsec SA, AWS iç adresine ping, sonra BGP.
Direct Connect'e ne zaman geçilmeli
| Site-to-Site VPN | Direct Connect | |
|---|---|---|
| Yol | Genel internet, şifreli | Bir Direct Connect lokasyonunda özel devre |
| Bant genişliği | Tünel başına 1,25 Gbps, Large Bandwidth Tunnels ile 5 Gbps | Hosted bağlantıda 50 Mbps ila 25 Gbps, dedicated bağlantıda 1 ila 400 Gbps |
| SLA | Bağlantı başına %99,95 | Maximum resiliency modeliyle %99,99'a kadar |
| Şifreleme | Her zaman IPsec | Varsayılan olarak yok; desteklenen dedicated portlarda MACsec ya da üzerinde IPsec |
Trafik sürekli gigabit seviyesindeyse, gecikme önemliyse ya da internet çıkış trafiği bir porttan daha pahalıya geliyorsa geçin. Eylül 2026'dan beri 10 ve 100 Gbps'lik dedicated bağlantılar, bir kademe içindeki dışa veri aktarımını da kapsayan sabit ücretli fiyatlandırmayı kullanabiliyor. VPN'i yedek olarak tutun: Virtual private gateway Direct Connect rotalarını tercih eder; bu yüzden trafik tünelleri yalnızca devre arızalandığında kullanır. Felaket kurtarma mimari diyagramı bu planlamayı ele alıyor.
Site-to-site VPN diyagramı
Diyagram içeriği
- On-premises data center · 10.20.0.0/16 · AS 65010
- Server LAN
- ERP database
- File server
- Edge firewall (customer gateway)
- VPC · eu-west-1
- Virtual private gateway · AS 64512
- Tunnel 1 endpoint
- Tunnel 2 endpoint
- Private subnet · eu-west-1a
- App instance
- Private subnet · eu-west-1b
- to 10.50.0.0/16
- Tunnel 1 · inside 169.254.10.0/30 · BGP .2 ↔ .1
- Tunnel 2 · inside 169.254.10.4/30 · BGP .6 ↔ .5
- 10.20.0.0/16
Nasıl okunur:
- Solda veri merkezi: AS 65010'da 10.20.0.0/16. LAN, VPC trafiğini customer gateway cihazı olan uç güvenlik duvarına gönderir.
- İki tünel, virtual private gateway'in iki uç noktasına ulaşır; her birinin kendi iç /30'u ve BGP oturumu vardır. İkisi de açıktır; dönüş tünelini AWS seçer.
- Sağda VPC: 10.50.0.0/16; iki Availability Zone'da özel alt ağlar ve 10.20.0.0/16'ya giden yayılmış (propagated) bir rota.
- Markdown bloğu, iki tünelde de aynı olması gereken ayarları listeler.
- Alttaki notlar, iki tünelin neyi karşıladığını (uç nokta değişimleri) ve neyi karşılamadığını (tek güvenlik duvarı, tek ISP) söyler.
Site-to-site VPN diyagramlarını net çizmek
- İki ucu da etiketleyin: CIDR, ASN ve genel IP. VPN ile ilgili destek taleplerinin çoğu bunlardan biriyle başlar.
- İki tüneli de çizin, iç /30'ları ve BGP eşleriyle birlikte; hangisinin neden tercih edildiğini de belirtin.
- Ortak ayarları tek bir kutuya koyun: IKE sürümü, algoritmalar, DH grubu, yaşam süreleri, MTU ve MSS.
- Tek hata noktalarını gösterin; örneğin tek bir cihaz ya da tek bir ISP.
- Dışarıda bırakın: ön paylaşımlı anahtarlar, ISP'nin iç detayları ve host listeleri.
Ağ topolojisi diyagramı ofis tarafını, AWS VPC diyagramı ise alt ağları ve rota tablolarını ele alıyor.
Archboard'da oluşturun
- Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
- Veri merkezi için Temel paketinden bir Çerçeve ekleyin ve ona CIDR'ını ve ASN'sini içeren bir ad verin. İçine, hepsi Ağ paketinden olmak üzere, iki Sunucu düğümü içeren bir Alt ağ ve bir Güvenlik duvarı ekleyin.
- Ağ paketinden bir VPC ekleyin. İçine, virtual private gateway için iki Yönlendirici düğümü içeren bir Çerçeve ve her birinde Bulut paketinden bir Hesaplama düğümü olan iki özel Alt ağ düğümü ekleyin.
- Tünelleri güvenlik duvarından uç noktalara, iki ucu oklu olarak çizin ve iç /30 ile BGP eşleriyle etiketleyin. LAN'dan güvenlik duvarına ve ağ geçidinden alt ağlara kenarlar ekleyin.
- Ortak ayarlar için tünellerin arasına Temel paketinden bir Markdown bloğu, notlar için de Metin ekleyin.
VPN Terraform'da tanımlıysa ücretsiz Terraform’dan diyagrama aracı size ilk taslağı verir; ağ diyagramlarına da göz atın.
Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.
SSS
Bir site-to-site VPN diyagramı neleri göstermeli? CIDR'larıyla birlikte iki ağı, her ağ geçidinin genel IP'sini ve ASN'sini, her tünelin iç adreslerini, yönlendirmeyi ve iki tarafın eşleştirmesi gereken ayarları.
AWS Site-to-Site VPN'de neden iki tünel var? Her bağlantının, farklı Availability Zone'lardaki uç noktalara giden iki tüneli vardır. AWS bunların bakımını tek tek yapar; ikisi de yapılandırılmışsa trafik durmak yerine diğer tünele geçer.
IPsec üzerinde statik yönlendirme mi, BGP mi kullanmalıyım? Cihazınız destekliyorsa BGP. Arızalı bir tünelin rotalarını otomatik olarak geri çeker ve ECMP için gereklidir. Statik yönlendirme, BGP desteği olmayan cihazlar içindir.
AWS VPN için hangi MTU ve MSS değerlerini kullanmalıyım? AES-GCM ile ve NAT traversal olmadan en fazla 1.446 ve 1.406 bayt. CBC şifreleri ve NAT-T, AWS tablosundaki daha küçük değerleri gerektirir.
VPN yerine ne zaman Direct Connect kullanmalıyım? Trafik sürekli gigabit seviyesindeyse, gecikmenin öngörülebilir olması gerekiyorsa ya da %99,99'a varan bir SLA'ya ihtiyacınız varsa. VPN'i şifreli bir yedek olarak tutun.