Site-to-Site VPN — yani lokasyonlar arası kalıcı tünel — bir ağ mühendisinin envanterindeki en eski ama hala en yanlış anlaşılan araçlardandır. “WireGuard kurdum, çalıştı, bitti” demek kolay; ama 12 lokasyonlu bir kurumsal müşterinin Gediz, Tekirdağ, Ankara, Berlin ofisleri arasında günde 4TB veri akıyorsa, “çalıştı” yetmez — mimari soruları cevaplamış olmanız gerekir. Hangi topoloji? Hub-spoke mi mesh mi partial mesh mi? Hangi protokol — IPsec, WireGuard, GRE, OpenVPN? MTU planı nedir, NAT-T traversal kötü davranıyor mu, asimetrik yönlendirme tuzakları nerede? Bu yazı, kurulum yapmaz — kurulum tutorial’larına sosyal medya doludur — bunun yerine sahada 12 yıl boyunca öğrendiğim kavramsal derinliği aktarır. Site-to-Site VPN tasarlarken doğru soruları sormanıza yardım eder; cevapları kendi kontekstinize göre vermenizi sağlar.

Bir VPN’in Kategorik Tanımı: Aslında “VPN” Diye Tek Bir Şey Yok

VPN terimi şemsiye bir kavramdır. Altında en az dört farklı dağıtım modeli yer alır:

• Remote Access VPN: Tek bir kullanıcı dizüstüyle merkezi ofise bağlanır. WireGuard mobile, OpenVPN client, Cisco AnyConnect bu kategoridedir.
• Site-to-Site VPN: İki veya daha fazla LAN, bir tünel üzerinden birbirine kalıcı olarak bağlanır. Bu yazının odağı.
• SD-WAN Overlay VPN: Dinamik, policy-driven, çoklu tünel — bir vendor product seti (Cisco vManage, Fortinet SD-WAN).
• Provider-managed VPN (MPLS L3VPN): Servis sağlayıcı omurgasında yönetilir; müşteri tünel kurmaz.

Site-to-Site, bu dördünün arasındaki en “klasik” model. Ama içinde gizli karmaşıklıklar barındırır.

Topoloji Kararı: Hub-Spoke vs Full Mesh vs Partial Mesh

Hub-Spoke (Yıldız Topolojisi)

Tüm uzak lokasyonlar (spoke) merkezi bir noktaya (hub) bağlanır. Lokasyonlar arası trafik hub üzerinden geçer.

Artılar: Konfigürasyon basit, merkezi yönetim kolay, yeni lokasyon eklemek hızlı (sadece hub-spoke tünel).

Eksiler: Hub tek nokta arızadır; hub çöktüğünde tüm ağ kopar. Lokasyon-arası latency hub üzerinden gider (Tekirdağ-İzmir trafiği İstanbul’a uğrar). Hub bant genişliği sınırlı kalırsa darboğaz olur.

Ne zaman kullanılır? 5-30 lokasyonlu, merkezi BT yönetimi olan, lokasyon-arası trafik az olan KOBİ/şube ağları.

Full Mesh

Her lokasyon her diğer lokasyonla doğrudan tünel kurar. N lokasyon için N*(N-1)/2 tünel gerekir.

Artılar: Lokasyonlar arası en kısa yol, tek nokta arızası yok, gerçek redundans.

Eksiler: Tünel sayısı patlama: 10 lokasyon için 45 tünel, 20 lokasyon için 190 tünel. Konfigürasyon ve operasyon maliyeti ağır. Her lokasyona public IP veya STUN benzeri NAT traversal çözümü şart.

Ne zaman? Lokasyonlar arası ağır trafik olan, tier-3 işletmeler. Örneğin haber ajansları, finans firmaları.

Partial Mesh (Hibrit)

Hub-spoke iskeleti üstüne, en sık konuşan lokasyonlar arası doğrudan tünel.

Artılar: Hub-spoke basitliği ile mesh performansının dengesi.

Eksiler: “Hangi lokasyonlar arasında direkt tünel?” sorusu süreklı re-evaluation ister.

Ne zaman? 8-15 lokasyonlu, lokasyon-arası trafik desenleri belirgin olan firmalar. Saha pratiğimin en sık başvurduğu model.

DMVPN ve Modern Alternatifler

