SaaS trafikini düzgün müştəri VPN-inə necə yönləndirmək olar
Üst-üstə düşən müştəri alt şəbəkələri ortaq marşrutlaşdırmanı pozur. İzolyasiya modeli seçin, hər işi təsdiqlənmiş tenantla əlaqələndirin və işə salmadan əvvəl tenantlar arası yolları sınayın.
SaaS platforması on iki müştəri şəbəkəsinə qoşulur və həmin müştərilərdən ikisi ilkin verilənlər bazası üçün 10.20.0.10 ünvanından istifadə edir. İşdə bu ünvanı alan worker hansı verilənlər bazasının nəzərdə tutulduğunu deyə bilmir və ortaq marşrut cədvəli paketi prefiksin göstərdiyi tunelə həvəslə göndərir. Həll daha çox tunel deyil; tenant kimliyinin yola harada daxil olduğunu və ünvan planının hansı izolyasiya modelini tələb etdiyini qərarlaşdırmaqdır. Üç şərt seçimi həll edir: müştəri prefikslərinin üst-üstə düşüb-düşməməsi, səhvin nə qədər yayıla biləcəyi və konnektoru kimin idarə etdiyi.
İki müştəri verilənlər bazası, bir təyinat ünvanı
IP ünvanı yer, kimlik deyil. Sorğu serverin təsdiqlədiyi tenantı daşımalı və həmin tenant təyinat həll edilməzdən əvvəl şəbəkə kontekstini seçməlidir.
Bu olmadıqda nasazlıq səssizdir. Bağlantı uğur qazanır, sorğu işləyir və cavab yanlış müştərinin verilənlər bazasından gəlir, çünki marşrut cədvəlində 10.20.0.10 üçün bir giriş var idi. DNS vəziyyəti pisləşdirir: tenant A kontekstində həll olunmuş keşlənmiş ad tenant B üçün işləyən iş tərəfindən təkrar istifadə edilə bilər. Paketdə heç nə ikisini fərqləndirmir, ona görə də heç bir təkrar cəhd məntiqi bunu bərpa etmir.
Əvvəlcə izolyasiya modelini qərarlaşdırın
Məhsulları müqayisə etməzdən əvvəl üç şərti yazın. Üst-üstə düşmə bir ünvan fəzasının ümumiyyətlə paylaşıla biləcəyini; təsir radiusu marşrut səhvinin dəstək bileti yoxsa pozuntu olduğunu; əməliyyat sahibliyi isə tenant başına konnektor donanması idarə edə biləcəyinizi həll edir.
| 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 |
Prefikslər fərqlidirsə və siyasət idarə olunan hub-a icazə verirsə, tenant başına marşrut cədvəlləri olan bir Transit Gateway işləkdir. Qoşma assosiasiyası həmin qoşmadan daxil olan trafik üçün istifadə olunan marşrut cədvəlini seçir, yayılma isə hansı marşrutların cədvəldə görünəcəyini seçir. Yalnız öz cədvəli ilə əlaqələndirilmiş və yalnız öz prefikslərini yayan tenant qoşması hub-a çatır və başqa heç nəyə. Bu marşrut qərarıdır və yalnız heç kim ortaq cədvələ default marşrut əlavə etmədikcə düzgün qalır.
Prefikslər üst-üstə düşürsə, təkcə marşrutlaşdırma onları ayıra bilməz. Ya tenant başına fərqli şəbəkə konteksti, ya da hər müştərinin fəzasına birmənalı məna verən tərcümə planı lazımdır.
Transit Gateway izolyasiyası əslində nə deməkdir
Assosiasiya və yayılma vacib olan iki düymədir və onları qarışdırmaq asandır. Assosiasiya bu qoşmadan gələn paketin hansı cədvəldə axtarılacağını cavablandırır; yayılma isə hansı cədvəllərin bu qoşmanın marşrutlarını öyrəndiyini cavablandırır. İzolyasiya hər ikisini tenant üçün xüsusi etməkdən gəlir, daha çox qoşma yaratmaqdan deyil.
Default hamı-hamıya quruluşu rahatdır və izolyasiya deyil. Ayrı marşrut cədvəlləri bağlantını məhdudlaşdırır, lakin bir dəyişməz təyinat ünvanına eyni marşrutlaşdırma konteksti daxilində iki məna vermir. Tətbiq tenantı bilməzdən əvvəl 10.20.0.10 ünvanını həll edirsə, marşrut qatı artıq lazım olan məlumatı itirmiş olur.
AWS 23 oktyabr 2026-cı ildə Transit Gateway və Cloud WAN üçün qoşma səviyyəsində 1:1 NAT əlavə etdi və bu, dəstəklənən qoşmalar üçün üst-üstə düşmə cavabını dəyişir. Transit Gateway NAT sənədləri host bitləri qorunmaqla statik, vəziyyətsiz, bərabər prefiksli IPv4 xəritələmələrini təsvir edir. Bunun ətrafında dizayn etməzdən əvvəl dəstəklənən qoşma növlərini və regional məhdudiyyətləri yoxlayın.
İşi təsdiqlənmiş tenantla əlaqələndirin
Hər iş server tərəfindən təsdiqlənmiş tenant kimliyi daşımalı və bu kimlik administratorun sahib olduğu bağlantı qeydini seçməlidir. Qeyd təsdiqlənmiş şəbəkə kontekstini, xidmət ünvanını, etimad məlumatı istinadını və orada icazə verilən əməliyyatları göstərir. Etibarsız sorğu heç vaxt öz VPN identifikatorunu, gatewayini və ya şəxsi hədəfini təqdim etməməlidir, çünki etibarlı giriş hər qoşulmuş müştərinin ünvan fəzasını yoxlamaq icazəsi deyil.
İzolyasiya edilmiş konnektor dizaynında tenant A-nın işi A-nın VPC-də işləyən və yalnız A-nın təsdiqlənmiş resurslarına çata bilən A-ya xas konnektora gedir. Bir hostda ayrı konteynerlər bu ayrılığı özlüyündə yaratmır; şəbəkə ad fəzaları, marşrutlar və çıxış siyasəti bunu tətbiq etməlidir. Konnektor həmçinin tenantla məhdud etimad məlumatları və növbələr tələb edir, çünki şəxsi marşrut ortaq sirri və ya ortaq iş elementini məhdudlaşdırmır. Hovuzlanmış tətbiq workerləri, şəbəkə konteksti və etimad məlumatları host başına deyil, tenant başına seçildiyi müddətcə yaxşıdır.
Sağlamlıq yoxlamaları tenantı və mərhələni adlandırmalıdır: tunelin qurulması, marşrutun mövcudluğu və real xidmət sorğusunun uğuru üç fərqli siqnaldır. İşləyən tunellərin ümumi sayı konnektoru sınıq olan yeganə müştərini gizlədəcək.
Uğursuz olmalı yolları sınayın
İşə salmadan əvvəl üç test keçirin. İcazəli A əməliyyatı uğur qazanmalı, icazəli B əməliyyatı uğur qazanmalı və qəsdən B-nin konnektoruna və ya tərcümə edilmiş aliasına yönəldilmiş A işi qapalı şəkildə uğursuz olmalıdır. Sonra bir tuneli qırın və işin yalnız həmin tenant üçün uğursuz olduğunu, başqa müştərinin eyni nömrəli alt şəbəkəsinə düşmədiyini təsdiqləyin. Bərpa da sınanmalıdır, çünki köhnə marşrut və ya keşlənmiş etimad məlumatı kəsintidən uzun yaşaya bilər.
Arxitektura izolyasiya edilmiş konnektorlarla hovuzlanmış workerlər və ya tam ayrılmış tenant resursları ola bilər. Dəyişməz olan eynidir: təsdiqlənmiş tenant konteksti marşrutu və etimad məlumatlarını seçir və heç bir marşrut dəyişikliyi tenantlar arasında tətbiq icazəsi vermir.