İki ofisi tek bir mantıksal ağ gibi davranır hale getirmek, uzaktan çalışmanın olağanlaştığı bu dönemde sık ihtiyaç duyulan bir özelliktir. Site-to-site (S2S) VPN tüneli, iki ayrı lokasyondaki MikroTik cihazları arasında şifreli, sürekli açık bir köprü kurar. Bu yazıda IPsec/IKEv2 üzerinden iki şube arasında nasıl tünel kurulduğunu, gerçek IP ve subnet’lerle adım adım anlatacağım. Hedefim, yazıyı takip edenin yaklaşık iki saat içinde test ortamında çalışan bir S2S tüneli kurabilmesidir.

Senaryomuz: Merkez Ofis + Şube

Anlatıyı somutlaştırmak için bir örnek senaryo kullanalım. Bir şirketin İstanbul merkez ofisi ve Ankara şubesi var. Her ikisinde de MikroTik router (RB5009) bulunuyor. Trafiği şu şekilde planlıyoruz:

• Merkez Ofis (İstanbul): LAN: 192.168.10.0/24, dış IP: 185.x.x.10 (static)
• Şube (Ankara): LAN: 192.168.20.0/24, dış IP: 78.x.x.20 (static)

İki LAN birbiriyle haberleşebilmeli. Merkez ofisteki sunuculara şubeden direkt erişim olmalı, şubedeki yazıcılara merkezden ulaşılabilmeli. Internet trafiği yine her iki uçtan kendi WAN’larından çıkmalı (full-tunnel değil, sadece şirket subnet’leri tünelden gitsin).

Önemli ön koşul: Her iki tarafın dış IP’si en azından bir tarafta statik olmalıdır. Eğer ikisi de dinamik IP kullanıyorsa, en az birinin MikroTik Cloud DDNS ile sabit isim alması gerekir.

IPsec/IKEv2 Neden Tercih Edilir?

S2S için diğer alternatifler de mevcuttur: PPTP (artık güvensiz), L2TP/IPsec (eskimiş ama hâlâ kullanılır), OpenVPN (yavaş), GRE (şifresiz, ek IPsec ile birleştirilebilir). IKEv2/IPsec’in tercih sebepleri:

• Modern AES-256, ChaCha20 gibi şifreleme algoritmalarını destekler
• NAT traversal native olarak vardır
• Yüksek throughput verir (RB5009 üzerinde 450-550 Mbps)
• MOBIKE ile bağlantı kesintilerinden hızlı toparlanır
• Microsoft, Apple, Cisco, Fortinet hepsiyle uyumlu

2024 sonrası WireGuard alternatif olarak da popülerleşiyor; ama enterprise dünyada IKEv2 hâlâ standart kabul edilen seçenek.

Adım 1: Merkez Ofiste IPsec Profile Tanımlama

Önce iki tarafta da kullanılacak şifreleme parametrelerini bir “profile” altında tanımlayalım. Hem hash hem encryption hem DH grup uyumlu olmalı.

Merkez ofiste Winbox’ı açıp IP > IPsec > Profiles > Add:

/ip ipsec profile
add name=ankara-profile hash-algorithm=sha256 enc-algorithm=aes-256 
  dh-group=modp2048 lifetime=8h nat-traversal=yes dpd-interval=2m

Açıklama:

• hash-algorithm=sha256 — yüksek güvenlik
• enc-algorithm=aes-256 — modern standart
• dh-group=modp2048 — orta-üst güvenlik (modp4096 daha güvenli ama ağır)
• lifetime=8h — IKE SA yeniden anahtarlama süresi
• nat-traversal=yes — NAT arkasında çalışabilsin
• dpd-interval=2m — Dead Peer Detection, ölü tünel tespiti

Adım 2: IPsec Peer Tanımlama

Şimdi şubenin dış IP’sini “peer” olarak tanımlayalım:

/ip ipsec peer
add name=ankara-peer address=78.x.x.20/32 profile=ankara-profile 
  exchange-mode=ike2

exchange-mode=ike2 kritik — IKEv2 kullanmamızı sağlar. IKEv1’e fallback olmasını istemiyoruz.

Adım 3: IPsec Identity Tanımlama

Identity, peer’ın kimliklendirilme yöntemini belirler. En basit yöntem PSK (Pre-Shared Key) kullanmaktır:

/ip ipsec identity
add peer=ankara-peer auth-method=pre-shared-key 
  secret="cokGuvenliBirAnahtarBuradaOlmali_2026!@#"

PSK uzun ve karmaşık olmalı. Üretim ortamında sertifika tabanlı kimliklendirme daha güvenlidir, ama bu yazıda PSK ile gidiyoruz.

Adım 4: IPsec Proposal Tanımlama