Cisco’nun DMVPN’i (Dynamic Multipoint VPN), hub-spoke + dinamik spoke-to-spoke kombinasyonudur. MikroTik tarafında doğrudan eşdeğeri yok; ancak WireGuard mesh + dinamik routing protokolü (OSPF over WireGuard) ile benzer davranış elde edilebilir. 2024 sonu itibarıyla Tailscale, NetMaker gibi modern overlay araçları MikroTik üzerinde container olarak çalışıp DMVPN benzeri “akıllı mesh” sağlıyor.

Protokol Karşılaştırması: Hangi Tüneli Niye Seçmeli?

IPsec — Olgun, Standartlaşmış, Karmaşık

IPsec aslında bir protokol değil, bir framework: IKEv1/IKEv2 (key exchange), ESP (encapsulation), AH (authentication), DH gruplar, transform set’ler. Bu modülerlik bir avantaj ama aynı zamanda yapılandırma yüzeyini genişletir.

Artılar: Vendor-neutral (Cisco-MikroTik-Fortinet birlikte çalışır), audit-friendly (PCI-DSS, ISO27001 raporlarında “standard”), hardware acceleration yaygın (CCR2004+ AES-GCM 2.4 Gbps).

Eksiler: Konfigürasyon karmaşık, debug zor, NAT-T olmadan NAT arkasında çalışmaz, MTU sorunları yaygın.

İdeal kullanım: Vendor-mixed kurumsal site-to-site, denetlenebilirlik gereksinimi.

WireGuard — Modern, Hızlı, Sade

3000 satır kodla yazılmış, kernel-level, sadece UDP. Curve25519 + ChaCha20 + Poly1305 sabit kripto seti — IPsec’in onlarca transform kombinasyonu yerine tek bir doğru kombinasyon.

Artılar: Sade konfigürasyon (her peer için 5-6 satır), hızlı handshake (4 paket), roam-friendly (mobile için ideal), NAT’ı transparently geçer.

Eksiler: Henüz tüm vendor’lar desteklemiyor (eski Cisco IOS yok), audit yazılı dokümentasyonu az, hardware crypto yaygın değil.

İdeal kullanım: Yeni greenfield projeler, mobile remote access, hub-spoke hibrit.

GRE — Tüneller Üzerinde Tünel

GRE (Generic Routing Encapsulation) kriptosuz bir L3 tüneldir; kendi başına güvensiz, ama IPsec içine sarıldığında (GRE-over-IPsec) bambaşka bir oyun açar: dinamik routing protokolleri (OSPF, EIGRP) tünel üzerinden taşınabilir, multicast geçebilir.

Artılar: Routing protokol desteği, multicast geçirme, IP-agnostic (IPv4-IPv6 mixing).

Eksiler: Tek başına şifresiz, encapsulation overhead +24 byte (MTU planlamayı zorlar).

İdeal kullanım: Dinamik routing isteyen branch network’ler, multicast video dağıtımı.

OpenVPN — Esnek ama Yavaş

Userspace SSL/TLS bazlı VPN. TCP veya UDP üzerinden çalışabilir.

Artılar: TCP/443 üzerinden TLS gibi davranır; corporate firewall’ları geçer. Sertifika tabanlı auth olgun.

Eksiler: Userspace nedeniyle yavaş (CCR2004’te 240 Mbps tavan), context-switch overhead.

İdeal kullanım: Restrictive firewall arkasında acil bağlantı, eski legacy sistemler.

Performans Karşılaştırma Tablosu

MTU Planlama: VPN’in Sessiz Katili

Site-to-Site VPN sorunlarının yaklaşık %35’i MTU/MSS yanlış ayarından doğar. Sorun şöyle gelişir: Ethernet üzerinde standart MTU 1500 byte’tır. IPsec/GRE/WireGuard her biri encapsulation overhead ekler:

• IPsec ESP+SHA256+AES: +57 byte (1443 effective MTU)
• IPsec ESP+SHA1+AES (klasik): +52 byte (1448 effective)
• GRE: +24 byte (1476 effective)
• GRE+IPsec: +73 byte (1427 effective)
• WireGuard: +60 byte (1440 effective)
• OpenVPN UDP: +69 byte (1431 effective)

