SD-WAN Nedir? Nasıl Çalışır, MPLS’ten Farkı Nedir ve Hub Nerede Olmalı?

Çok şubeli bir kurumda “bulut uygulaması yavaş” şikâyetinin kaynağı her zaman uygulama değildir. Trafik şubeden önce genel merkeze, oradaki güvenlik katmanına ve ardından internete gidiyorsa kullanıcıya yakın bir bulut hizmetine bile dolambaçlı bir yoldan ulaşılabilir. Ancak ağ yolunu ölçmeden bütün gecikmeyi WAN bağlantısına bağlamak da doğru değildir; yerel ağ, DNS, kimlik doğrulama ve uygulama tarafı aynı incelemenin parçalarıdır.

SD-WAN, şube, veri merkezi ve bulut bağlantılarını yazılım tabanlı politikalarla yöneten; uygulama ihtiyacı ve ölçülen yol kalitesine göre trafik için uygun erişim yolunu seçebilen bir geniş alan ağı yaklaşımıdır. MPLS veya internet hattının yerine geçen yeni bir devre değildir; bu bağlantıları birlikte kullanabilir.

Bu rehber; BT direktörleri, altyapı ve ağ yöneticileri, güvenlik ekipleri ve kurumsal mimarlar için SD-WAN’ın çalışma mantığını, MPLS ve VPN’den farkını, sınırlarını ve geçiş adımlarını ele alır. Özellikle bir tasarım kararına odaklanır: Merkezi erişim gereken trafik nerede toplanmalı, hangi trafik yerelden çıkmalı ve bu yapı bir arızada nasıl davranmalı?

Hub’ın bir ofis sistem odasında, colocation tesisinde, bulutta veya yönetilen bir bağlantı noktasında konumlandırılması; bağlantı seçeneklerini ve işletim modelini değiştirir. Bununla birlikte bütün SD-WAN mimarilerinde tek bir hub zorunlu değildir. Aşağıdaki politika, test ve maliyet tabloları karar vermeyi destekleyen örneklerdir; belirli bir ürünün yapılandırması, hizmet taahhüdü veya gerçek müşteri sonucu değildir.

SD-WAN nedir?

SD-WAN’ın açılımı Software-Defined Wide Area Network, Türkçesi Yazılım Tanımlı Geniş Alan Ağıdır. Yaklaşım, taşıma bağlantılarını uygulama politikalarından ayırır. Kurum; farklı lokasyonlarda MPLS tabanlı IP VPN, fiber internet, xDSL veya 4G/5G erişim kullanırken hangi uygulamanın hangi koşulda hangi yoldan ilerleyeceğini ortak bir politika modeliyle tanımlayabilir. ^[1]

Örneğin bir sipariş uygulaması için öncelik, işlem sırasında bağlantının kararlı kalması olabilir. Görüntülü toplantı için gecikme değişkenliği ve paket kaybı daha belirgin hale gelebilir. Gece yapılan veri aktarımı ise kalan kapasiteyi kullanacak şekilde planlanabilir. Tasarımın amacı bütün uygulamalara aynı yolu dayatmak değil, iş ihtiyacını ağ davranışına çevirmektir.

“Yazılım tanımlı” ifadesi donanım gereksiniminin ortadan kalktığı anlamına gelmez. Şubede veya bulutta trafiği işleyen fiziksel ya da sanal uçlar, bağlantı hizmetleri ve bir yönetim mekanizması bulunur. Tek bağlantı üzerinde de merkezi yönetim veya segmentasyon faydası sağlanabilir; fakat alternatif yol yoksa yol değiştirerek yedeklilik sağlamak mümkün değildir.

SD-WAN, genel SDN yaklaşımının WAN bağlamındaki uygulamalarından biridir; bütün veri merkezi ağını otomatik olarak yeniden tasarlamaz. Hibrit bulut yönetimi açısından bağlantı katmanını destekler, uygulama bağımlılıkları ve veri yerleşimi kararlarının yerine geçmez.

Geleneksel WAN hangi durumlarda zorlanır?

Şubelerin ağırlıklı olarak merkezdeki uygulamalara eriştiği bir ağda merkezi çıkış modeli uygun olabilir. Ancak SaaS ve farklı bulut ortamları devreye girdiğinde aynı modelin her trafik için kullanılması ek mesafe ve işlem yükü yaratabilir. Microsoft 365’in bağlantı ilkeleri de gereksiz ağ dolanmalarının azaltılmasını ve uygun yerel çıkışın değerlendirilmesini önerir. Bu, bütün güvenlik denetimlerinin kapatılması anlamına gelmez.

Bulut trafiğinin merkeze dolanması

Backhauling, şube trafiğinin asıl hedefe gitmeden önce merkezi bir noktaya taşınmasıdır. Sorun “merkez” bulunması değil, merkezi geçişin uygulama açısından gereksiz olup olmadığının değerlendirilmemesidir. Veri merkezindeki ERP’ye erişim ile internet üzerinden kullanılan bir iş birliği uygulamasının en uygun yolu aynı olmayabilir.

Bağlantı tedariki ve değişikliklerin yönetimi

Yeni lokasyon açılırken hat teslimi, yerel erişim kalitesi, güvenlik cihazı kurulumu ve politika onayları birlikte planlanmalıdır. SD-WAN, mevcut bir bağlantı üzerinden devreye almayı kolaylaştırabilir; fakat henüz teslim edilmemiş bir fiber hattı veya kapsama bulunmayan mobil erişimi yaratmaz. İnternet ile özel devrelerin süre ve maliyetleri, lokasyona ve sözleşmeye göre karşılaştırılmalıdır.

Yedek hat bulunmasına rağmen sürekliliğin doğrulanmaması