Proposal, IPsec Phase 2’nin (ESP) şifreleme parametrelerini tanımlar:

/ip ipsec proposal
add name=ankara-proposal auth-algorithms=sha256 
  enc-algorithms=aes-256-cbc pfs-group=modp2048 lifetime=1h

PFS (Perfect Forward Secrecy) önemli — bir anahtarın kırılması geriye dönük trafiği açığa çıkarmaz.

Adım 5: IPsec Policy Tanımlama

Policy, hangi trafiğin tünelden geçeceğini belirler. Merkez ofisten Ankara şubesi LAN’ına gidecek trafik:

/ip ipsec policy
add src-address=192.168.10.0/24 dst-address=192.168.20.0/24 
  peer=ankara-peer proposal=ankara-proposal tunnel=yes 
  sa-src-address=185.x.x.10 sa-dst-address=78.x.x.20

Burada tunnel=yes kritik. sa-src-address ve sa-dst-address tünelin iki ucu olan dış IP’lerdir.

Adım 6: NAT Bypass

Bu en sık unutulan adım. NAT, normalde tüm dışa giden trafiği maskelemeli; ama VPN trafiğini maskelemiyoruz, çünkü iki ofis aynı mantıksal ağda olmalı. Bu yüzden VPN subnet’lerine giden trafiği NAT’tan dışlayan bir kural ekliyoruz. Bu kuralı listenin EN ÜSTÜNE koyun:

/ip firewall nat
add chain=srcnat src-address=192.168.10.0/24 dst-address=192.168.20.0/24 
  action=accept place-before=0 comment="VPN: bypass NAT"

Adım 7: Firewall Forward İzni

VPN üzerinden gelen trafiğin LAN’a ulaşmasına izin verin:

/ip firewall filter
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 
  action=accept comment="VPN: Ankara to Istanbul"
add chain=forward src-address=192.168.10.0/24 dst-address=192.168.20.0/24 
  action=accept comment="VPN: Istanbul to Ankara"

Adım 8: Şube Tarafında Aynı Konfigürasyon (Aynalı)

Şimdi Ankara’da, kaynak ve hedefi takas ederek aynı konfigürasyonu tekrarlayın. Profile, peer, identity, proposal — aynı parametreler. Policy ise:

/ip ipsec policy
add src-address=192.168.20.0/24 dst-address=192.168.10.0/24 
  peer=istanbul-peer proposal=istanbul-proposal tunnel=yes 
  sa-src-address=78.x.x.20 sa-dst-address=185.x.x.10

NAT bypass:

/ip firewall nat
add chain=srcnat src-address=192.168.20.0/24 dst-address=192.168.10.0/24 
  action=accept place-before=0

Adım 9: Test ve Doğrulama

İki taraf yapılandırıldıktan sonra tünelin kurulup kurulmadığını kontrol edelim. Merkez ofiste:

/ip ipsec active-peers print

Burada Ankara peer’ı “established” durumda olmalı. Eğer kurulmamışsa:

/log print where topics~"ipsec"

komutuyla loglara bakın. En sık karşılaşılan hata mesajları:

• “phase1 negotiation failed”: Profile parametreleri (hash, enc, dh-group) iki tarafta farklı
• “invalid hash”: PSK uyuşmuyor
• “no matching policy”: Policy src/dst subnet’leri yanlış
• “peer not authenticated”: NAT-T sorunu, NAT-T destekleyen mod açın

Tünel established olduğunda şimdi ping testi yapın. Merkez ofisteki bir bilgisayardan:

ping 192.168.20.10

Cevap geliyorsa tünel başarılı!

Performans Optimizasyonu

RB5009 üzerinde IPsec’in hardware offloading özelliği var. Aşağıdaki komutla aktif edebilirsiniz:

/ip ipsec settings set accept-redirects=no max-buffers=10000

Bu, IPsec trafiğinin throughput’unu ciddi şekilde artırır. Bazı eski cihazlarda (RB951, RB2011) bu özellik yoktur, throughput 100-150 Mbps ile sınırlı kalır.

Yaygın Hatalar ve Çözümleri

Hata 1: NAT bypass kuralı diğer NAT kurallarının altına yerleşmiş. Çözüm: place-before=0 ile en üste alın.

Hata 2: Firewall filter forward chain’inde drop kuralı VPN kabul kuralının üstünde. Çözüm: kuralları manuel sıralayın.

Hata 3: Aynı subnet iki tarafta da kullanılıyor (örneğin ikisi de 192.168.1.0/24). Çözüm: bir tarafta subnet’i değiştirin. Aynı subnet’te S2S çalışmaz.

Hata 4: PSK’da Türkçe karakter kullanılmış. Çözüm: PSK’da sadece ASCII karakter kullanın.

