Bölüm 47: Ara Kutular

Bir önceki durakta paketin kaynak adresi geçitte değişti. O kutu paketi yalnızca iletmedi, başlığındaki bir alana dokundu. Router’ın tanımında böyle bir iş yok.

Yolun geri kalanı da benzer kutularla dolu ve çoğunun adı burada hiç geçmedi. Peki bir cihaz ne zaman router olmaktan çıkıyor?

Bir kutu ne zaman router olmaktan çıkar?

Resmi tanım RFC 3234 numaralı belgede duruyor. Tanıma göre ara kutu, kaynak ile hedef arasındaki veri yolunda bulunan ve bir IP router’ının olağan işlevleri dışında iş gören her aracı kutudur. Tanımın biçimine dikkat et: ortada bir cihaz listesi yok, bir dışlama kuralı var.

Çizgi de katmanla çekiliyor. Bir router’dan en fazla network layer’a kadar işlem yapması bekleniyor; transport layer’daki port numarasına uzanan bir kutu o çizginin dışına çıkmış oluyor. Adres çeviren kutuyu zaten tanıyorsun: 46. bölümde port çevirisinin end-to-end argument’a ödettiği bedeli saymıştık.

Katman eşlemesi eski bir tablodan geliyor: repeater physical layer’da, switch data link layer’da, router network layer’da durur. Adlandırma da burada karışıyor: IP dünyasında router’ın kendisine de geçit deniyor, oysa aynı ad transport layer’dan application layer’a kadar OSI’nin dört katmanını birden kaplayan kutular için de kullanılıyor. Bir kutunun adı hangi katmanda çalıştığını söylemez; söyleyen şey baktığı alandır.

Ara kutular beş sınıfta toplanıyor ve her sınıf başka bir yerde duruyor.

Dağılımın kendisi de bir şey söylüyor. Firewall ile saldırı tespiti tablodaki dört yerin hepsinde birden tekrarlanıyor. Aynı işlev dört kez satın alınıyor. O kutu hem erişim ağlarında hem çekirdek ağda duran özelleşmiş bir ara kutu olarak sınıflandırılıyor.

Beş sınıfın tamamı tek bir soyutlamaya iniyor: eşleştir ve uygula. Firewall IP adresleriyle taşıma portlarını eşleştirir, eylemi de izin vermek ya da reddetmektir. Router, switch ve adres çevirici aynı kalıbı kullanır. Değişen tek şey hangi alana bakıldığıdır.

Bir istek kaç bağlantıya bölünüyor?

16. bölümde proxy iki rolü aynı anda oynuyordu: isteği yapan istemciye karşı sunucu, origin sunucuya karşı istemci. Reverse proxy aynı ikiliği sunucunun önünde kurar ve istemcinin bağlantı kurduğu, el sıkıştığı taraf odur. İstemci tek istek yaptığını sanır; yolda iki ayrı istek-yanıt çifti oluşur.

Uygulama geçidi bu ikiliği bir adım ileri taşır. Yetkili kullanıcı için hedefe kendi bağlantısını kurar ve veriyi iki bağlantı arasında aktarır. Baktığı yer de IP, TCP ve UDP alanlarıyla sınırlı kalmaz; uygulama verisinin kendisini de okur. Başlık okumak ile içerik okumak arasındaki fark, kutunun hangi katmana kadar indiğini belirler.

Klasik proxy’nin bir bedeli var. İstemci yazılımının kutuya nasıl ulaşacağını bilmesi gerekir, örneğin tarayıcıya proxy’nin adresi elle girilir. Reverse proxy’de bu bedel ortadan kalkar. İstemci hiçbir ayar yapmaz, çünkü kutu zaten adın gösterdiği adreste oturur.

Asıl kırılma TLS tarafında. TLS üç şey sağlar: şifreli bir bağlantı, veri bütünlüğü ve uç nokta kimlik doğrulaması. Üçüncüsü burada can alıcı hâle geliyor, çünkü doğrulanan şey yol değil uç nokta oluyor. 11. bölümdeki el sıkışmada sunucu sertifikasını ve özel anahtarını kullanarak kimliğini kanıtlar ve iki taraf paylaşılan bir sır üretir; istemcinin de sertifika göstermesi isteğe bağlıdır. Özel anahtarı elinde tutan kutu, o oturumun uç noktasıdır. Bu işe TLS sonlandırma deniyor. 12. bölümde sertifika zinciri bir adı doğruluyordu; TLS’i sonlandıran reverse proxy o adın sahibi olarak konuşur.

Vakayı kuralım. İstemci 198.51.100.25 adresinden çıkıyor. Reverse proxy 203.0.113.10 adresinde 443 portunu dinliyor, arkasında 192.0.2.11, 192.0.2.12 ve 192.0.2.13 duruyor. Tek bir HTTPS isteği için yolda 2 ayrı TCP bağlantısı ve 2 ayrı TLS oturumu kurulur. İstemcinin doğruladığı sertifika 203.0.113.10 adresindeki özel anahtara aittir. Arka uçtaki makinenin adını istemci hiç görmez. Kutu arkaya 80 portundan şifresiz bile konuşabilir. Bugünkü güvenlik anlayışında arka taraf da çoğu zaman yeniden şifreleniyor; kutunun trafiği içeride düz metin olarak görmesi ise değişmiyor.

