Cara Menghalakan Trafik SaaS ke VPN Pelanggan yang Betul

Platform SaaS bersambung ke sedozen rangkaian pelanggan, dan dua daripada pelanggan itu kedua-duanya menggunakan 10.20.0.10 untuk pangkalan data utama mereka. Pekerja yang menerima alamat itu dalam sesuatu kerja tidak mempunyai cara untuk mengetahui pangkalan data mana yang dimaksudkan oleh kerja itu, dan jadual penghalaan dikongsi akan dengan senang hati menghantarnya ke terowong yang ditunjuk oleh awalan itu. Penyelesaiannya bukan terowong yang lebih banyak; penyelesaiannya ialah memutuskan di mana identiti penyewa masuk ke laluan dan model pengasingan mana yang diperlukan oleh pelan alamat. Tiga syarat menentukan pilihan: sama ada awalan pelanggan bertindih, sejauh mana kesilapan boleh merebak, dan siapa yang mengendalikan penyambung.

Dua pangkalan data pelanggan, satu alamat destinasi

Alamat IP ialah lokasi, bukan identiti. Permintaan mesti membawa penyewa yang telah disahkan oleh pelayan, dan penyewa itu mesti memilih konteks rangkaian sebelum destinasi diselesaikan.

Apabila ia tidak berbuat demikian, kegagalan itu senyap. Sambungan berjaya, pertanyaan dijalankan, dan jawapan datang daripada pangkalan data pelanggan yang salah kerana jadual penghalaan mempunyai satu entri untuk 10.20.0.10. DNS memburukkannya: nama yang dicache yang diselesaikan dalam konteks penyewa A boleh digunakan semula oleh kerja yang berjalan untuk penyewa B. Tiada apa-apa dalam paket yang membezakan kedua-duanya, jadi logik cuba semula tidak membaikinya.

Tentukan model pengasingan dahulu

Tuliskan tiga syarat itu sebelum membandingkan produk. Pertindihan menentukan sama ada satu ruang alamat boleh dikongsi; jejari kesan menentukan sama ada kesilapan penghalaan ialah tiket sokongan atau pelanggaran; pemilikan operasi menentukan sama ada anda boleh mengendalikan armada penyambung bagi setiap penyewa.

Jika awalan berbeza dan dasar membenarkan hab terkawal, satu Transit Gateway dengan jadual penghalaan bagi setiap penyewa adalah boleh dilaksanakan. Persatuan lampiran memilih jadual penghalaan yang digunakan untuk trafik yang masuk daripada lampiran itu, dan penyebaran memilih laluan mana yang muncul dalam jadual. Lampiran penyewa yang diasosiasikan hanya dengan jadualnya sendiri dan menyebarkan hanya awalannya sendiri mencapai hab dan tidak ke tempat lain. Itu keputusan penghalaan, dan ia kekal betul hanya selagi tiada siapa menambah laluan lalai ke jadual dikongsi.

Jika awalan bertindih, penghalaan semata-mata tidak dapat memisahkannya. Anda memerlukan konteks rangkaian berasingan bagi setiap penyewa atau pelan terjemahan yang memberi ruang setiap pelanggan makna yang tidak kabur.

Apa Sebenarnya Pengasingan Transit Gateway

Persatuan dan penyebaran ialah dua tombol yang penting, dan keduanya mudah dikelirukan. Persatuan menjawab dalam jadual mana paket daripada lampiran ini dicari; penyebaran menjawab jadual mana yang mempelajari laluan lampiran ini. Pengasingan datang daripada menjadikan kedua-duanya khusus penyewa, bukan daripada mencipta lebih banyak lampiran.

Persediaan lalai semua-ke-semua itu mudah tetapi bukan pengasingan. Jadual penghalaan berasingan mengehadkan sambungan, tetapi ia tidak memberi satu alamat destinasi yang tidak berubah dua makna dalam konteks penghalaan yang sama. Jika aplikasi menyelesaikan 10.20.0.10 sebelum mengetahui penyewa, lapisan penghalaan sudah kehilangan maklumat yang diperlukan.

AWS menambah NAT 1:1 peringkat lampiran untuk Transit Gateway dan Cloud WAN pada 23 Oktober 2026, yang mengubah jawapan pertindihan untuk lampiran yang disokong. Dokumentasi NAT Transit Gateway menerangkan pemetaan IPv4 statik, tanpa keadaan dan berawalan sama dengan bit hos dipelihara. Semak jenis lampiran yang disokong dan kekangan serantau sebelum mereka bentuk berdasarkannya.

Ikat kerja kepada penyewa yang disahkan

Setiap kerja patut membawa identiti penyewa yang disahkan pelayan, dan identiti itu patut memilih rekod sambungan milik pentadbir. Rekod itu menamakan konteks rangkaian yang diluluskan, alamat perkhidmatan, rujukan kelayakan dan operasi yang dibenarkan di sana. Permintaan yang tidak dipercayai tidak boleh sekali-kali membekalkan pengecam VPN, gerbang atau sasaran peribadinya sendiri, kerana log masuk yang sah bukan kebenaran untuk menyiasat ruang alamat setiap pelanggan yang bersambung.

Dalam reka bentuk penyambung terasing, kerja penyewa A pergi ke penyambung khusus A yang berjalan dalam VPC A dan hanya boleh mencapai sumber A yang diluluskan. Kontena berasingan pada satu hos tidak mencipta pemisahan itu dengan sendirinya; ruang nama rangkaian, laluan dan dasar keluar mesti melaksanakannya. Penyambung juga memerlukan kelayakan dan baris gilir berlingkup penyewa, kerana laluan peribadi tidak mengehadkan rahsia dikongsi atau item kerja dikongsi. Pekerja aplikasi terkumpul adalah baik selagi konteks rangkaian dan kelayakan dipilih bagi setiap penyewa, bukan setiap hos.

Pemeriksaan kesihatan patut menamakan penyewa dan peringkat: terowong ditubuhkan, laluan hadir dan permintaan perkhidmatan sebenar berjaya ialah tiga isyarat berbeza. Kiraan agregat terowong yang aktif akan menyembunyikan pelanggan tunggal yang penyambungnya rosak.

Uji laluan yang mesti gagal

Jalankan tiga ujian sebelum pelancaran. Operasi A yang dibenarkan mesti berjaya, operasi B yang dibenarkan mesti berjaya, dan kerja A yang dihalakan dengan sengaja ke penyambung B atau alias terjemahannya mesti gagal tertutup. Kemudian putuskan satu terowong dan sahkan kerja itu gagal hanya untuk penyewa tersebut, tanpa jatuh ke subnet bernombor sama pelanggan lain. Pemulihan juga patut diuji, kerana laluan basi atau kelayakan yang dicache boleh bertahan lebih lama daripada gangguan.

Seni bina boleh berupakan pekerja terkumpul dengan penyambung terasing, atau sumber penyewa yang benar-benar berasingan. Invariannya sama: konteks penyewa yang disahkan memilih laluan dan kelayakan, dan tiada perubahan laluan pernah memberikan kebenaran aplikasi merentas penyewa.