İkinci hattın satın alınması, başarısızlık senaryosunun çözüldüğü anlamına gelmez. Yedek hattın kapasitesi, erişebildiği hedefler, güvenlik politikası ve arıza anındaki uygulama davranışı ayrıca kontrol edilmelidir. İki sözleşmenin aynı bina girişine veya aynı üst sağlayıcıya dayanması ihtimalini sorgulayın. Geleneksel ağlar da dinamik yönlendirme ve otomasyon kullanabilir; SD-WAN karşılaştırmasını “eski ağ akılsız, yeni ağ akıllı” basitliğine indirmeyin.

SD-WAN nasıl çalışır?

SD-WAN, mevcut erişim ağlarının üzerinde mantıksal bağlantılar oluşturur; uç cihazlar trafiği sınıflandırır ve izin verilen yollar arasından politika doğrultusunda seçim yapar. Yönetimin merkezileşmesi, kullanıcı paketlerinin mutlaka yönetim sunucusundan geçmesini gerektirmez. Cisco’nun mimarisinde de kontrol bileşenleri rota ve politika bilgisini dağıtırken veri trafiğini edge cihazları taşır; farklı üreticiler işlevleri farklı bileşenlerde birleştirebilir.

Underlay’i yalnızca “fiziksel kablo” olarak düşünmemek gerekir: operatör IP hizmeti de bu katmanın parçası olabilir. Overlay ise tek başına bir güvenlik garantisi değildir; kullanılan tünelin şifreleme ve kimlik doğrulama özellikleri doğrulanmalıdır.

Uygulama farkındalıklı yönlendirme nasıl karar verir?

Uygulama farkındalıklı yönlendirme, trafiği tanımlayıp gecikme, paket kaybı ve jitter gibi ölçümlerle politika koşullarını karşılaştırır. Yol seçimi, yalnızca en düşük gecikmeyi aramak değildir: izin verilen bağlantılar, maliyet tercihi, güvenlik gereksinimi ve uygun yol bulunmadığındaki davranış da karara katılır. Ürünün “SLA sınıfı” dediği eşik seti, operatörle imzalanmış sözleşmesel SLA ile aynı şey değildir. ^[4]

Önce ölçümün nereden nereye yapıldığını kaydedin. Şube ile hub arasındaki test, hub’dan SaaS uygulamasına giden bölümü otomatik olarak kapsamaz. Gidiş-dönüş süresi (RTT), tek yön gecikme ve jitter ölçümlerini birbirinin yerine kullanmayın. Aynı panelde yeşil görünen iki yol, farklı hedeflere veya farklı ölçüm dönemlerine göre değerlendirilmiş olabilir.

Trafik sınıflandırması için de varsayım değil kanıt gerekir. Uygulama imzası, hedef adres, port veya işaretleme kullanılıyorsa gerçek akışın beklenen sınıfa düştüğünü pilotta doğrulayın. Şifreli ve değişken uç noktalara sahip uygulamalar için tanıma kapsamını; tanınamayan trafik için varsayılan politikayı ayrıca belirleyin.

Hat kopması ile performans bozulması aynı olay değildir

Bir devrenin tamamen erişilemez olması ile paket kaybının yavaşça artması farklı algılama mekanizmaları gerektirebilir. Ölçüm sıklığı, ortalama alınan dönem, ardışık başarısızlık sayısı ve geri dönüşte bekleme süresi; tepki hızı ile kararlılık arasında denge kurar. Üretici dokümantasyonundaki gelişmiş yönlendirme seçenekleri de bu ayrımı gösterir; bütün ürünler için geçerli tek bir failover süresi yoktur.

Politikaya iki karar daha ekleyin: Bütün yollar kalite hedefinin altına düşerse trafik en iyi kalan yoldan mı ilerleyecek, yoksa belirli akışlar durdurulacak mı? Eski hat düzeldiğinde hemen geri mi dönülecek, kararlılığı doğrulanana kadar beklenecek mi? Bu kararlar, güvenlik ve uygulama sahipleri tarafından onaylanmalıdır.

SD-WAN ile MPLS arasındaki fark nedir?

MPLS bir etiket anahtarlama mimarisidir; SD-WAN ise bağlantıları politika ve uygulama ihtiyacına göre kullanan bir yaklaşım. Kurumsal satın alma görüşmelerinde “MPLS hattı” denildiğinde çoğunlukla operatörün sunduğu MPLS tabanlı IP VPN hizmeti kastedilir. Bu yüzden doğru karşılaştırma “hangi teknoloji diğerini yok eder?” değil, “hangi taşıma hizmetlerini hangi politikayla kullanacağız?” sorusudur.

MPLS tabanlı IP VPN’in mantıksal olarak ayrılmış olması, verinin kriptografik olarak şifrelendiği anlamına gelmez; RFC 4364 bu ayrımı açıkça yapar. Benzer biçimde internet bağlantısında SLA bulunması da bütün internet üzerindeki her hedefe uçtan uca performans garantisi verildiği anlamına gelmez. Sözleşmenin ölçüm noktaları ve istisnaları incelenmelidir.

SD-WAN projesi MPLS’in kaldırılmasını zorunlu kılmaz. Bir lokasyonda MPLS’i korumak, diğerinde iki internet bağlantısı kullanmak, başka bir yerde mobil erişimi yalnızca kritik işlemler için yedeklemek mümkündür. Karar, teknolojinin adı üzerinden değil; uygulama gereksinimi, gerçek test sonucu ve toplam maliyet üzerinden verilmelidir.

SD-WAN ile klasik VPN arasındaki fark nedir?

VPN güvenli veya mantıksal olarak özel bağlantıyı; SD-WAN ise bu bağlantıların uygulama politikalarıyla ölçekli biçimde yönetilmesini ele alır. Buradaki karşılaştırma, lokasyonlar arası site-to-site VPN üzerinedir. Uzaktan çalışan kullanıcının VPN veya ZTNA erişimi ayrı bir tasarım konusudur.