Eğer iç tarafta 1500 byte paketler tünele girerse, fragmentation gerekir; eğer DF (Don’t Fragment) bit’i set ise (TCP genelde set eder), paket düşer ve “PMTU Discovery” devreye girer. PMTU mesajları sıklıkla bloklanır (firewall ICMP type 3 code 4 düşürür); sonuç: sessiz paket kaybı, tüneller “çalışır görünür” ama büyük dosyalar transfer olmaz, video konferanslar kekelir.

Pratik Çözüm: MSS Clamping

/ip firewall mangle
add chain=forward action=change-mss new-mss=1380 
    protocol=tcp tcp-flags=syn tcp-mss=!0-1380 
    out-interface=wg-vpn comment="VPN MSS clamp"

Bu kural, TCP SYN paketinde MSS değerini 1380’e zorlar. Karşı taraf 1380 byte segmentlerle gönderir, fragmentation gerekmez. Sahada her site-to-site VPN kurulumunda standart olarak eklediğim ilk kural.

NAT-T (NAT Traversal): NAT Arkasında IPsec

Klasik IPsec, ESP protocol number 50 ile çalışır. NAT cihazları port translate edebilir ama “protokol” translate edemez; ESP NAT arkasında düşer. NAT-T çözümü: ESP paketini UDP 4500 içine sarmak. IKEv2 handshake sırasında her iki taraf NAT-T destekliyorsa otomatik geçilir.

Sahada Karşılaşılan Tuzaklar

• Bazı eski Cisco IOS sürümlerinde NAT-T sadece passive modda; aktif başlatılması gerek.
• Çift NAT (CGNAT arkasındaki müşteri + ofis NAT) NAT-T’yi bozar; STUN benzeri keep-alive şart.
• Firewall UDP/4500’ü hem inbound hem outbound izin vermeli.

WireGuard’ın NAT Avantajı

WireGuard UDP bazlı ve stateless. Periyodik keep-alive paketleriyle (varsayılan 25 sn) NAT mapping’i canlı tutar. NAT-T’ye benzer ek mekanizma gerekmez. Bu, mobil ve NAT arkasındaki şubeler için onu favori yapar.

Asimetrik Yönlendirme Tuzakları

Multi-WAN ve multi-tunnel ortamlarda asimetrik routing en sinsi sorundur. Senaryo: İstanbul ofisi iki ISP’ye sahip (WAN1, WAN2). VPN tüneli WAN1 üzerinden Ankara’ya gidiyor. Ama Ankara’dan dönen trafik ECMP nedeniyle WAN2 üzerinden ulaşıyor. Stateful firewall WAN2’de “bu paket için bağlantı kaydım yok” diyerek drop ediyor.

Çözüm Önerileri

1. Route mark + policy-based routing: VPN trafiğini mangle ile işaretle, sadece WAN1’den çıkmasını zorla.
2. Connection tracking sync: İki WAN router’ı arasında conntrackd benzeri sync (Linux native, RouterOS’ta yok; CHR ile çözülebilir).
3. Tek tarafta NAT: Karmaşık ama bazen tek çözüm.

Routing Protokolü Tüneller Üzerinde

20+ lokasyonlu bir ağda statik route ile route tablolarını yönetmek bir kabustur. Dinamik routing protokolü tünel üzerinden çalıştırmak şart:

OSPF over GRE/IPsec

GRE multicast taşır, OSPF multicast (224.0.0.5/6) kullanır → ideal kombinasyon. Tipik konfigürasyon:

/interface gre
add name=gre-ankara remote-address=ANKARA_PUBLIC 
    local-address=ISTANBUL_PUBLIC ipsec-secret="SECRET"

/ip address
add address=10.99.0.1/30 interface=gre-ankara

/routing ospf instance
add name=corporate
/routing ospf area
add instance=corporate name=backbone area-id=0.0.0.0
/routing ospf interface-template
add interfaces=gre-ankara area=backbone network-type=point-to-point

OSPF her tünelin durumunu canlı izler; tünel düşerse alternatif route otomatik devreye girer. Saha pratiği: tünel adjacency süresi 5 sn (hello-interval=1, dead-interval=4), tipik failover 5-7 sn.

BGP over Tunnel

