Satu VPN situs-ke-situs untuk beberapa VPC di AWS Transit Gateway

Pasang VPN sekali dan setiap VPC ke satu gateway transit, lalu pisahkan asosiasi dari propagasi agar spoke dapat mencapai kantor tetapi tidak satu sama lain.

Dua VPC membutuhkan jaringan kantor kuartal ini, dan pada terowongan kedua perkiraan itu runtuh. AWS Transit Gateway dapat berperan sebagai hub perutean bersama: VPN dipasang sekali, dan setiap VPC dipasang ke hub yang sama. Jaringan lokal kemudian menjangkau setiap VPC terpasang lewat satu koneksi. Itu mengubah siapa yang memiliki keputusan perutean, dan itulah bagian yang paling sering salah pada desain.

Lampiran VPN dan lampiran VPC adalah objek terpisah pada gateway yang sama, karena itulah hubungan perutean harus dibangun setelahnya.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Mengapa peering bukan jalan pintas yang diharapkan

Alternatif yang menggiurkan adalah mengakhiri VPN di VPC A dan mem-peer VPC B ke sana. Peering VPC biasa tidak menyediakan transit dari tepi ke tepi melalui koneksi VPN A. Peer hanya menjangkau alamat yang disediakan peering itu sendiri, dan tepi VPN bukan salah satunya. Transit adalah yang diberikan hub; peering memberi sepasang.

Batasan itu sifat dari peering, bukan kuota yang bisa dinaikkan.

Asosiasi dan propagasi mengerjakan hal berbeda

Di dalam gateway transit, asosiasi memilih tabel rute yang dipakai untuk mencari lalu lintas yang datang dari lampiran. Propagasi menentukan tabel mana yang menerima prefiks yang dipelajari atau terhubung dari sebuah lampiran. Satu lampiran dapat berasosiasi dengan satu tabel sekaligus menyebar ke beberapa. Mencampuradukkan keduanya adalah cara desain berakhir dengan keterjangkauan yang tidak direncanakan siapa pun.

Hub kecil yang terhubung penuh adalah kasus mudah.

Masukkan setiap lampiran ke satu tabel dan VPN beserta kedua prefiks VPC selesai dengan bersih. Itu juga mengizinkan keterjangkauan antar VPC yang mungkin tidak pernah diniatkan organisasi, karena tabel bersama tidak mengenal konsep spoke.

Rute beban kerja hidup di tempat lain

Setiap subnet beban kerja tetap membutuhkan rute sendiri menuju gateway transit untuk prefiks lokal yang dimaksud. Tabel rute VPC itu adalah objek terpisah dari tabel milik gateway transit sendiri. Tambahkan prefiks yang diperlukan dan pertahankan rute yang ada alih-alih mengganti setiap tujuan dengan default baru. Rute subnet juga tidak mengumumkan apa pun ke perangkat pelanggan.

Pilih perutean dinamis atau statis dengan sengaja; peering tidak menyediakan keduanya.

Isolasi spoke tanpa kehilangan akses lokal

Ketika A dan B sama-sama boleh mencapai kantor tetapi tidak boleh merutekan satu ke yang lain, pisahkan tabelnya. Tabel terasosiasi lampiran VPN memuat prefiks VPC. Tabel terasosiasi lampiran VPC memuat prefiks lokal, tanpa rute yang menyatukan A dengan B. Propagasi yang menghasilkan hubungan itu, jadi Anda tidak perlu menerima setiap asosiasi default.

Ini isolasi perutean, dan ini bukan otorisasi aplikasi.

Grup keamanan, ACL jaringan, firewall host, dan izin tiap layanan sendiri tetap menentukan lalu lintas mana yang diterima. Jika inspeksi diperlukan, rancang jalur yang didukungnya secara eksplisit alih-alih menganggap hub melakukannya.

Apa yang tidak diperbaiki hub

Rencana alamat tetap harus tidak bertumpang tindih, karena hub tidak membiarkan satu prefiks menandai dua beban kerja. Setiap lampiran VPC membutuhkan cakupan Availability Zone yang diharapkan beban kerjanya. Dengan BGP, rute perangkat pelanggan kembali ke setiap prefiks yang diperlukan harus cocok dengan desain dan kebijakan impornya. Pengumuman yang hilang terlihat persis seperti terowongan yang putus.

Koneksi VPN dan gateway transit kini menjadi infrastruktur bersama.

Rencanakan redundansi terowongan, kapasitas perangkat, pemantauan, dan pemeliharaan di sekitar semua VPC yang bergantung alih-alih memperlakukan masing-masing sebagai terhubung mandiri.

Migrasi dari pengaturan virtual private gateway yang ada berhak mendapat rencana eksplisit yang sama. Bangun lampiran dan kebijakannya, pindahkan satu jalur beban kerja yang terkendali, dan konfirmasi hubungan yang diizinkan dan ditolak sebelum memensiunkan jalur lama. Sentralisasi membantu ketika memberi tim jaringan satu tempat untuk mengelola konektivitas bersama, dan merugikan ketika menyembunyikan siapa boleh mencapai siapa di balik satu tabel besar.

Artikel terkait