“VPN statiktir, SD-WAN dinamiktir” genellemesi eksiktir. VPN tünelleri üzerinde BGP gibi dinamik yönlendirme ve yedek tünel mekanizmaları çalışabilir; AWS Site-to-Site VPN dokümantasyonu bunun açık bir örneğidir. SD-WAN’ın farkı, uygulama sınıflandırması, yol kalitesi, merkezi politika ve yaşam döngüsü yönetimini bir arada sunabilmesidir.

Satın alma değerlendirmesinde “VPN destekliyor mu?” sorusuyla yetinmeyin. Farklı tüneller arasında politika nasıl korunuyor, mevcut oturumlar nasıl etkileniyor, uygulama trafiği hangi ölçümlerle yönlendiriliyor ve değişiklikler nasıl denetleniyor? Kurumsal fark bu soruların cevaplarında ortaya çıkar.

SD-WAN’ın faydaları ve sınırları nelerdir?

SD-WAN’ın değeri daha fazla hat satın almakla değil, mevcut bağlantıları iş ihtiyacıyla ilişkilendirmekle ortaya çıkar. Aşağıdaki tablo, tasarım hedefini bunun geçerli olacağı koşuldan ayırmak için kullanılabilir.

Hat değişiminde oturumlar her zaman korunur mu?

Hayır. Yeni yolun bulunması, mevcut uygulama oturumunun kesintisiz devam etmesiyle aynı şey değildir. Özellikle yerel internet çıkışında başka ISP’ye geçildiğinde kaynak genel IP adresi değişebilir. NAT durumu, güvenlik duvarı oturumları, karşı uç davranışı ve uygulamanın yeniden bağlanma yeteneği sonucu etkiler. Fortinet’in teknik açıklaması da NAT oturumlarının yeniden değerlendirilmesine özel koşullar getirir.

Pilot sırasında yeni bağlantının kurulabildiğini göstermekle yetinmeyin. Devam eden dosya aktarımını, açık bir ERP oturumunu ve görüşmeyi ayrı ayrı deneyin. Şifreli overlay içindeki yol değişimi ile internet üzerindeki doğrudan çıkış değişimini aynı test sonucu gibi raporlamayın.

İki internet hattı tek bağlantının hızını ikiye katlar mı?

Akışların farklı hatlara dağıtılması, tek bir aktarımın bütün hat hızlarının toplamına ulaşacağını göstermez. Bazı çözümler oturum veya adres temelli dağıtım yapar; özel bant birleştirme mekanizmalarının desteği ayrıca değerlendirilir. Fortinet’in SD-WAN kural seçenekleri de farklı oturum ve adres tabanlı dağıtım yöntemleri tanımlar.

Örneğin iki adet 100 Mbps bağlantı, farklı akışlara toplamda daha fazla kapasite sunabilir; fakat tek bir akış için otomatik 200 Mbps taahhüdü değildir. Ayrıca tünel ek yükü, güvenlik işleme kapasitesi ve karşı uç sınırları ölçümde dikkate alınmalıdır.

Kötü hattın etkisi azaltılabilir; bütün sorunları giderilemez

Bazı ürünlerde ileri hata düzeltme (FEC) veya paket çoğaltma, belirli kayıp senaryolarında uygulamayı destekleyebilir. Bunun ek bant genişliği ve işlemci maliyeti vardır; desteklenen tünel ve trafik kapsamı değişir. Örneğin Palo Alto Networks dokümantasyonu bu işlevlerin seçici kullanılmasını ve ürüne özgü sınırlamaların dikkate alınmasını ister. Bu özellikler fiziksel kesintiyi veya kapasite yetersizliğini ortadan kaldıran bir garanti değildir.

Dolayısıyla iki kötü hattın bulunduğu bir lokasyonda ilk karar her zaman yeni yazılım almak olmayabilir. Son kilometre erişiminin yenilenmesi, yerel ağın düzeltilmesi veya daha uygun bir operatör yolunun seçilmesi gerekebilir.

SD-WAN mimarisinde hub nerede olmalı?

Hub; şubelerin belirli hedeflere erişmek, ortak güvenlik hizmetlerini kullanmak veya başka ağlara bağlanmak için trafik gönderdiği veri iletim noktasıdır. Yönetim paneliyle aynı işlev değildir. Hub veri merkezinde bulunurken yönetim sistemi bulutta çalışabilir; bazı akışlar da hub’a uğramadan doğrudan hedefe gidebilir.

Tek merkezli hub-and-spoke, birden fazla bölgesel hub ve şubeler arasında doğrudan iletişime izin veren mesh modelleri farklı ihtiyaçları karşılar. Cisco’nun tasarım rehberi bu topolojileri tünel ölçeği ve bölgesel tasarımla birlikte değerlendirir. Bu nedenle “SD-WAN için mutlaka tek bir merkez gerekir” veya “bütün trafiği aynı veri merkezine taşıyalım” yaklaşımı doğru başlangıç değildir.

Carrier-neutral yapı ne sağlar, neyi garanti etmez?

Carrier-neutral veri merkezi, tek bir bağlantı sağlayıcısına zorunlu bağımlılığı azaltan bir seçim ortamı sunar. Ancak birden fazla operatörün aynı tesiste bulunması, satın alınan iki devrenin fiziksel olarak bağımsız olduğunu kendiliğinden kanıtlamaz. Aynı kanal, bina girişi, ara taşıyıcı veya enerji bileşeni iki bağlantıyı birlikte etkileyebilir.

Bu nedenle sağlayıcı sayısını değil, ortak arıza alanlarını sorgulayın. İki devre hangi güzergâhlardan geliyor? Ayrı girişler var mı? Farklı sözleşmeler aynı son kilometre altyapısını mı kullanıyor? Yedek bağlantı planlı bakımlarda da kullanılabilir mi? Hat çeşitliliği, bu sorulara verilen cevaplarla gerçek bir süreklilik tasarımına dönüşür.

Peering, internet erişimi ve özel bulut bağlantısı aynı şey değildir