Tek isteğin yolda kaç bağlantıya bölündüğünü görelim:

Arka uç istemcinin kim olduğunu nereden bilecek?

İki bağlantıya bölmenin doğal bir sonucu var ve pratikte ilk gün karşına çıkıyor. Arka uçtaki sunucu, bağlantıyı kuran taraf olarak reverse proxy’yi görüyor. Kayıtlarında tek bir adres birikiyor, coğrafi kısıtlar çalışmıyor, adres başına hız sınırı bütün trafiği tek bir kovaya topluyor.

Çözüm üç ayrı yerde duruyor ve hangisini seçtiğin, proxy’nin hangi katmana kadar indiğine bağlı:

İlk ikisi bir liste tutuyor: her proxy kendi gördüğü adresi sona ekliyor, böylece zincir baştan sona okunabiliyor. Üçüncüsü ise bambaşka bir yerde çalışıyor: bağlantı kurulur kurulmaz, herhangi bir uygulama verisinden önce, tek bir satır hâlinde gerçek adres ve port yazılıyor. Şifreli trafiği hiç açmadan ileten, transport layer’da çalışan bir dengeleyici ancak bunu kullanabiliyor.

Bir güvenlik tuzağı da tam burada. Bu başlıkları istemci de yazabilir; hiçbiri doğrulanmıyor. Arka uç listenin tamamına güvenirse, saldırgan başka bir adresten geliyormuş gibi görünebilir. Kural şu: yalnızca kendi proxy’sinin eklediği son değere güven. Listede ondan öncesi istemciden gelmiş olabilir ve kanıtlanamaz.

Yükü dağıtan kutu neyi gizliyor?

Load balancer’ın işi üç adımdır. Dışarıdan gelen istemci isteklerini alır, işi içeride dağıtır, sonucu dış istemciye döndürür. Dördüncü ve asıl etkisi bu üçünün yanında bir parantez gibi durur: veri merkezinin iç yapısını istemciden gizler.

Kararın nasıl verildiğinin ayrı bir adı var. Application layer routing’i deniyor, çünkü karar IP başlığındaki hedef adresten çıkmıyor; isteğin kendisine bakılıyor. Havuzda üç arka uç varsa ve dağıtım sıra ile yapılıyorsa, 900 istekten her arka uca 300 tanesi düşer.

Sıra ile dağıtmak en basit kural ve tek başına yeterli değil. Kutunun elindeki seçenekler bir merdiven oluşturuyor:

Son satırın bir adı var: oturum yapışkanlığı (session affinity, sahada sık sık sticky session). Arka uç kullanıcının oturumunu kendi belleğinde tutuyorsa, aynı kullanıcının her isteği aynı makineye düşmek zorunda; düşmezse kullanıcı sürekli oturumdan atılır. 14. bölümde durumun sunucudan neden çıkarıldığını gördük; yapışkanlık, o dersi öğrenmemiş bir mimarinin ödediği bedeldir.

Özet almanın da bir tuzağı var. En akla yakın yöntem özet mod N; N arka uç sayısı. Ama havuza bir arka uç eklediğinde N değişiyor ve neredeyse bütün anahtarlar başka bir makineye kayıyor. Tek bir sunucu eklemek bütün oturumları dağıtıyor, bütün önbellekleri soğutuyor.

Çözümün adı tutarlı özetleme. Arka uçları ve anahtarları aynı dairesel uzaya yerleştiriyorsun; bir anahtar, saat yönünde kendisinden sonraki ilk arka uca ait oluyor. Havuza yeni bir arka uç girdiğinde yalnızca onun hemen öncesindeki dilim el değiştiriyor, geri kalan her şey yerinde kalıyor. Taşınan anahtar oranı 1/N’e iniyor. Fikri 1997’de MIT’de Karger ve arkadaşları yayımladı; bir yıl sonra kurulan Akamai’nin temelinde bu çalışma var. Aynı fikir bugün dağıtık önbelleklerde ve veritabanlarında da kullanılıyor.

Bir de kimin havuzda kalacağı sorusu var. Dengeleyici arka uçları düzenli aralıklarla yokluyor; adı sağlık denetimi. Etkin denetimde kutu her birkaç saniyede bir özel bir istek atıp cevabı ölçüyor, edilgen denetimde ise gerçek trafikteki hataları sayıyor. Belirlenen eşiği aşan arka uç havuzdan çıkarılıyor ve düzelince geri alınıyor. Bu mekanizma olmadan dengeleyici, ölmüş bir sunucuya sadakatle istek yollamayı sürdürür.

Bu kutunun var oluş nedeni bir zorluk listesinde geçiyor: yükü yönetmek ve dengelemek, işlem, ağ ve veri darboğazlarından kaçınmak. Load balancer bir ölçek aracıdır. Güvenlik önlemi olarak tasarlanmamıştır; iç yapıyı gizlemesi ondan çıkan bir yan etkidir.

