Klasik ADC devreye alma projelerinde en büyük maliyet çoğu zaman ürünün kendisi değil, mevcut ağın ürüne göre yeniden düzenlenmesidir. Kurum servislerinin default gateway ayarlarını değiştirmek, IP planını yeniden yapmak, route davranışını elden geçirmek veya bakım penceresi açmak üretim ortamında ciddi risk oluşturur.
Özellikle yüzlerce veya binlerce kurum servisi olan yapılarda "her sunucunun gateway'ini değiştir" yaklaşımı uygulanabilir değildir. Bazı kurum servislerinde gateway hiç tanımlı olmayabilir, bazıları statik route ile çalışıyor olabilir, bazıları ise değiştirilmesi zor eski sistemler üzerinde koşuyor olabilir. Bu durumda ADC'yi araya almak yalnızca network projesine dönüşür.
Bir başka problem de ağ alanlarının zorla birleştirilmesidir. VIP DMZ tarafında durmalı, kurum servisi iç ağda kalmalı, tenant ağları birbirinden ayrılmalı veya yönetim ağı ayrı tutulmalıdır. Eğer ADC bu alanlar arasında kontrollü trafik taşıyamıyorsa, güvenlik segmentasyonu bozulur ya da uygulama ekipleri gereksiz IP taşıma işine zorlanır.
Tek tip reverse proxy modeli de her ihtiyacı karşılamaz. Bazı uygulamalarda kurum servisinin gerçek istemci IP'sini görmesi gerekir; bazı L4 servislerde dönüş trafiğinin ADC üzerinden geçmesi istenmez; bazı inline senaryolarda ise IP değiştirmeden ve gateway'e dokunmadan trafiği araya almak gerekir. NAT tabanlı tek model bu çeşitliliği karşılamaz.
TR7 Dağıtım Topolojisi Modları bu esnekliği sağlar: kurum servislerinin IP, gateway veya Route Tablosu yerleşimine dokunmadan, servis ihtiyacına göre doğru trafik yerleşimini seçmenize izin verir.
TR7, dağıtım topolojisini servis tipine, ağ yerleşimine ve geçiş riskine göre seçilebilir bir mimari karara dönüştürür.
Klasik reverse proxy modelinde istemci TR7'ye, TR7 kurum servisine bağlanır. Transparent bind senaryosunda ise kurum servisi gerçek istemci IP'sini görebilecek şekilde trafik akışı korunabilir.
NAT modunda hedef ve kaynak dönüşümü birlikte yönetilir. SNAT modunda yalnızca kaynak tarafı düzenlenir; DR modunda ise dönüş trafiği doğrudan istemciye giderek yüksek hacimli L4 senaryoları için daha verimli akış sağlar.
VIP'in bulunduğu Route Tablosu ile kurum servisinin bulunduğu Route Tablosu farklı olabilir. TR7 bu iki ağ alanı arasında kontrollü trafik taşıyarak DMZ, iç ağ, tenant ağı ve yönetim ağı gibi bölümleri düzleştirmeden birbirine bağlar.
TR7, belirli kurum servisi IP'leri için trafiği kendi üzerine çekebilir. Kurum servisinin IP'si, gateway'i veya uygulama ayarı değiştirilmeden ADC devreye alınabilir.
Dağıtım Topolojisi Modları, hızlı kurulumdan yüksek performanslı L4 trafiğe kadar farklı ağ yerleşimlerini destekler.
One-arm modelde istemci ve kurum servisi trafiği aynı ağ tarafında karşılanabilir. TR7 tek arayüz üzerinden servis trafiğini alır ve yönlendirme kurallarıyla ilgili kurum servisine aktarır. Bu model, minimum ağ değişikliğiyle hızlı ADC devreye alma için uygundur. Özellikle pilot, geçici geçiş veya düşük riskli yayın senaryolarında pratik başlangıç noktasıdır.
Two-arm modelde TR7, iki farklı ağ segmenti arasında konumlanır. Bir tarafta istemci veya DMZ ağı, diğer tarafta kurum servisi ağı bulunur. Bu yapı, ADC'yi yalnızca trafik yönlendiren değil, ağ sınırında politika uygulayan bir geçiş noktası haline getirir. Güvenlik ve segmentasyon gerektiren kurumsal mimariler için uygundur.
Reverse proxy modelinde istemci TR7 üzerindeki VIP veya vService'e bağlanır, TR7 ise kurum servisine ayrı bağlantı açar. TLS sonlandırma, WAAP, header düzenleme, çerez güvenliği, içerik farkındalıklı kurallar ve AAM entegrasyonu bu modelde tam uygulanabilir. Bu, HTTP ve API trafiği için en yaygın uygulama teslim topolojisidir. Kurum servisi doğrudan internet veya dış ağ karşısına çıkarılmaz.
Transparent L7 senaryosunda kurum servisi tarafında kaynak IP'nin gerçek istemci olarak görünmesi hedeflenir. Bu model, yalnızca header tabanlı istemci IP aktarımına güvenmek istemeyen uygulamalar için değerlidir. Log, erişim kontrolü ve uygulama içi IP bazlı kararlar daha doğal çalışabilir. Ağ dönüş yolunun buna uygun planlanması gerekir.
Bridge modeli, TR7'nin trafik yoluna L2 seviyesinde köprü gibi yerleşmesine izin verir. Bu senaryoda ek IP yeniden planlama veya geniş routing değişikliği ihtiyacı azalabilir. VM, container veya segment arası geçişlerde mevcut adresleme korunarak trafiğe girilebilir. Bridge modu, ağ değişikliğinin sınırlı tutulması gereken ortamlarda kullanışlıdır.
Transparent gateway modelinde TR7, kurum servisi ağının geçiş noktasına yerleştirilir. Kaynak IP korunabilir ve NAT zorunlu hale gelmez. Bu model, kurum servislerinin istemci IP'sini doğal biçimde görmesi gereken senaryolarda değerlidir. Default route değişimi dikkatli planlanmalı ve geri dönüş yolu net kontrol edilmelidir.
TR7, belirlenen kurum servisi IP'leri için trafik sahipliğini kendi üzerine alarak inline çalışabilir. Bu model, kurum servisinin IP adresi, default gateway'i veya route ayarları değiştirilemediğinde özellikle değerlidir. Kurum servisi gateway kullanmıyor olsa bile TR7, ilgili trafik yoluna araya giren kontrol noktası olarak konumlanabilir. Büyük ortamlarda yüzlerce kurum servisini tek tek değiştirmek yerine kontrollü inline geçiş sağlanır.
TR7, bir Route Tablosu üzerindeki VIP'i dinleyip trafiği farklı bir Route Tablosu üzerindeki kurum servisine yönlendirebilir. Bu sayede DMZ, iç ağ, tenant ağı, yönetim ağı veya farklı servis bölgeleri aynı ağ düzlemine taşınmadan birbirine kontrollü biçimde bağlanır. Operatör kurum servislerini yeniden IP'lendirmek veya ağları düzleştirmek zorunda kalmaz. TR7, Route Tabloları arasında güvenlik politikası uygulanabilen kontrollü geçiş noktası haline gelir.
L4 NAT modunda hedef dönüşümü ve kaynak dönüşümü birlikte kullanılarak trafiğin dönüş yolu TR7 üzerinden garanti altına alınabilir. SNAT modunda ise sadece kaynak tarafı düzenlenir ve kurum servisinin mevcut dönüş yolu tasarımına göre hareket edilir. Bu iki model, L4 trafiğin ağ topolojisine uygun biçimde taşınmasını sağlar. UDP, TCP veya belirli port aralıkları için ayrı davranışlar seçilebilir.
DR modunda istek trafiği TR7 üzerinden kurum servisine yönlendirilir, cevap trafiği ise doğrudan istemciye dönebilir. Bu model, özellikle yüksek hacimli streaming, oyun, DNS veya düşük gecikme isteyen L4 servislerde avantaj sağlar. ADC dönüş trafiğini taşımadığı için veri yolu daha verimli hale gelir. DR senaryosunda kurum servisi ve ağ dönüş davranışı doğru hazırlanmalıdır.
L4 persistence, belirli istemci trafiğinin aynı kurum servisi hedefinde kalmasına yardımcı olur. CONNMARK, recent kayıtları ve persistence süresiyle akış sürekliliği sağlanabilir. SIP persistence ise SIP trafiği gibi oturum hassas protokollerde özel davranış sunar. Bu yapı, L4 seviyesinde yalnızca dağıtım değil, oturum tutarlılığı da sağlar.
L4 ve vService tanımları için gerekli giriş izinleri otomatik üretilebilir. Her front-end IP, port ve protokol için uygun kabul kuralları oluşturularak manuel güvenlik duvarı hataları azaltılır. Inline ve L4 senaryolarda otomatik kural üretimi özellikle önemlidir. Operatör topolojiyi seçer, TR7 ilgili trafik yolunun temel izinlerini tutarlı biçimde üretir.
Topoloji modları; L4 varsayılanları, inline süreç davranışı, TR7 Route Tabloları, cluster rolü ve hata görünürlüğüyle birlikte işletilir.
Yeni L4 pool için round-robin algoritması, NAT modu ve UDP protokolü varsayılan başlangıç değerleri olarak kullanılabilir. Operatör bu değerleri servis ihtiyacına göre TCP, UDP, any protocol, port range veya farklı L4 algoritmalarına çevirebilir. Varsayılanlar hızlı başlangıç içindir; production davranışı açıkça gözden geçirilmelidir.
Round-robin ve weighted round-robin gibi algoritmalar L4 dağıtımda kullanılabilir. Ağırlıklı model, farklı kapasitedeki kurum servisleri arasında daha dengeli trafik dağıtımı sağlar. Algoritma seçimi servis tipi, kapasite ve oturum davranışıyla birlikte planlanmalıdır.
IP sahiplenme tabanlı inline mod, ilgili arayüz, kurum servisi IP'si ve gateway bilgisine göre çalışır. Gateway açıkça belirtilmemişse mevcut ağ bilgisinden uygun yol çıkarılabilir. Süreç beklenmedik şekilde durursa otomatik yeniden başlatma uygulanabilir.
Inline modda noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice ve inactiveClusterIp gibi durumlar açık hata nedeni olarak gösterilebilir. Bu, "çalışmıyor" demek yerine neden çalışmadığını operasyon ekibine netleştirir. Hata görünürlüğü, inline topolojilerin güvenle işletilmesi için kritiktir.
Cluster ortamında inline sahiplenme işlemi yalnızca aktif rolü taşıyan cihazda yürütülmelidir. Aktif cihaz değiştiğinde inline trafik sahipliği de ilgili düğüme taşınır. Bu model, iki düğümün aynı IP için aynı anda sahiplik iddiasında bulunmasını engellemeye yardımcı olur.
Inline transparent mod, kurum servisinin default gateway ayarına bağımlılığı azaltır. Kurum servisinin gateway'i yoksa veya değiştirilemiyorsa TR7 ilgili trafik yolunu IP sahiplenme yöntemiyle kendi üzerine alabilir. Bu özellik, bakım penceresi açmadan ve kurum servisini değiştirmeden kontrollü ADC devreye alma sağlar.
VIP'in dinlendiği TR7 Route Tablosu ile kurum servisinin bulunduğu TR7 Route Tablosu farklı olabilir. TR7, bu iki ağ alanı arasında trafik taşıyarak topoloji değişikliği ihtiyacını azaltır. Bu davranış özellikle DMZ'den iç ağa, tenant ağından ortak servis ağına veya migration sırasında eski ve yeni ağ alanları arasında kontrollü geçiş için değerlidir.
Büyük kurumlarda yüzlerce kurum servisinin IP, route veya gateway ayarını değiştirmek risklidir. IP sahiplenme tabanlı inline mod, mevcut adresleme korunarak TR7 ADC'nin trafik yoluna alınmasını sağlar.
Bazı eski veya izole kurum servislerinde default gateway tanımlı olmayabilir. TR7, inline transparent modda bu servislerin gateway ayarına dokunmadan ilgili trafiği kendi üzerinden geçirerek devreye alınabilir.
Kurumlar VIP'i DMZ Route Tablosunda dinletip kurum servisini iç Route Tablosunda tutabilir. TR7, ağları birleştirmeden ve servis IP'lerini değiştirmeden bu iki alan arasında kontrollü trafik geçişi sağlar.
Oyun veya streaming ekipleri DR moduyla cevap trafiğini doğrudan istemciye döndürebilir. TR7 trafik kararını verirken dönüş veri yolu üzerindeki yük azaltılır ve yüksek throughput senaryoları daha verimli hale gelir.
One-arm'dan transparent inline'a, L4 DR'dan Route Tablosu arası geçişe kadar doğru topolojiyi canlı bir kurulumda birlikte inceleyelim.