AWS Client VPN atau bastion untuk mencapai VPC yang di-peering

Satu endpoint Client VPN dapat menjangkau VPC yang di-peering dengan VPC terkaitnya, dan Anda tidak memerlukan bastion agar hal itu sah. Pilihan yang layak diambil adalah di mana lalu lintas berpindah tangan: rute endpoint yang mendarat di subnet asosiasi dan melintasi koneksi peering, atau host di VPC yang di-peering yang mengakhiri sesi. Kedua jalur berfungsi dan gagal di tempat berbeda, jadi keputusannya soal kepemilikan dan audit, bukan soal apa yang diizinkan AWS. Berikut cara saya memilih di antara keduanya, dan empat entri yang membuat jalur ter-rute berhasil.

Dua jalur, satu endpoint, pemilik berbeda

Pada jalur ter-rute, lalu lintas klien mencapai endpoint, diterjemahkan ke alamat antarmuka jaringan Client VPN di subnet asosiasi, dan meninggalkan subnet itu melalui koneksi peering dari A ke B. VPC B tidak mengakhiri sesi VPN apa pun; ia melihat lalu lintas biasa dari VPC A, karena itu rute baliknya menunjuk ke VPC A, bukan ke kumpulan klien.

Pada jalur bastion, klien mencapai host terlebih dahulu. Bastion di A tetap membiarkan lompatan terakhir melintasi koneksi peering, jadi Anda mempertahankan pekerjaan peering dan menambah sesi. Bastion di B juga memerlukan jalur dari klien, dan ketika jalur itu adalah rute endpoint yang sama, Anda memiliki desain ter-rute plus satu lompatan. Bastion hanya menghilangkan pekerjaan ketika sudah ada, sudah disetujui, dan hal di belakangnya memerlukan batas sesi bukan batas jaringan.

Empat entri membuat jalur ter-rute berhasil

AWS mendokumentasikan skenario ini di halaman Client VPN how-it-works, dan dalam praktiknya bermuara pada empat entri yang dimiliki dua atau tiga tim. Rentangnya ilustratif; rentang peering harus unik dan rentang balik harus sesuai rencana Anda.

Rute dan izin adalah kontrol terpisah. Rute endpoint yang benar tanpa aturan otorisasi yang cocok tidak memberi klien apa pun; aturan otorisasi untuk tujuan yang tidak dapat dirutekan endpoint memberinya lubang hitam. Keduanya harus menyebut rentang yang sama.

Rute endpoint menunjuk ke subnet di VPC milik endpoint itu sendiri, tidak pernah ke koneksi peering. Tabel rute VPC menunjuk ke koneksi peering, tidak pernah ke instance atau antarmuka. Menyalin nilai di antara keduanya tersimpan tanpa keluhan dan tidak merutekan apa pun.

Karena subnet asosiasi menerjemahkan sumber klien, B harus merutekan balik ke VPC A, bukan ke kumpulan klien. Mengirim rentang klien melalui koneksi peering tampak simetris, lolos tinjauan, dan gagal diam-diam karena B tidak pernah melihat paket dengan sumber klien.

Grup keamanan dan meter terakhir izin

Perutean membawa paket ke B; B tetap memutuskan. Untuk koneksi peering aktif di region yang sama, grup keamanan di B dapat mereferensikan grup yang diterapkan pada asosiasi Client VPN, yang menjaga aturan tetap sempit dan bertahan terhadap perubahan alamat. Jika referensi grup tidak dapat dilakukan, izinkan rentang subnet asosiasi secara eksplisit alih-alih melebarkannya ke 0.0.0.0/0, yang mengubah kesalahan perutean menjadi timeout tanpa penjelasan.

Lalu periksa apa yang tidak pernah disentuh perutean: ACL jaringan pada kedua subnet, daftar izin atau audiens token aplikasi, dan DNS. Peering tidak menyalin zona ter-hosting privat, jadi laptop dapat menyimpan rute yang berfungsi ke alamat yang tidak dapat ia resolusi, dan koneksi peering tidak menambah kepercayaan pada sertifikat. Arahkan endpoint ke resolver yang menjawab untuk B, lalu pastikan nama privat dan sertifikat cocok.

