Menambahkan subnet lokal ke AWS VPN: VGW versus Transit Gateway

VPN Site-to-Site yang ada membawa 10.60.0.0/16, jaringan layanan baru muncul di belakang gateway lokal yang sama sebagai 10.70.0.0/16, dan seseorang bertanya apakah proxy diperlukan. Biasanya tidak: jalur yang dirutekan dapat membawa prefiks itu, tetapi hanya jika tiga hal selaras, dan yang mana tiga bergantung pada arsitektur AWS yang sudah Anda jalankan. Gateway privat virtual punya satu batas tabel rute; transit gateway menambahkan batas kedua. Pengumuman yang benar dengan tabel yang salah menghasilkan sesi yang tampak sehat dan tidak mengirimkan apa pun.

Umumkan prefiks yang benar-benar dapat dikirim oleh gateway

Gateway lokal memerlukan rute kelanjutan ke jaringan baru sebelum pengumuman apa pun bermakna. Mengumumkan 10.70.0.0/16 lewat BGP memberi tahu AWS ke mana paket untuk rentang itu harus dikirim; itu tidak membuat jalur penerusan lokal yang membuat rentang tersebut dapat dijangkau di ujung lain. Pastikan gateway memiliki rute untuk prefiks yang menunjuk ke perangkat yang memegangnya, dan perangkat dikonfigurasi untuk menjawab alamat tersebut. Kebijakan ekspor dan batas prefiks yang diterima adalah kendala berikutnya, karena prefiks yang disaring sesi tidak pernah sampai ke AWS sama sekali.

Jaga agregat dan rute yang lebih spesifik tetap disengaja. Jalur yang tumpang tindih dari dua arah adalah keputusan desain, bukan detail yang ditemukan belakangan.

Jalur satu: batas gateway privat virtual

Dengan gateway privat virtual, dokumentasi perutean AWS VPN menjelaskan dua mode distribusi, rute statis dan pengumuman BGP, dan keduanya bergantung pada tabel rute subnet yang benar-benar dipakai aplikasi. Propagasi nyaman ketika Anda mengendalikan seluruh rentang, dan rute eksplisit lebih mudah dinalar ketika Anda ingin tujuan tercantum di samping target. Bagaimanapun, pemeriksaannya sama: apakah tabel subnet aplikasi yang spesifik memuat jalur yang berfungsi ke target VPN untuk prefiks baru, dan apakah ia menang terhadap apa pun yang lebih spesifik?

Sesi BGP yang sehat membuktikan kanal itu ada. Itu tidak mengatakan apakah tabel subnet tertentu telah mengonsumsi rute tersebut.

Jalur dua: transit gateway menambahkan tabel

Transit gateway membagi satu pertanyaan itu menjadi dua. Subnet VPC harus mengirim tujuan ke lampiran transit gateway, lalu tabel rute transit gateway harus memilih lampiran VPN untuk prefiks yang sama. Pilihan asosiasi dan propagasi menentukan jaringan terlampir mana yang menerima rute, sehingga sebuah prefiks dapat diumumkan dengan benar oleh VPN dan tetap tidak pernah mencapai VPC yang tabelnya tidak pernah diasosiasikan dengan tabel rute yang benar.

Kegagalan umum adalah rute yang ada di satu tabel dan tidak di tabel lain, dengan setiap tim yakin sisinya benar. Ketika Anda membandingkan kedua arsitektur, batas tambahan inilah seluruh perbedaannya: lebih banyak tempat untuk diperiksa, dan kendali lebih presisi atas siapa yang menerima rute.

Propagasi rute juga tidak memberikan prefiks kepada setiap lampiran. Ia mendistribusikannya ke tabel yang dikonfigurasi untuk menerimanya.

Jalur balik adalah keputusan kebijakan tersendiri

Lalu lintas yang masuk hanya separuh pertukaran. Jaringan lokal baru memerlukan rute balik ke prefiks sumber AWS melalui gateway yang tepat, dan kebijakan keamanan di kedua ujung harus mengizinkan pasangan sumber dan tujuan itu. Jika terowongan menegosiasikan cakupan perlindungan dengan pemilih lalu lintas, prefiks baru harus berada di dalamnya, atau paket dibuang sebelum tabel rute mana pun diperiksa.

Tumpang tindih alamat adalah jebakan lainnya. Rentang terpisah yang dimiliki secara eksplisit membuat ini sederhana; rentang yang tumpang tindih berarti translasi atau desain ulang, dan keduanya bukan varian yang dapat dipertukarkan dari resep yang sama.

Uji dengan sumber di jaringan baru dan tujuan di subnet aplikasi, lalu ulangi ke arah sebaliknya. Uji satu arah hanya membuktikan satu arah.

Kapan proxy benar-benar menjadi batas yang lebih baik

Proxy mendapat tempatnya ketika kebutuhan adalah antarmuka layanan yang sempit, ketika aplikasi sudah mengharapkan arsitektur itu, atau ketika jalur jaringan tidak dapat dibuat membawa prefiks tanpa translasi yang tidak Anda inginkan. Itu bukan opsi cadangan untuk entri tabel rute yang tidak diperiksa siapa pun.

Putuskan dalam urutan ini: penerusan lokal, pengumuman, batas tabel, kebijakan balik. Perbaiki yang pertama gagal, dan baru kemudian tanyakan apakah jalur yang dirutekan memang jawaban yang tepat.