Peering, katılan ağlar arasındaki trafik değişimini ele alır; özel bulut bağlantısı ise belirli bir bulut sağlayıcısına tanımlı erişim sunar. DE-CIX’in GlobePEER ve DirectCLOUD hizmetleri de bunları ayrı hizmet kapsamlarında tanımlar. Bir internet exchange’e erişmek, internetteki bütün hedeflere doğrudan rota veya her uygulama için en düşük gecikme anlamına gelmez.

Hub seçerken “hangi exchange’e yakın?” sorusunu, “hedef ağlarımıza hangi peering veya transit ilişkileriyle erişiyoruz?” sorusuyla tamamlayın. Sağlayıcının sunduğu Internet Exchange ve peering seçenekleri ile Direct Cloud Access bağlantılarını ayrı ayrı değerlendirin. Birine erişim satın alınması diğerinin otomatik olarak devreye girdiğini göstermez.

Özel bulut devresini varsayılan olarak şifreli kabul etmeyin. Örneğin AWS Direct Connect, aktarılan trafiği varsayılan olarak şifrelemediğini açıkça belirtir; IPsec veya uygun MACsec seçenekleri ayrıca değerlendirilir. Bu ayrım bütün özel bağlantı tasarımlarında “izolasyon” ve “şifreleme” gereksinimlerinin ayrı sorulmasını gerektirir.

Hub’ın güçlü olması, bütün SaaS trafiğinin oradan geçmesini gerektirmez

Kurumsal uygulamalara erişim için colocation hub kullanırken, onaylı SaaS akışları için kullanıcıya yakın çıkış tasarlanabilir. Microsoft 365 özelinde yerel çıkış ve uygun DNS çözümlemesi birlikte değerlendirilmelidir; farklı bir SaaS ürününde ise sağlayıcının kendi bağlantı önerileri esas alınmalıdır. Bulut trafiğini otomatik olarak tek modele zorlamayın.

Kritik karar, “merkezi mi dağıtık mı?” ikiliğinden çok, hangi uygulamanın hangi güvenlik ve erişim koşuluyla hangi yolu kullanacağıdır. Aynı kurumda merkezi ERP, yerel SaaS çıkışı, özel bulut devresi ve kısıtlı mobil yedek birlikte bulunabilir.

Yedekli hub tasarımı nasıl değerlendirilir?

Aynı kabinet içindeki iki cihaz, cihaz arızası açısından faydalı olabilir; fakat tesis kaybı senaryosu için aynı korumayı sağlamaz. Yedek hub’ın rolünü seçilen risk senaryosuna göre tanımlayın. Tek cihaz, tek operatör, tek bina ve bölgesel kesinti birbirinden farklı olaylardır; her biri için aynı yedekleme yöntemi yeterli olmayabilir.

Hub’ı yedekleme ve kurtarma ortamına yakın konumlandırmak bağlantı planlamasını kolaylaştırabilir. Buna karşılık birincil uygulama, bütün hub’lar ve kurtarma erişiminin aynı arıza alanında toplanması ayrı bir risktir. Ağ kurtarma planı yalnızca cihaz yedeğini değil; alternatif hedeflere erişimi, DNS’i, kimlik hizmetlerini ve yönetim bağlantısını da kapsamalıdır.

Bu tablo bir ürün sıralaması değil, tasarım değerlendirme aracıdır. Hub’ın reklam edilen port hızı yerine gerçek işlevlerle ölçülen kapasitesini değerlendirin. Sanal hub için de işlemci, ağ arayüzü ve lisans sınırlarını tek bir kapasite kalemi gibi varsaymayın.

SD-WAN, SASE ve SSE arasındaki ilişki nedir?

SD-WAN bağlantı ve trafik politikalarına odaklanır; SASE ağ ve güvenlik işlevlerini bütünleştiren daha geniş bir çerçevedir. SSE ise bu çerçevenin güvenlik odaklı bölümünü ifade eder. İsimlerin benzer olması, kapsamlarının aynı olduğu anlamına gelmez. Mplify’nin SASE çerçevesi bağlantı, güvenlik, politika ve Zero Trust gereksinimlerini birlikte ele alır.

SSE ve SASE karşılaştırmasında ürünün gerçekten içerdiği işlevlere bakın. Güvenli web ağ geçidi (SWG), bulut erişim güvenliği aracısı (CASB), Zero Trust ağ erişimi (ZTNA) ve güvenlik duvarı yeteneklerinin kapsamı aynı paket adı altında farklılaşabilir.

Yerel internet çıkışı açılırken güvenlik nerede uygulanacak?

Bir şubede merkezden bağımsız internet çıkışı açılıyorsa hangi denetimin edge cihazında, hangisinin bulut tabanlı güvenlik hizmetinde, hangisinin uç noktada uygulandığını yazın. Kurumsal kullanıcılar, misafirler, yönetim trafiği ve üçüncü taraf erişimi için ayrı ihtiyaçlar belirleyin. Performans kazanmak amacıyla güvenlik zincirini farkında olmadan atlayan bir alternatif yol oluşturmayın.

WAN segmentasyonu, şubeler veya iş birimleri arasındaki erişimi ayırmaya yardımcı olabilir; uygulama içindeki yetkilendirmeyi ve iş yükü seviyesindeki kontrolü kendiliğinden sağlamaz. Bu ayrımı Zero Trust yaklaşımı ve mikrosegmentasyon rehberi ile birlikte değerlendirin.

Yönetim katmanını da koruyun

Merkezi politika dağıtımı, yönetim hesabının etkisini büyütür. Çok faktörlü kimlik doğrulama, görev bazlı yetki, kontrollü yönetim erişimi, yapılandırma değişikliği kayıtları ve güncel yazılım süreçleri bu nedenle proje kapsamına alınmalıdır. Uluslararası ortak ağ sıkılaştırma rehberi de yönetim bağlantılarının görünürlüğünü ve güçlü kimlik doğrulamayı vurgular.