50+ prefix değişen büyük ağlarda BGP daha esnek; route-map ile granular politika. Multi-tenant senaryolarda MP-BGP ile address family ayrımı (örneğin VRF-aware tunnel).

Yüksek Erişilebilirlik (HA) Tasarım Kalıpları

Hub Çoklama (Active-Active Hub)

İki ayrı veri merkezinde iki hub. Her spoke iki hub’a da tünel kurar; OSPF/BGP üzerinden best-path otomatik seçilir. Bir hub çöktüğünde 5-10 sn içinde tüm trafik diğer hub’a geçer.

VRRP’li Tek Hub

Tek lokasyonda iki router VRRP master/backup. Master’da tünel terminate olur; failover sırasında tünel yeniden kurulur (15-30 sn kesinti). Daha basit ama failover yavaş.

Saha Önerisi

5+ spoke olan müşterilerde Hub Çoklama’yı şiddetle öneririm. Tek hub mimari “ucuz” görünür ama dr scenario’ya hazırlıksızdır. 2023’te bir müşteride hub veri merkezinin yedeği yoktu; data center power outage’inde 6 saat 11 şube ağı kesik kaldı.

5651 ve KVKK: Türkiye Bağlamında VPN

VPN üzerinden geçen trafik, yine 5651 kapsamında loglama yükümlülüğüne tabidir. Eğer tünel üzerinden hotspot kullanıcısı internete çıkıyorsa, hangi tünelin hangi kullanıcıya açıldığı 2 yıl saklanmalıdır. KVKK açısından ise VPN paketlerinin payload’u kişisel veri içeriyorsa (örneğin uzak ofisten merkez İK sistemine iletilen personel verisi) end-to-end şifrelemenin yeterli olmadığı, in-transit ve at-rest birlikte korunması gerektiği unutulmamalı.

Saha Vaka: 12 Lokasyonlu Tekstil Firmasında Partial Mesh Tasarım

2024’te bir tekstil grubu (12 lokasyon: 1 merkez + 8 mağaza + 3 üretim tesisi) site-to-site VPN re-tasarımı istedi. Mevcut yapı: hub-spoke OpenVPN üzerinden, hub İstanbul. Sorunlar: mağaza-üretim arası trafik (sipariş→üretim emri) İstanbul’a uğruyor, latency 80ms; OpenVPN throughput hub’da 250 Mbps’a sıkıştı.

Yeni Tasarım

• Çekirdek: 2 hub (İstanbul + Bursa), her ikisi de WireGuard concentrator.
• 8 mağaza: Hub-spoke, her ikisine de tünel.
• 3 üretim tesisi: Birbirleriyle direkt mesh (üretim emri-sipariş trafiği), ayrıca hub’lara da bağlı.
• Routing: OSPF over WireGuard, area 0 her yerde.
• Failover: Hub düşerse spokes diğer hub’a otomatik geçer.

Sonuç

• Mağaza-üretim latency 80ms → 14ms.
• Toplam tünel sayısı 12 (hub-spoke) + 3 (mesh) = 15. Full mesh olsaydı 66 tünel.
• Throughput sınırı kaldırıldı; tek tünel 800 Mbps yapıyor (WireGuard).
• Aylık downtime 4 saatten 8 dakikaya düştü.

SSS: Site-to-Site VPN Hakkında Sıkça Sorulanlar

Hangi protokol “en güvenli”dir?

Doğru konfigüre edildiğinde IPsec ve WireGuard eşit güvenliktedir. Konfigürasyon hataları farkı yaratır; default WireGuard daha “yanlış yapmaya az müsait”tir.

Multi-cloud arası VPN kuruyorum, hangi protokol?

AWS/Azure/GCP’nin VPN gateway’leri IPsec konuşur. Multi-cloud için IPsec standarttır; WireGuard daha yeni destekleniyor.

MTU 1380 her zaman doğru mu?

Hayır. WireGuard için 1420, IPsec için 1380, GRE+IPsec için 1360 başlangıç değeridir. Path MTU discovery testi şart.

VPN üzerinden VoIP nasıl?

UDP-bazlı (IPsec ESP, WireGuard) tünel önerilir. TCP üzerinde (OpenVPN TCP) VoIP jitter doğurur.

Mesh tünel sayısı kontrol edilemez büyürse?