Adın yanıltmasına da izin verme. Cisco’nun GLBP’si gibi ağ geçidi yedekliliği protokollerinde dengeleme tek bir sanal IP adresi ile birden çok sanal MAC adresi üzerinden, ARP cevaplarıyla ve data link layer’da yapılır. Yol üstündeki load balancer ise isteğin kendisine bakıyor. Aynı ad iki ayrı katmanda karşına çıkıyor.

16. bölümdeki içerik dağıtım ağının kenar sunucusunu tanıyorsun ve önbellek isabetinin yolu nasıl kısalttığını da. Sunucuları erişim ağlarının derinine iten o yerleştirme felsefesi, RFC 3234 tanımına göre tam anlamıyla bir ara kutu üretir. Sunucu veri yolunda durur ve router’ın işi olmayan bir iş yapar.

Bu kutuların bir bölümü ağın kendi zayıflığını telafi etmek için orada. IP en iyi çaba modelinde çalışır ve hiçbir garanti vermez; veri merkezleri ile içerik dağıtım ağları istemci ağlarının yakınına yerleştiği için aynı hizmet birden çok noktadan verilebilir hâle gelir. Eksik garantiyi kapatan şey protokolün kendisi değil, yolun üstüne konan kutulardır.

Kasa yazılıma dönünce ne değişti?

Tarihsel model sadeydi. Her ağ işlevi için ayrı bir kutu satın alınırdı: firewall bir kutu, load balancer başka bir kutu, adres çevirici üçüncü bir kutu. İşlev ile kasa aynı şeydi. Başlangıç noktası tescilli ve kapalı donanım çözümleriydi.

Router’ın yekpare kasasında veri düzlemi ile kontrol düzlemi aynı satıcı yazılımında birlikte duruyordu. Yol üstündeki kutular da aynı kalıptaydı. Sonra yön değişti.

Bugün tescilli donanımdan uzaklaşılıyor ve açık bir interface gerçekleyen sade donanıma doğru gidiliyor. Yerel eylemler eşleştir-uygula kalıbıyla programlanabilir hâle geliyor, yenilik de donanımdan yazılıma kayıyor. Ağ işlev sanallaştırmanın (NFV) tanımı buradan çıkıyor: sade donanım üstündeki ağ, hesaplama ve depolama kaynakları üzerinde programlanabilir hizmetler. Load balancer artık bir kasa değil, bir sunucuda çalışan bir süreçtir.

Şimdi geri çekilip resmin tamamına bak. 19. bölümde gördüğümüz gibi internet mimarisinin bilinen adı kum saati modelidir: physical, data link, transport ve application layer’da çok sayıda protokol varken network layer’da yalnızca bir tane vardır. O ince bel IP’dir ve internete bağlı milyarlarca cihazın her birinde gerçeklenmek zorundadır. Belin çevresine sonradan dört kalem birikti: adres çevirisi, ağ işlev sanallaştırma, firewall’lar ve önbellekleme.

Mimarinin üç köşe taşı sayılıyor: yalın bağlanabilirlik, ince bel olarak IP ve zekânın ağın kenarında durması. Sonuncusunun adı end-to-end argument’tır. Beldeki dört kalemin dördü de onu aşındırıyor. İlk ikisine hiçbiri dokunmuyor.

Savın künyesi de belli. 1981’de Saltzer, Reed ve Clark adlandırdı: bir işlev ancak iletişimin uçlarındaki uygulamanın bilgisiyle tam ve doğru gerçeklenebilir. RFC 1958 aynı cümleyi mimarinin merkezine koyuyor: zekâ ağın içinde saklı değildir, uçlardadır. Ama metnin çoğu zaman atlanan bir parantezi var: iletişim sisteminin sağladığı eksik bir sürüm, bir başarım iyileştirmesi olarak bazen yararlı olabilir. Ara kutuların meşruiyeti oradan çıkıyor. Sav ağın içindeki işlevi yasaklamıyor; ona yalnızca son söz hakkı vermiyor.

Özet

• Ara kutu bir cihaz adı taşımaz: tanımı, veri yolunda durup router’ın olağan işleri dışında iş görmektir; ölçüt kasanın markası değil, yapılan işin katmanıdır.
• Beş sınıf tek kalıba iner: adres çevirisi, firewall, load balancer, önbellek ve uygulamaya özgü kutu, hepsi eşleştir-uygula kalıbıyla çalışır.
• Reverse proxy oturumu keser: özel anahtar onda olduğu için tarayıcının doğruladığı ad arkadaki makinenin değil, kutunun kendi adıdır.
• Load balancer bir ölçek aracıdır: isteği alır, işi içeride dağıtır, sonucu döndürür ve bunu yaparken veri merkezinin iç yapısını görünmez kılar.
• Aşınan tek bir köşe taşıdır: belin çevresindeki dört kalem zekânın kenarda durmasını, yani end-to-end argument’ı yıpratır; yalın bağlanabilirliğe ve ince bele dokunmaz.

Beş sınıfın hepsi paketin bir yerine bakıyor ve her biri baktığı yere göre karar veriyor. Peki görmelerini hiç istemiyorsan ne yaparsın?