Hata 5: Tünel kurulu ama trafik gitmiyor. Çözüm: firewall forward kurallarını ekleyin; tünel sadece şifreli paket geçirir, paketlerin LAN’a varması ayrı bir konudur.

Çoklu Şube Senaryosu (Hub-Spoke)

İki yerine 10 şubeyle çalışıyorsanız, her şubeyi merkez ofise tek tek tünelleyin. Bu hub-spoke topolojisidir. Her şubedeki konfigürasyon merkeze yönlendirilir; şubeler arası trafik merkez ofis üzerinden geçer.

Eğer şubeler birbiriyle de doğrudan haberleşmeli ise full-mesh topoloji gerekir. Bu, n×(n-1)/2 sayıda tünel demektir; 10 şubede 45 tünel. Bu noktada yönetim karmaşıklaşır ve genelde otomasyon (Ansible, Terraform) tercih edilir.

Monitoring ve Bakım

Tünel kurulduktan sonra unutmayın, izleyin. /ip ipsec active-peers komutu tünel sağlığını gösterir. Bunu bir Zabbix veya Prometheus exporter ile otomatik takibe alın.

Aşağıdaki gibi bir scheduler ekleyerek tünel kopmasında otomatik bildirim alabilirsiniz:

/system scheduler
add name=check-tunnel interval=5m 
  on-event=":if ([/ip ipsec active-peers print count-only where state=established] = 0) do={ 
    /tool e-mail send [email protected] subject="VPN DOWN" body="S2S tunnel offline" 
  }"

İleri Konu: GRE Tüneliyle Köprüleme

Sadece IPsec yeterli olmadığı bazı senaryolar var. Örneğin OSPF veya RIP gibi routing protokollerinin iki şube arasında çalışması gerekiyorsa, IPsec policy tabanlı bir tünel olduğu için L3 multicast trafiği iletmez. Çözüm GRE + IPsec birlikteliğidir.

GRE bir layer 3 tüneldir ve hem unicast hem multicast taşır. IPsec ile şifrelenen GRE tüneli, hem güvenli hem dinamik routing destekli olur. Kurulumu şöyledir:

/interface gre
add name=gre-ankara remote-address=78.x.x.20 local-address=185.x.x.10

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

/ip ipsec policy
add src-address=185.x.x.10/32 dst-address=78.x.x.20/32 
  protocol=gre peer=ankara-peer proposal=ankara-proposal tunnel=yes

Sonra GRE arayüzü üzerinden OSPF konuşturabilirsiniz. Bu yapı, çoklu şube WAN’ında dinamik routing isteyen senaryolarda hayat kurtarır.

Latency Etkisi ve Throughput

S2S tüneli üzerindeki ek latency genellikle 3-7 ms’dir. Bu, fiziksel mesafenin baz latency’sine eklenir. İstanbul-Ankara arası baz latency 12-15 ms, tünel ile 18-22 ms civarında oluşur. Throughput tarafında, AES-256 ile RB5009 yaklaşık 450-550 Mbps verir. AES-128 + GCM kullanıldığında bu 700 Mbps’ye çıkar.

Daha düşük segmentteki cihazlarda (RB951 gibi) hardware crypto offloading olmadığı için throughput 80-120 Mbps ile sınırlı kalır. Şube cihazını seçerken bu farkı göz önünde bulundurun.

Saha Vakası: 3 Şubeli Tekstil Firması

İzmir merkez + Bursa ve Denizli şubeli bir tekstil firmasında kurduğum hub-spoke S2S yapı 4 yıldır kesintisiz çalışıyor. Toplam 3 tünel, her biri RB4011 üzerinde, ortalama throughput 380 Mbps. Şubeler ortak ERP’ye sürekli bağlı, gece yedeklemeler otomatik merkeze geliyor.

Bu kurulumun en güzel yanı şu: dört yıl içinde sadece 2 bakım müdahalesi gerekti, ikisi de RouterOS güncelleme amacıyla. Tünelin kendisi sıfır arıza ile çalıştı. Doğru kurulmuş bir S2S VPN, sahanın en sessiz ama en kıymetli yapı taşıdır.

Backup ve Geri Yükleme Stratejisi

S2S yapılandırma karmaşıktır; küçük bir parametre değişikliği tüm tüneli koparır. Bu yüzden yedek alma disiplini şarttır. Tünel kurulduktan sonra her iki cihazda da export alın:

/export file=s2s-ankara-istanbul-prod
/system backup save name=s2s-prod-2026

Export dosyası okunabilir bir betiktir; geri yüklemek için /import s2s-ankara-istanbul-prod.rsc komutunu kullanırsınız. Binary backup ise yapılandırmanın tam halini geri getirir. İkisini de aynı yedek konumuna kopyalayın.