Ayrıca cihaz sertifikalarının yenilenmesini, yapılandırma yedeklerini, hizmet hesabı yetkilerini ve acil yönetim yolunu planlayın. Güvenlik hizmetine ulaşılamadığında trafiğin durması veya sınırlı devam etmesi gibi kararları önceden onaylayın; arıza anında varsayılan ayarın keşfedilmesine bırakmayın.

SD-WAN ne zaman anlamlıdır, ne zaman gereksiz karmaşıklık yaratabilir?

Kararı yalnızca şube sayısına bağlamayın. Çok lokasyon, farklı bağlantı kaliteleri, yoğun SaaS kullanımı, sık şube açılışı ve tutarlı politika ihtiyacı değerlendirmeyi güçlendiren etkenlerdir. Ancak iki lokasyonlu bir kurum da kritik iş sürekliliği veya merkezi yönetim gereksinimi nedeniyle fayda görebilir.

Ön değerlendirmede üç soruya odaklanın: Mevcut ağda ölçülmüş hangi sorun çözülüyor? SD-WAN bu sorunu alternatiflerden daha uygun biçimde çözebiliyor mu? Politikayı işletmek ve sonuçları izlemek için gerekli sorumluluk modeli var mı? Tek amaç düşük fiyatlı bir hat satın almaksa, daha basit bir çift-WAN çözümü de karşılaştırmaya alınabilir.

Bütün uygulamaların tek veri merkezinde bulunması SD-WAN’ı otomatik olarak gereksiz kılmaz; hat çeşitliliği, segmentasyon veya operasyonel standartlaşma yine değer yaratabilir. Buna karşılık ağ basit, performans yeterli ve değişiklik ihtiyacı düşükse ek lisans ve işletim katmanı beklenen faydayı karşılamayabilir. Kararı bir pilot ve aynı kapsamlı maliyet karşılaştırmasıyla destekleyin.

SD-WAN’a geçiş için sekiz pratik adım

SD-WAN geçişi cihaz seçimiyle değil, mevcut trafik ve başarısızlık senaryolarının anlaşılmasıyla başlar. Aşağıdaki sıra bir proje çerçevesidir; güvenlik ve işletim kararları son adımlara bırakılmaz, başlangıçtan itibaren bütün aşamalara eşlik eder.

1. Lokasyon ve hat envanterini çıkarın

Lokasyon başına bağlantı türü, sağlayıcı, kapasite, gerçek kullanım, genel IP/NAT durumu, sözleşme bitişi ve yedek erişimi kaydedin. Cihaz modeli, yazılım desteği, güç, yerel ağ ve saha erişimini aynı envantere ekleyin. İki bağlantının birbirinden bağımsız olduğu varsayımını doğrulanması gereken ayrı bir madde olarak işaretleyin.

2. Uygulamaları ve bağımlılıkları sınıflandırın

ERP, ses/video, SaaS, veri aktarımı ve misafir erişimi gibi gruplar oluşturun; fakat her uygulamanın sahibi ve iş etkisi belli olsun. IP izin listeleri, DNS, kimlik sağlayıcıları, lisans sunucuları ve dış iş ortakları gibi bağımlılıkları kaydedin. “İnternet açılıyor” testi, bu bağımlılıkların çalıştığını kanıtlamaz.

3. Mevcut kaliteyi ve kabul ölçütlerini belirleyin

Yoğun saatleri ve dönemsel işleri kapsayan bir başlangıç ölçümü yapın. Uygulama işleminin süresini, hata oranını ve kesinti sırasında kullanıcı davranışını ağ verileriyle birlikte değerlendirin. RTT veya paket kaybı eşiklerini başka bir kurumdan kopyalamak yerine uygulama sahibiyle belirleyin. Ölçüm noktası ve gözlem süresi kayıtlı olsun.

4. Hub ve çıkış mimarisini ayrıca karara bağlayın

Kurumsal uygulama, SaaS, internet ve özel bulut trafiğinin gidiş ve dönüş yollarını çizin. Hub’ın konumu kadar yedek hub, NAT, güvenlik denetimi ve alternatif çıkış IP’lerini belirleyin. Mobil veya NAT arkasındaki hatların seçilen ürünün tünel kurulum koşullarını karşılayıp karşılamadığını doğrulayın. Büyük paket ve gerçek uygulama testleriyle MTU kaynaklı sorunları da araştırın.

5. Farklı profilde pilot lokasyonlar seçin

Sadece bağlantısı iyi olan merkez ofiste pilot yapmayın. Yoğun bir şube, sınırlı bağlantıya sahip bir nokta ve farklı erişim türü kullanan bir lokasyon seçmek daha anlamlı karşılaştırma sağlayabilir. Normal çalışmanın yanında hat kaybı, performans bozulması, hub kaybı ve geri dönüş testleri planlayın. Pilot sonuçları onaylanmadan geniş yayılımı başlatmayın.

6. Mevcut MPLS ve diğer bağlantıların rolünü ölçümle değiştirin

MPLS’i otomatik olarak kaldırmak yerine, hangi lokasyonda ana veya yedek yol olarak korunacağını belirleyin. Sözleşme, geri dönüş ihtiyacı ve test sonuçları uygunsa kademeli rol değişikliği yapın. Bir taşıma hizmetini iptal etmeden önce yeni yapının bütün kritik iş dönemlerini karşılayabildiğini ve ihtiyaç halinde geri dönüşün hâlâ uygulanabilir olduğunu teyit edin.

7. Güvenlik politikasını aynı değişiklik planında uygulayın

Yerel internet çıkışı, segmentler, cihaz yönetimi ve bulut güvenlik hizmetleri aynı kapsamda test edilmelidir. Eski erişim kuralları yeni çıkış IP’leriyle uyumlu mu? Üçüncü taraf izinleri güncellendi mi? Alternatif yol aynı güvenlik kontrolünü uyguluyor mu? Bu sorular cevaplanmadan yalnızca performans sonucuna dayanarak kabul vermeyin.