O zaman SD-WAN veya overlay (Tailscale, NetMaker) düşünme zamanı. Manuel mesh 15-20 tünelin üstünde sürdürülebilir değil.

VPN tünel kapanırsa hangi alarm sistemi?

RouterOS scheduler ile /ping kontrolü, başarısızsa Telegram/Email push. Daha gelişmiş: Prometheus blackbox exporter + Alertmanager.

Anahtar Yönetimi ve Sertifika Yaşam Döngüsü

VPN’in unutulan ama yaşamsal bir boyutu anahtar/sertifika yaşam döngüsüdür. IPsec PSK (pre-shared key) ile başlanır; “secret” kelimesi sözlükten kelime ise 1 saatte kırılır. Sahada bir aile şirketine ait VPN’in IPsec PSK’sının “izmir2018” olduğunu görmüştüm — 8 saniye bir wordlist saldırısıyla kırılırdı. Pratik öneriler:

• IPsec PSK için minimum 32 karakter, alfanumerik + sembol; password manager ile saklayın.
• Sertifika tabanlı IKEv2 mümkünse PSK’dan tercih edilmeli. CA olarak küçük çaplı offline OpenSSL, büyük çaplı için pfSense veya Cisco PKI server.
• Sertifika TTL’si maksimum 13 ay; otomatik yenileme cron + Ansible ile.
• WireGuard private key’leri Hashicorp Vault veya Bitwarden secret rotation ile en az yıllık rotasyon.
• İhraç eden cihaz konfigürasyon yedeklerinde key clear-text görünmemeli; export hide-sensitive kullan.

Performans İzleme: VPN Tünelin Sağlığını Saatlik Bilmek

Bir VPN tüneli “up” demek “sağlıklı” demek değildir. Üç metriği eş zamanlı izlemek şart:

1. Latency: Tünelin iki ucu arası ping. Baseline’ın 1.5 katına çıkarsa alarm.
2. Packet loss: Her 5 dakikada bir 100 paketlik ping testi; %0.5 üstü kötü işaret.
3. Jitter: Latency varyansı; 30ms üstü ses/video uygulamalarını bozar.

Bunlar için MikroTik’in /tool ping komutunu scheduler ile her dakika koşturup sonuçları syslog’a yazdırıyoruz; Grafana Loki bu syslog’u alıyor ve dashboard’da görselleştiriyor. SLA raporlarımız bu veriyle hazırlanıyor; “tünel %99.8 uptime” demek müşteriye iyi geliyor ama daha önemlisi anomali görüldüğünde proactive müdahale şansı veriyor.

Sonuç: VPN Tasarımı Mimari Bir Karardır

Site-to-Site VPN, “kurdum çalıştı” düzeyinde kalırsa 8 ay sonra “neden yavaş?” diye gelinir. Doğru topoloji, doğru protokol, doğru MTU ve doğru failover stratejisi seçimi — bunlar mimari kararlar ve her birinin saha gerçekliğine göre cevabı farklıdır. Bu yazı bir tutorial değil; sizin tasarım kararlarınızda doğru soruları sormanız için bir checklist. Sıradaki VPN projenizden önce kağıdı önünüze çekin: lokasyon sayım kaç, ortalama trafik deseni nasıl, hangi vendor karışımı söz konusu, audit gereksinimim var mı, failover toleransım 30sn mi 5sn mi? Cevaplar topoloji ve protokol tercihinizi şekillendirecek. İyi tasarlanmış VPN, sadece “çalışan” değil, “10 yıl sonra hala doğru” olandır.

Konuyla İlgili Diğer Rehberler

Bu konuyla doğrudan ilişkili pratik rehberlerimiz:

1. MikroTik WireGuard VPN Kurulumu: Sunucu + Mobil/Laptop İstemci Pratik Rehberi
2. MikroTik CCR Serisi 2026: Hangi ISP İçin Hangi Model?
3. MikroTik vs Cisco: KOBİ İçin 5 Yıllık TCO Karar Rehberi
4. MikroTik İlk Yapılandırma Rehberi: Kutudan Çıktığı Andan İlk Bağlantıya

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• WireGuard Resmi Sitesi
• IETF IKEv2 RFC 7296
• NIST VPN Guideline (SP 800-77)
• Wikipedia: Network Address Translation
• Wikipedia: OSI Model