Kapan bastion adalah jawaban yang jujur

Saya menyimpan tiga pemicu untuk sengaja memilih bastion. VPC yang di-peering milik tim yang tidak akan menambahkan rute balik untuk rentang Anda atau tidak akan menerima referensi grup. Akses harus disetujui atau dicatat per sesi dan aplikasi tidak dapat memikulnya sendiri. Atau lompatan terakhir harus tetap di dalam B karena layanan hanya ter-resolusi di sana dan identitas TLS-nya disematkan ke nama internal.

Tidak satu pun dari itu merupakan jalan pintas dari fakta bahwa peering tidak transitif. Ketidaktertransitifan membatasi apa yang boleh dilakukan sumber daya di B: mereka tidak dapat menggunakan A sebagai transit ke VPC ketiga yang di-peering dengan A. Itu tidak pernah berarti pengguna VPN tidak dapat menjangkau VPC yang di-peering secara langsung, dan bastion yang dibangun untuk menghindari salah baca itu adalah host yang ditambal tanpa alasan.

Kesalahan sebaliknya lebih mahal seiring waktu: alirkan setiap tim melalui satu-satunya bastion yang sudah ada, lalu temukan bahwa grup keamanan, tabel rute, dan jendela tambalnya adalah ketergantungan produksi. Catat pemicu mana yang dilayani host, dan pensiunkan saat pemicunya hilang.

Transit Gateway dan beberapa asosiasi mengubah aritmetika

Jika endpoint terpasang langsung ke Transit Gateway alih-alih ke subnet, modelnya berubah: klien tidak lagi diterjemahkan ke alamat antarmuka di subnet asosiasi, dan tabel rute gateway harus membawa rentang klien plus lampiran yang menuju VPC yang di-peering. Itu lebih bersih dalam skala, tetapi pekerjaannya berpindah dari empat entri ke tabel rute gateway.

Beberapa asosiasi melipatgandakan pemeriksaan. Rute endpoint milik endpoint, namun setiap subnet asosiasi memerlukan tabel rute dengan lompatan berikut peering yang nyata. Sesi dapat berhasil melalui satu asosiasi sementara yang lain tidak memiliki jalur balik, jadi uji masing-masing.

Urutan verifikasi yang menemukan kerusakan dengan cepat

Jalankan ini secara berurutan; setiap langkah dapat lolos sementara langkah berikutnya gagal, dan timeout klien hampir tidak pernah mengatakan mana yang rusak.

1. Resolusi nama aplikasi dari klien dan periksa bahwa alamatnya berada di dalam rentang peering.
2. Sambungkan, lalu baca log koneksi endpoint untuk asosiasi yang mengakhiri sesi.
3. Pada subnet asosiasi itu, pastikan tabel rute mengarahkan rentang peering ke koneksi peering yang aktif.
4. Pada subnet sumber daya di B, pastikan entri balik untuk rentang antarmuka dan aturan grup yang cocok.
5. Uji satu operasi yang diizinkan dan satu sumber daya yang harus tetap tak terjangkau; yang kedua menangkap sisa debugging.
6. Sambungkan ulang setelah setiap perubahan rute split-tunnel, karena tunnel yang berjalan tidak akan mengambil kumpulan rute baru.

Dua gejala layak dihafal. SYN yang mencapai B tanpa balasan hampir selalu rute balik yang hilang. Koneksi yang selesai lalu direset biasanya grup, ACL, atau aplikasi. Keduanya tidak muncul di log endpoint sebagai penyebab, jadi simpan empat entri dengan pemilik di samping masing-masing.

Jika tidak satu pun dari tiga pemicu berlaku, selesaikan jalur ter-rute dan catat keempat entri itu. Jika satu berlaku, pertahankan bastion hanya untuk batas itu dan biarkan rute endpoint untuk layanan yang tidak memerlukan sesi di depannya.