8. İzleme, kabul ve işletime devri tamamlayın

Politika değişikliği, operatör arızası, cihaz yenileme ve güvenlik olayında kimin sorumlu olduğunu yazılı hale getirin. Yapılandırma yedeklerini ve geri dönüş prosedürünü test edin. Gözlemlenebilirlik yaklaşımındaki gibi, altyapının durumunu iş hizmetinin sonucuyla ilişkilendirin. Projenin bitiş noktası, cihazların panele eklenmesi değil; kabul koşullarının sağlanması ve operasyonun devralınmasıdır.

Örnek: 20 şubeli bir kurumda SD-WAN pilotu nasıl kurgulanır?

Aşağıdaki senaryo kurgusaldır. Gerçek müşteri, teklif, ölçülmüş performans sonucu veya belirli bir ürüne ait hazır konfigürasyon değildir. Amaç, aynı ağ içinde farklı uygulamalara farklı yollar tanımlamanın nasıl değerlendirileceğini göstermektir.

Varsayalım ki kurumun 20 şubesi bulunuyor; ERP uygulaması Ankara’daki bir colocation ortamında çalışıyor. Şubeler SaaS iş birliği araçlarını da kullanıyor. Bazı lokasyonlarda MPLS ve internet birlikte mevcut, bazılarında internet ile mobil yedek bulunuyor. Başlangıçta internet trafiğinin tamamı genel merkezden çıkıyor.

Önerilen tasarım hipotezi

ERP trafiğini uygulamanın bulunduğu ortama erişen hub üzerinden, onaylı SaaS trafiğini ise kullanıcıya uygun güvenli çıkış üzerinden geçirmek değerlendirilir. Kurtarma ortamına erişim için farklı bir arıza alanındaki ikinci hub seçeneği incelenir. Mobil bağlantı, bütün yükü üstlenecek sınırsız yedek olarak değil; tanımlanan kritik işlemleri sürdürecek seçenek olarak planlanır.

Üç pilot lokasyon seçilir: yoğun işlem yapan bir şube, bağlantı kalitesi dalgalanan bir şube ve mobil yedeğe bağımlı bir nokta. Önce gerçek trafik sınıflandırması ve ERP işlemleri doğrulanır. Ardından bir hattın tamamen kaybı ile hat çalışırken kalitesinin bozulması ayrı deneyler olarak uygulanır.

Bir ağ hedefi ile iş kabul kriterini ayırın

Örneğin ekip, yalnızca bu pilot için şube-hub yolunda RTT’nin 80 ms’yi, ölçülen jitter’ın 20 ms’yi ve paket kaybının %1’i aşmamasını araştırma başlangıcı olarak seçebilir. Bu değerler evrensel standart veya önerilen hizmet seviyesi değildir. Ölçüm dönemi ve cihazın hesaplama yöntemiyle birlikte tanımlanmalı, uygulama testine göre değiştirilmelidir.

ERP’nin kabul kriteri ise ağ sayacından farklıdır: örneğin onaylanan kullanıcı yükünde sipariş işleminin tamamlanması, hat değişiminde işlemin kaybolmaması ve tekrar denemelerin mükerrer kayıt oluşturmaması. Ağ ekibi yolu doğrularken uygulama sahibi işlem sonucunu doğrular. Bu kontrol, SD-WAN’ın uygulama içi veri tutarlılığını tek başına sağladığı varsayımını önler.

Pilotun sonunda yalnızca “gecikme azaldı” raporu hazırlanmaz. Hangi uygulama hangi yoldan geçti, hangi olayda kaç oturum yeniden kuruldu, güvenlik kontrolü korundu mu ve kalan kapasite yeterli miydi? Sonuçlar kabul tablosuna işlenir; sağlanmayan koşullar için düzeltme ve yeniden test kararı alınır.

SD-WAN pilotunda hangi testler yapılmalı?

Kabul testi, cihazın desteklediği özellik listesi ile kurumun ihtiyaç duyduğu davranışı birbirinden ayırır. Aşağıdaki testler kontrollü pilot ortamında, onaylı değişiklik ve geri dönüş planıyla yürütülmelidir. Başarı eşikleri testten önce belirlenmelidir; tablo evrensel süre veya performans hedefi vermez.

Yönetim paneline erişilememesi ile hub’ın veri iletememesi aynı arıza değildir. Bazı tasarımlarda uçlar son geçerli bilgilerle bir süre iletime devam edebilir; bu sürenin rota ve anahtar yaşam döngüleriyle ilişkisi ürüne göre değişir. Cisco’nun graceful restart açıklaması bir örnektir, bütün SD-WAN ürünlerine genellenemez.

Her test için gerçek uygulama işlemi kullanın. Bir ping’in cevap vermesi; kimlik doğrulamanın, TLS oturumunun veya sipariş akışının tamamlandığını kanıtlamaz. Gidiş ve dönüş trafiği, büyük veri aktarımı, DNS ve dış entegrasyonlar test kapsamına dahil edilmelidir.

SD-WAN maliyeti ve üretici bağımlılığı nasıl değerlendirilir?

SD-WAN’ın ekonomik sonucu yalnızca MPLS faturasıyla internet faturası karşılaştırılarak hesaplanamaz. Aynı lokasyon sayısı, kapasite, güvenlik kapsamı ve hizmet beklentisiyle toplam sahip olma maliyeti çıkarılmalıdır. Aşağıdaki tablo fiyat tahmini değil, teklifleri aynı zeminde değerlendirmek için bir maliyet kapsamıdır.

