SaaS trafiğini doğru müşteri VPN'sine nasıl yönlendirirsiniz
Çakışan müşteri alt ağları paylaşılan yönlendirmeyi bozar. Bir yalıtım modeli seçin, her işi doğrulanmış bir kiracıya bağlayın ve başlatmadan önce kiracılar arası yolları test edin.
Bir SaaS platformu bir düzine müşteri ağına bağlanır ve bu müşterilerden ikisi birincil veritabanları için 10.20.0.10 kullanır. Bir işte bu adresi alan çalışanın, işin hangi veritabanını kastettiğini bilmesinin hiçbir yolu yoktur ve paylaşılan bir yönlendirme tablosu onu önekin işaret ettiği tünele memnuniyetle gönderir. Çözüm daha fazla tünel değildir; çözüm, kiracı kimliğinin yola nerede girdiğine ve adres planının hangi yalıtım modelini gerektirdiğine karar vermektir. Seçimi üç koşul belirler: müşteri öneklerinin çakışıp çakışmadığı, bir hatanın ne kadar uzağa yayılabileceği ve bağlayıcıyı kimin işlettiği.
İki müşteri veritabanı, tek hedef adres
Bir IP adresi konumdur, kimlik değildir. İstek, sunucunun doğruladığı bir kiracı taşımalı ve bu kiracı, hedef çözümlenmeden önce ağ bağlamını seçmelidir.
Bu olmadığında hata sessizdir. Bağlantı başarılı olur, sorgu çalışır ve yanıt yanlış müşterinin veritabanından gelir çünkü yönlendirme tablosunda 10.20.0.10 için tek bir giriş vardı. DNS durumu kötüleştirir: kiracı A'nın bağlamında çözülen önbelleğe alınmış bir ad, kiracı B için çalışan bir iş tarafından yeniden kullanılabilir. Paketteki hiçbir şey ikisini ayırt etmez, bu yüzden hiçbir yeniden deneme mantığı bunu düzeltmez.
Önce yalıtım modeline karar verin
Ürünleri karşılaştırmadan önce üç koşulu yazın. Çakışma, tek bir adres alanının paylaşılıp paylaşılamayacağını belirler; etki yarıçapı, bir yönlendirme hatasının destek bileti mi yoksa ihlal mi olduğunu belirler; operasyonel sahiplik, kiracı başına bir bağlayıcı filosu işletip işletemeyeceğinizi belirler.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
Önekler farklıysa ve politika kontrollü bir merkeze izin veriyorsa, kiracı başına yönlendirme tabloları olan tek bir Transit Gateway uygulanabilir. Ek ilişkilendirmesi, o ekten giren trafik için kullanılan yönlendirme tablosunu seçer ve yayılma, bir tabloda hangi rotaların görüneceğini seçer. Yalnızca kendi tablosuyla ilişkilendirilen ve yalnızca kendi öneklerini yayan kiracı ek, merkeze ulaşır ve başka hiçbir yere ulaşmaz. Bu bir yönlendirme kararıdır ve kimse paylaşılan tabloya varsayılan bir rota eklemediği sürece doğru kalır.
Önekler çakışıyorsa, yalnızca yönlendirme onları ayıramaz. Kiracı başına ayrı bir ağ bağlamına veya her müşterinin alanına açık bir anlam veren bir çeviri planına ihtiyacınız var.
Transit Gateway yalıtımı gerçekte ne anlama gelir
İlişkilendirme ve yayılma önemli olan iki ayardır ve karıştırılmaları kolaydır. İlişkilendirme, bu ekten gelen paketin hangi tabloda arandığını yanıtlar; yayılma, hangi tabloların bu ekin rotalarını öğrendiğini yanıtlar. Yalıtım, ikisini de kiracıya özgü yapmaktan gelir, daha fazla ek oluşturmaktan değil.
Varsayılan herkesten herkese kurulumu kullanışlıdır ve yalıtım değildir. Ayrı yönlendirme tabloları bağlantıyı kısıtlar, ancak tek bir değişmemiş hedef adrese aynı yönlendirme bağlamında iki anlam vermez. Uygulama kiracıyı bilmeden önce 10.20.0.10'u çözerse, yönlendirme katmanı ihtiyaç duyacağı bilgiyi zaten kaybetmiştir.
AWS, 23 Ekim 2026'da Transit Gateway ve Cloud WAN için ek düzeyinde 1:1 NAT ekledi; bu, desteklenen ekler için çakışma yanıtını değiştirir. Transit Gateway NAT belgeleri, ana bilgisayar bitleri korunarak statik, durumsuz ve eşit önekli IPv4 eşlemelerini açıklar. Buna göre tasarım yapmadan önce desteklenen ek türlerini ve bölgesel kısıtlamaları kontrol edin.
İşi doğrulanmış bir kiracıya bağlayın
Her iş, sunucu tarafından doğrulanmış bir kiracı kimliği taşımalı ve bu kimlik, yöneticinin sahip olduğu bir bağlantı kaydını seçmelidir. Kayıt, onaylanmış ağ bağlamını, hizmet adresini, kimlik bilgisi referansını ve orada izin verilen işlemleri belirtir. Güvenilmeyen bir istek asla kendi VPN tanımlayıcısını, ağ geçidini veya özel hedefini sağlamamalıdır, çünkü geçerli bir oturum açma, bağlı her müşterinin adres alanını araştırma izni değildir.
Yalıtılmış bağlayıcı tasarımında, kiracı A'nın işi A'ya özgü ve A'nın VPC'sinde çalışan, yalnızca A'nın onaylanmış kaynaklarına ulaşabilen bir bağlayıcıya gider. Tek bir ana bilgisayardaki ayrı kapsayıcılar bu ayrımı kendi başlarına yaratmaz; ağ ad alanları, rotalar ve çıkış politikası bunu uygulamalıdır. Bağlayıcı ayrıca kiracı kapsamlı kimlik bilgilerine ve kuyulara ihtiyaç duyar, çünkü özel bir rota paylaşılan bir sırrı veya paylaşılan bir iş öğesini kapsamaz. Havuzlanmış uygulama çalışanları, ağ bağlamı ve kimlik bilgileri ana bilgisayar başına değil kiracı başına seçildiği sürece sorun değildir.
Sağlık kontrolleri kiracıyı ve aşamayı adlandırmalıdır: tünel kuruldu, rota mevcut ve gerçek bir hizmet isteği başarılı oldu üç farklı sinyaldir. Ayakta olan tünellerin toplam sayısı, bağlayıcısı bozuk olan tek müşteriyi gizleyecektir.
Başarısız olması gereken yolları test edin
Başlatmadan önce üç test çalıştırın. İzin verilen bir A işlemi başarılı olmalı, izin verilen bir B işlemi başarılı olmalı ve kasıtlı olarak B'nin bağlayıcısına veya çevrilmiş takma adına yönlendirilen bir A işi kapalı olarak başarısız olmalıdır. Ardından bir tüneli koparın ve işin yalnızca o kiracı için başarısız olduğunu, başka bir müşterinin aynı numaralı alt ağına düşmediğini doğrulayın. Geri yükleme de test edilmelidir, çünkü eski bir rota veya önbelleğe alınmış kimlik bilgileri kesintiden daha uzun yaşayabilir.
Mimari, yalıtılmış bağlayıcılara sahip havuzlanmış çalışanlar veya tamamen ayrılmış kiracı kaynakları olabilir. Değişmez olan aynıdır: doğrulanmış kiracı bağlamı rotayı ve kimlik bilgilerini seçer ve hiçbir rota değişikliği kiracılar arasında uygulamaya izin vermez.