Yıldız mı tam örgü mü: hangi VPN topolojisi sitelerinize uyar

İki şube ofisi bütün gün birbiriyle konuşuyor ve aralarındaki tünel başka bir bölgedeki veri merkezi üzerinden dolanıyor. Her istek bu dolambaç için iki kez ödüyor ve dosya eşitleme tuhaf hissettirmeye başlayana kadar kimse fark etmiyor. Topoloji sorusu tam burada başlıyor: hangi diyagramın daha dayanıklı göründüğünde değil, hangi trafik desenine para ödediğinizde. İki tasarım da çalışıyor ve ikisi de farklı biçimlerde, farklı maliyetlerle arızalanıyor.

Her şeyden önce eş ilişkilerini sayın

N site varsa tam örgü N çarpı N eksi bir, ikiye bölünmüş kadar tünel ister; merkez ise N ister. Beş sitede bu ona karşı beş, hâlâ yönetilebilir görünüyor. On beşte bu 105'e karşı on beş oluyor ve fark artık aritmetik değil, kadro sorunu.

Bu ilişkilerin her biri sahip olmanız gereken durum taşır. IPsec'te bu bir güvenlik ilişkisi, kimlik, anahtar veya sertifika, ölü eş algılama ve her uzak önek için en az bir rota demek. WireGuard'da ise her eş için bir ortak anahtar ve AllowedIPs bloğu demek; eş başına daha ucuz ama hiç keşif yok: yeni bir site her hâlükârda mevcut tüm sitelerde yapılandırma değişikliği demek.

Çizim değil, trafik karışımı karar versin

Şube trafiği çoğunlukla merkezi bir ERP ya da dosya kümesine yönelik istekler ise merkez bir taviz değil, doğru biçimdir: trafik zaten oraya gitmek istiyordu ve tek bir politika noktasını denetlemek ikili kural örgüsünden kolaydır. Örgü karmaşıklığını, şubeler birbirleriyle veri alışverişi yaptığında hak eder: iki ofis arasında çoğaltma, siteler arasında ses, bir düzine mühendisin bütün gün açtığı bir CAD paylaşımı.

Zor durumlar arada kalır ve çoğunluk onlardır. Bir organizasyon şemasından tahmin etmek yerine tartışmadan önce ölçün.

Tabloyu kural değil, eşitlik bozucu olarak okuyun. Dört satırdan üçünün aynı yönü göstermesi genellikle tasarımı belirler, bölünme ise hibrit demektir; olgun ağların çoğu zaten eninde sonunda onu işletir.

Merkeze yönlendirmesi söylenmeli

İki çalışan uç-merkez tüneli uçlar arasında erişim yaratmaz. Merkezde IP yönlendirme açık olmalı, her uç ağına bir rota, geçişe izin veren bir güvenlik duvarı kuralı ve dönüş yolu hesaplanmış olmalı; her uçta diğer sitenin öneklerine rota gerekir. Linux merkezde bu net.ipv4.ip_forward=1 ve çifti sessizce düşürmeyen bir FORWARD zinciri, politika tabanlı IPsec'te ise iki uçta da uzak uç alt ağını listeleyen trafik seçicileridir. strongSwan yönlendirme notları çekirdek ve güvenlik duvarı tarafını kapsar, eksik olan katman tam o katman olduğunda. Ucuz bir test: bir uçtan diğerindeki bir servise trafik gönderip merkezin sayaçlarını izlemek; hiç artmayan bir kural rotanın değil sıranın yanlış olduğunu gösterir.

Merkezi politika da işe yarayan kısımdır. Şubelerin birbirine ulaşmadan ortak servislere ulaşmasına izin verilebilir ve bu erişim matrisini açıkça yazmak değerlidir. Eksik rotalar, birinin okuyabileceği bir kuralın kötü bir yerine geçenidir.

Yarısı yapılmış sürüme dikkat: uç A, merkez üzerinden uç B'ye yönleniyor, merkez iki yöne de yönlendiriyor ve merkezin güvenlik duvarı A'dan gelen yeni bağlantılara izin veriyor ama B'den vermiyor. İlk yön sorunsuz test edilir, ikincisi takılır; bu bir yönlendirme arızası gibi görünür ama değildir.

Önce arızayı, sonra normal yolu tasarlayın

Tek merkez ortak bir bağımlılık ve aktarım darboğazıdır; yedeklilik ise merkez tasarımlarının genellikle yanıldığı yerdir. İki merkez, her ucun iki tünel tutması demektir ve dönüş yolu gidiş yoluyla uyuşmalıdır; uyuşmadığında durum tutan bir güvenlik duvarı yanıtları düşürür ve belirti açılıp sonra ölen bir bağlantıdır. Daha büyük kurulumlar bunu statik önekler yerine tüneller üzerinden bir yönlendirme protokolüyle çözer; daha fazla düzenek ama tahmini ortadan kaldırır. Ne seçerseniz seçin, dönüş yolunu gidiş yolunun yanına yazın, çünkü kimsenin test etmediği yarı dönüş yarısıdır.

Örgü bu riski dağıtır: bir sitenin bağlantısının düşmesi diğerlerini yalıtmaz. Ama yol seçiminin sizi şaşırtabileceği yerleri de çoğaltır ve uygulama oturumları hâlâ yardım olmadan bir yol değişikliğini atlatamaz.

Hiçbir tasarım bir TCP oturumunu devir teslim boyunca tek başına ayakta tutmaz. Uygulama yeniden bağlanamıyorsa topoloji sizin sorununuz değildir.

Değişiklik maliyetine göre seçin, sonra rotaları doğrulayın

Merkezle başlayın, çünkü yanlış yapılması daha ucuz olan odur, ve trafiği bunu hak eden çiftler için doğrudan tüneller ekleyin. Bu hibrit karar verememek değildir; çoğu kuruluşun bir yıl içinde vardığı tasarımdır. Önemli olan, her doğrudan bağlantının belirtilmiş bir gerekçesi ve bir sahibi olmasıdır.

Sonra bir değil iki çizimi doğrulayın. Normal yol için her siteden her servis önekine traceroute çalıştırın ve atlamaların diyagramla eşleştiğini doğrulayın. Arıza yolu için bir tüneli kapatın ve tekrarlayın, çünkü yalnızca her şey ayaktayken çalışan bir rota tasarlanmamış, sadece yapılandırılmıştır.

İki çizimi erişim matrisiyle birlikte saklayın ve bir site eklendiğinde gözden geçirin; yönettiğiniz maliyet bir sonraki değişikliğin maliyetidir, mevcut resmin zarafeti değil.