Basit bir karşılaştırma çerçevesi olarak: toplam maliyet = tek seferlik kurulum/geçiş + seçilen dönem boyunca tekrarlayan giderler + kurum içi işletim emeği + planlanan çıkış giderleri. Bir kalem cihaz, hizmet ve lisans teklifinde birden fazla kez yer alıyorsa çift sayımı önleyin. Kesinti riskinin parasal etkisini bu kesin giderlerden ayrı bir senaryo olarak değerlendirin; varsayımsal kazancı gerçekleşmiş tasarruf gibi sunmayın.

Üretici bağımlılığını da başlangıçta tartışın. IPsec veya BGP gibi standart bileşenlerin kullanılması, farklı üreticilerin politika motorları ve kontrol düzlemlerinin birbirinin yerine geçebileceğini kanıtlamaz. Sağlayıcı değişimi için politika tanımları, envanter, yapılandırmalar, günlükler, API erişimi ve kimlik bilgileri üzerinde hangi haklara sahip olduğunuzu sorun. Vendor Lock-in rehberi bu çıkış değerlendirmesini daha geniş altyapı bağlamında ele alır.

Kendi kendine yönetim ile yönetilen hizmet karşılaştırmasında ise aynı kapsamı kullanın. Operatör arıza takibi, gece müdahalesi, güvenlik güncellemeleri ve politika onayı aynı tarafta değilse iki teklifin toplamı aynı işi temsil etmiyor olabilir.

İzleme ve operasyon sorumlulukları nasıl paylaşılmalı?

Merkezi panel bulunması, sorumluluğun kendiliğinden merkezileştiği anlamına gelmez. Bir performans sorunu erişim hattında, SD-WAN politikasında, güvenlik katmanında veya uygulamada olabilir. Her olayın otomatik olarak bir sonraki tedarikçiye yönlendirilmesini önlemek için olay sahipliğini ve ortak inceleme yöntemini belirleyin.

İzleme planında tünel durumuna ek olarak hangi uygulamanın hangi yolu kullandığını, politika eşleşmelerini, kritik eşik dışında geçirilen süreyi, oturum yenilemelerini ve değişiklik geçmişini değerlendirin. Ortalama değerlerin yanında yoğun saatleri ve kullanıcı etkisini de görünür kılın. Yönetilen Hizmetler değerlendirmesinde, izleme kapsamının bu ağ ve uygulama göstergelerinden hangilerini içerdiğini ayrıca netleştirin.

Olay sonrası incelemede “hat yeşildi” veya “cihaz çalışıyordu” açıklamasıyla yetinmeyin. Sorunun başlangıcı, politika değişiklikleri, yol geçişi ve uygulamanın yeniden kullanılabilir olduğu an birlikte kaydedilmelidir. Kalıcı iyileştirme; alarm sayısının artması değil, sorunun nedeninin anlaşılması ve tekrarının önlenmesidir.

SD-WAN’a geçiş öncesi kontrol listesi

Aşağıdaki listeyi proje başlangıcında bir hazırlık tablosu olarak kullanın. Her satıra kurumunuzun sorumlusunu, hedef tarihini ve kanıt bağlantısını ekleyin. Tamamlanmamış bir maddeyi yalnızca toplantıda konuşulmuş olması nedeniyle tamamlandı olarak işaretlemeyin.

SD-WAN hakkında sıkça sorulan sorular

SD-WAN, MPLS’in yerini tamamen alır mı?

Hayır. MPLS tabanlı IP VPN, SD-WAN’ın kullandığı taşıma hizmetlerinden biri olarak kalabilir. Hangi lokasyonda korunacağı; uygulama gereksinimi, performans ölçümü, yedeklilik ve maliyetle belirlenir. Yeni mimarinin kabul testleri tamamlanmadan mevcut bağlantının iptal edilmesi doğru bir geçiş varsayımı değildir.

SD-WAN internet bağlantılarını garantili hale getirir mi?

Tek başına getirmez. Mevcut yollar arasında seçim yaparak bir sorunun etkisini azaltabilir. Ancak iki yol aynı fiziksel arızadan etkileniyorsa veya alternatif kapasite yetersizse bunu ortadan kaldıramaz. İnternet ve yönetilen hizmet sözleşmelerinin garanti kapsamı, ölçüm noktaları ve istisnaları ayrıca değerlendirilmelidir.

SD-WAN ile VPN aynı şey midir?

Hayır. Site-to-site VPN lokasyonlar arasında bir tünel veya özel bağlantı sağlar; SD-WAN bu tür bağlantıları uygulama politikaları, kalite ölçümü ve merkezi yönetimle birlikte kullanabilir. VPN’in mutlaka statik olduğu söylenemez; dinamik yönlendirme ve yedek tüneller de kullanılabilir.

SD-WAN ile SASE arasındaki fark nedir?

SD-WAN’ın odağı WAN bağlantısı ve trafik yönetimidir. SASE, bağlantı ve güvenlik işlevlerini ortak bir mimaride birleştirir. SSE ise güvenlik odaklı bileşenleri ifade eder. Bir SD-WAN ürünü almak, bütün SASE gereksinimlerinin karşılandığı anlamına gelmez.

SD-WAN küçük bir şirket için gerekli midir?

Lokasyon sayısı tek başına karar ölçütü değildir. İki şubeli bir kurumda bile kritik erişim ve merkezi politika ihtiyacı olabilir. Buna karşılık basit, kararlı ve az değişen bir ağda ek maliyet ve operasyon yükü fazla gelebilir. Aynı ihtiyacı karşılayan daha basit seçeneklerle birlikte değerlendirilmelidir.

SD-WAN’ı kurum içinde mi yönetmeli, yönetilen hizmet mi seçmeli?

Karar; ekibin yetkinliği, müdahale saatleri, değişiklik sıklığı ve sahip olunmak istenen kontrol düzeyine bağlıdır. Yönetilen modelde de uygulama öncelikleri, güvenlik onayları ve iş kabulü sahipsiz bırakılamaz. Hizmetin adı yerine sorumluluk matrisi, kapsam ve eskalasyon mekanizması karşılaştırılmalıdır.