Profesyonel bir disipline geçmek için bu yedekleri her hafta otomatik olarak FTP/SFTP üzerinden dış bir konuma gönderebilirsiniz. Scheduler ile /tool fetch komutu kullanılarak ya da yine MikroTik’in kendi Backup-to-Cloud özelliği ile bu sağlanır.

Çoklu Kullanıcı Yetkilendirme

S2S’in standart yapısında iki uç tek bir PSK paylaşır. Ama yönetim erişimi farklı kullanıcılar arasında bölünmeli. MikroTik üzerinde /user menüsünden ayrı kullanıcılar tanımlayın: bir tane “tunnel-admin” sadece IPsec menülerine erişebilir, “router-admin” tam yönetici. Bu, bir IT teknisyeninin sadece VPN bakımı yapmasına izin verirken router’ın diğer kritik yapılandırmalarına dokunamamasını sağlar.

Group bazlı yetkilendirme için /user group menüsünde özel gruplar oluşturup policy alanlarını kısıtlayabilirsiniz. Bu küçük disiplin, ekibinizin büyüdüğü gün sürpriz hatalardan korur.

Sıkça Sorulan Sorular

İki tarafın da dinamik IP’si varsa S2S kurulabilir mi?

En az birinin sabit DNS adı olmalı. MikroTik Cloud DDNS ücretsiz bu işlevi sağlar; bir tarafı Cloud üzerinden adresleyip diğer taraftan o DNS adına peer tanımlayabilirsiniz.

S2S tüneli throughput’u nasıl artırılır?

Hardware offloading destekleyen cihaz (RB5009 ve üstü), AES-NI desteğin Intel CHR, ve düşük overhead’li algoritmalar (AES-GCM) seçimi throughput’u 2-3 katına çıkarır.

S2S üzerinden VoIP geçirmek mantıklı mı?

Evet, ama jitter’a dikkat edin. Hatta varsa hardware QoS ile sesli trafiği önceliklendirin. Tünel jitter’i 20 ms’in altında tutulmalı.

İki MikroTik arasında Cisco/Fortinet ile S2S kurabilir miyim?

Evet, IKEv2 standart bir protokoldür. Parametreler her iki tarafta uyumlu olduğu sürece marka karması bir sorun yaratmaz.

PSK yerine sertifika kullanmanın avantajı nedir?

Sertifika tek seferlik bir kimliklendirme materyali, kolayca yenilenebilir veya iptal edilebilir. Çok sayıda peer varsa sertifika tabanlı yönetim daha pratiktir.

Sonuç

Site-to-site VPN, modern bir şirket ağ altyapısının vazgeçilmez bileşenlerinden biridir. MikroTik üzerinde IKEv2/IPsec ile kurmak, bir kez doğru yapıldığında yıllarca sessiz çalışan bir yapı sunar. Bu yazıdaki adımları test ortamınızda mutlaka uygulayın; üretime almadan önce trafiğin gerçekten beklediğiniz subnet’ler arasında aktığını doğrulayın. Bir sonraki adım, bu yapıyı izleme ve otomasyonla zenginleştirmektir; sonrasında kurduğunuz yapı, mekânların fiziksel ayrılığını hissettirmeden çalışan tek bir ağa dönüşür. Saha tecrübemden defalarca gözlemledim ki, başarılı kurulumların ortak özelliği ilk gün dikkatle test edilmiş olmaları ve bir bakım rutinine bağlanmış olmalarıdır.

Bir başka pratik öneri olarak, ilk kurulumda mutlaka bir bilgisayar ile iperf3 testi yapın. Tünel kurulu olsa da performans beklediğiniz gibi olmayabilir; iperf3 size gerçek throughput’u gösterir. Aldığınız rakam donanım kapasitesinin %60-80’i ise sağlıklı bir kurulumunuz var demektir. Daha düşükse şifreleme parametrelerini gözden geçirmeniz gerekebilir. Düzenli izlemenin yanına bu tek seferlik benchmark testi eklenirse, gerçek bir sorun yaşandığında elinizde karşılaştırma noktası olur. Bu küçük disiplin, ileride hangi değişikliğin performansa nasıl etkisi olduğunu nesnel olarak ölçmenize imkan tanır.

İlgili Yazılar

Aşağıdaki içerikler, bu yazıdaki konuların farklı yönlerini ele alıyor:

• MikroTik WireGuard VPN Kurulumu: Sunucu + Mobil/Laptop İstemci Pratik Rehberi
• MikroTik ile Uzak Erişim: VPN, Port Forward ve Cloud Yöntemleri Hangi Senaryoda?
• MikroTik VPN Türleri Karşılaştırması: PPTP, L2TP, SSTP, OpenVPN, IKEv2, WireGuard

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)
• MikroTik Resmi Dökümantasyon (RouterOS Wiki)
• MikroTik Resmi Forumu