Cara Merutekan Lalu Lintas SaaS ke VPN Pelanggan yang Tepat

Platform SaaS terhubung ke selusin jaringan pelanggan, dan dua dari pelanggan tersebut sama-sama menggunakan 10.20.0.10 untuk basis data utama mereka. Worker yang menerima alamat itu dalam sebuah pekerjaan tidak punya cara untuk mengetahui basis data mana yang dimaksud pekerjaan, dan tabel perutean bersama akan dengan senang hati mengirimnya ke tunnel mana pun yang ditunjuk prefiks. Solusinya bukan lebih banyak tunnel; solusinya adalah memutuskan di mana identitas penyewa masuk ke jalur dan model isolasi mana yang dibutuhkan rencana alamat. Tiga kondisi menentukan pilihan: apakah prefiks pelanggan tumpang tindih, seberapa jauh kesalahan dapat menyebar, dan siapa yang mengoperasikan konektor.

Dua basis data pelanggan, satu alamat tujuan

Alamat IP adalah lokasi, bukan identitas. Permintaan harus membawa penyewa yang telah diverifikasi server, dan penyewa itu harus memilih konteks jaringan sebelum tujuan diresolusi.

Bila tidak, kegagalannya senyap. Koneksi berhasil, kueri berjalan, dan jawabannya datang dari basis data pelanggan yang salah karena tabel perutean hanya punya satu entri untuk 10.20.0.10. DNS memperburuknya: nama yang di-cache yang diresolusi dalam konteks penyewa A dapat dipakai ulang oleh pekerjaan yang berjalan untuk penyewa B. Tidak ada yang membedakan keduanya di dalam paket, jadi logika percobaan ulang sebanyak apa pun tidak memperbaikinya.

Putuskan model isolasi lebih dulu

Tuliskan ketiga kondisi sebelum membandingkan produk. Tumpang tindih menentukan apakah satu ruang alamat dapat dibagi sama sekali; radius dampak menentukan apakah kesalahan perutean adalah tiket dukungan atau pelanggaran; kepemilikan operasional menentukan apakah Anda dapat menjalankan armada konektor per penyewa.

Jika prefiks berbeda dan kebijakan mengizinkan hub terkendali, satu Transit Gateway dengan tabel perutean per penyewa dapat dilakukan. Asosiasi lampiran memilih tabel perutean yang dipakai untuk lalu lintas yang masuk dari lampiran itu, dan propagasi memilih rute mana yang muncul di sebuah tabel. Lampiran penyewa yang hanya diasosiasikan dengan tabelnya sendiri dan hanya mempropagasikan prefiksnya sendiri mencapai hub dan tidak ke tempat lain. Itu keputusan perutean, dan hanya tetap benar selama tidak ada yang menambahkan rute default ke tabel bersama.

Jika prefiks tumpang tindih, perutean saja tidak dapat memisahkannya. Anda memerlukan konteks jaringan berbeda per penyewa atau rencana penerjemahan yang memberi ruang setiap pelanggan makna yang tidak ambigu.

Apa Arti Isolasi Transit Gateway Sebenarnya

Asosiasi dan propagasi adalah dua tombol yang penting, dan keduanya mudah tertukar. Asosiasi menjawab di tabel mana paket dari lampiran ini dicari; propagasi menjawab tabel mana yang mempelajari rute lampiran ini. Isolasi berasal dari membuat keduanya spesifik penyewa, bukan dari membuat lebih banyak lampiran.

Pengaturan default semua-ke-semua itu nyaman dan bukan isolasi. Tabel perutean terpisah membatasi konektivitas, tetapi tidak memberi satu alamat tujuan yang tidak berubah dua makna di dalam konteks perutean yang sama. Jika aplikasi meresolusi 10.20.0.10 sebelum mengetahui penyewanya, lapisan perutean sudah kehilangan informasi yang dibutuhkannya.

AWS menambahkan NAT 1:1 tingkat lampiran untuk Transit Gateway dan Cloud WAN pada 23 Oktober 2026, yang mengubah jawaban tumpang tindih untuk lampiran yang didukung. Dokumentasi NAT Transit Gateway menjelaskan pemetaan IPv4 statis, tanpa status, dan berprefiks sama dengan bit host dipertahankan. Periksa jenis lampiran yang didukung dan batasan regional sebelum merancang di sekitarnya.

Ikat pekerjaan ke penyewa yang terverifikasi

Setiap pekerjaan harus membawa identitas penyewa yang diverifikasi server, dan identitas itu harus memilih catatan koneksi milik administrator. Catatan itu menyebut konteks jaringan yang disetujui, alamat layanan, referensi kredensial, dan operasi yang diizinkan di sana. Permintaan yang tidak tepercaya tidak boleh pernah memasok pengenal VPN, gateway, atau target privatnya sendiri, karena login yang valid bukan izin untuk menyelidiki ruang alamat setiap pelanggan yang terhubung.

Dalam desain konektor terisolasi, pekerjaan penyewa A pergi ke konektor khusus A yang berjalan di VPC A dan hanya dapat menjangkau sumber daya A yang disetujui. Kontainer terpisah pada satu host tidak menciptakan pemisahan itu dengan sendirinya; ruang nama jaringan, rute, dan kebijakan keluar harus menerapkannya. Konektor juga memerlukan kredensial dan antrean berlingkup penyewa, karena rute privat tidak membatasi rahasia bersama atau item kerja bersama. Worker aplikasi yang dikumpulkan baik-baik saja selama konteks jaringan dan kredensial dipilih per penyewa, bukan per host.

Pemeriksaan kesehatan harus menyebut penyewa dan tahapannya: tunnel terbentuk, rute ada, dan permintaan layanan nyata berhasil adalah tiga sinyal berbeda. Jumlah agregat tunnel yang menyala akan menyembunyikan satu pelanggan yang konektornya rusak.

Uji jalur yang harus gagal

Jalankan tiga pengujian sebelum peluncuran. Operasi A yang diizinkan harus berhasil, operasi B yang diizinkan harus berhasil, dan pekerjaan A yang sengaja diarahkan ke konektor B atau alias terjemahannya harus gagal tertutup. Lalu putuskan satu tunnel dan pastikan pekerjaan gagal hanya untuk penyewa itu, tanpa jatuh ke subnet bernomor sama milik pelanggan lain. Pemulihan juga harus diuji, karena rute basi atau kredensial yang di-cache dapat bertahan lebih lama dari gangguan.

Arsitekturnya dapat berupa worker yang dikumpulkan dengan konektor terisolasi, atau sumber daya penyewa yang sepenuhnya terpisah. Invariannya sama: konteks penyewa terverifikasi memilih rute dan kredensial, dan tidak ada perubahan rute yang pernah memberikan izin aplikasi antarpenyewa.