SD-WAN için mutlaka bir hub gerekir mi?

Tek bir merkezi hub her mimari için zorunlu değildir. Şubeler arası doğrudan bağlantı, bölgesel hub, bulut edge ve yerel internet çıkışı birlikte kullanılabilir. Uygulama yerleşimi ve güvenlik ihtiyacı, hangi akışın hub üzerinden geçeceğini belirler.

Carrier-neutral veri merkezinde iki operatör kullanmak yeterli mi?

Sağlayıcı seçeneği önemli bir başlangıçtır; fakat gerçek yedeklilik için güzergâh ve ortak altyapı doğrulanmalıdır. Aynı bina girişi, kanal veya üst sağlayıcı iki devreyi birlikte etkileyebilir. Farklı sözleşme sayısı, farklı arıza alanı sayısıyla eş anlamlı değildir.

Hat değiştiğinde açık oturumlar kopar mı?

Kopabilir. Genel IP, NAT, güvenlik duvarı oturum durumu, tünel davranışı ve uygulamanın yeniden bağlanması belirleyicidir. Bu nedenle hat geçişi yeni bağlantılarla ve devam eden işlemlerle ayrı ayrı test edilmelidir. Kesintisizlik ürün adına bakılarak varsayılamaz.

SD-WAN iki hattın hızını tek aktarım için birleştirir mi?

Bütün çözümlerde ve bütün akışlarda değil. Oturumların hatlara dağıtılması toplam kullanımı iyileştirebilir; tek aktarımın hızlarının toplamına ulaşması ayrı bir yetenektir. Gerekli ise bant birleştirme desteği, karşı uç gereksinimi ve gerçek trafik performansı doğrulanmalıdır.

Kontrolcüye ulaşılamazsa bütün ağ durur mu?

Ürün ve tasarıma bağlıdır. Bazı sistemler son geçerli rota ve politikalarla belirli koşullarda iletime devam eder; yeni cihaz katılımı, rota değişimi veya anahtar yenileme etkilenebilir. Kontrolcü erişimi, yönetim erişimi ve hub kaybı ayrı test edilmelidir.

SD-WAN’a geçiş ne kadar sürer?

Süre; lokasyon sayısı, hat teslimleri, güvenlik entegrasyonları, uygulama bağımlılıkları ve pilot sonuçlarına bağlıdır. Hazır bağlantı üzerinden bir cihazı devreye almak, kurumsal geçişin tamamlanmasıyla aynı şey değildir. Keşif, pilot, kabul, kademeli yayılım ve işletime devir ayrı planlanmalıdır.

Ixpanse ve SD-WAN mimarisinin bağlantı katmanı

SD-WAN ürününden bağımsız olarak hub’ın barındırılacağı ortam, operatör seçenekleri ve kurumsal uygulamalara erişim tasarımı değerlendirilmelidir. Ixpanse’in Sunucu Barındırma hizmetinde yer alan carrier-neutral altyapı yaklaşımı ve Ankara IX kapsamındaki bağlantı seçenekleri, bu değerlendirmede barındırma ve erişim katmanını birlikte ele almak için bir zemin sunar.

Şube tarafındaki işletim ihtiyaçları için Yerinde Hizmetler kapsamındaki yönetilen ağ yaklaşımı; güvenlik ve süreklilik gereksinimleri için Veri Koruma hizmetleri ayrıca incelenebilir. SD-WAN ürünü, lisansı, politika işletimi, operatör hizmeti ve bulut bağlantısı aynı kapsam olarak varsayılmamalıdır; hangi işin hangi tarafça sağlanacağı proje ve sözleşmede netleştirilmelidir.

Hub konumlandırmasını, çoklu operatör tasarımını, colocation ihtiyacınızı ve bulut erişim yollarınızı birlikte değerlendirmek için Ixpanse uzman ekibiyle iletişime geçin. Görüşme öncesinde lokasyon listenizi, kritik uygulamalarınızı, mevcut hatlarınızı ve kabul edilebilir kesinti koşullarını hazırlamanız, ihtiyaca uygun bir değerlendirme yapılmasını kolaylaştırır.

Sonuç: SD-WAN kararı cihazdan önce trafik ve sorumluluk kararıdır

SD-WAN, farklı bağlantıları ortak bir politika altında kullanmayı kolaylaştırır; fakat uygulama gereksinimlerini, fiziksel bağlantı kalitesini ve operasyon sorumluluğunu ortadan kaldırmaz. MPLS ile birlikte çalışabilir, VPN teknolojilerini kullanabilir ve SASE mimarisinin bağlantı bileşenini oluşturabilir. Değeri, kullanılan etiketle değil, doğrulanmış davranışla ölçülmelidir.

Sağlam bir tasarım; hangi uygulamanın nerede çalıştığını, hangi yolu kullanabileceğini, güvenlik denetiminin nerede uygulanacağını ve arızada ne olacağını açıklar. Carrier-neutral colocation, uygun senaryolarda hub için güçlü bir seçenek olabilir; ancak bütün trafiği merkeze toplamak veya bağımsızlığı doğrulanmamış iki hattı yedekli saymak doğru değildir.

SD-WAN projesinde ilk soru “hangi cihazı alalım?” değil, “hangi iş işlemi hangi bağlantıya bağımlı, bu yol bozulursa ne olacak ve sonucu nasıl kanıtlayacağız?” olmalıdır. Cevabı envanter, pilot, kabul testleri ve net işletim sorumluluklarıyla veren kurumlar, teknoloji seçimini somut iş gereksinimine bağlayabilir.

İlgili içerikler

Carrier-Neutral Veri Merkezi Nedir? · Direct Cloud Access Nedir? · Internet Exchange Nedir? · Ağ Kurtarma Rehberi · Vendor Lock-in Nedir? · Hibrit Bulut Nedir?