Pemeriksaan sumber/tujuan adalah satu gerbang, bukan seluruh jalur VPN
Instance penerusan membutuhkan izin AWS serta rute Linux dan aturan firewall. Periksa validasi sumber/tujuan pada instance yang meneruskan.
VPN berakhir pada instance EC2, Anda dapat menjangkau alamat terowongan instance itu, dan lalu lintas yang seharusnya melewatinya menuju host privat lain menghilang. Itu dua pengujian berbeda, dan mencampurnya membuang waktu berjam-jam. Yang pertama bertanya apakah Anda dapat menjangkau instance; yang kedua memintanya meneruskan lalu lintas untuk tujuan yang bukan miliknya, yang membutuhkan penerusan Linux, kebijakan firewall, rute di sisi jauh, dan izin tingkat AWS yang tidak ada hubungannya dengan sistem operasi tamu. Tidak ada apa pun di konsol yang menarik perhatian pada perbedaan itu. Gejalanya tampak seperti kesalahan perutean, dan biasanya bukan.
Pisahkan kedua pengujian sebelum mengubah apa pun
Menjangkau gateway membuktikan terowongan, rute ke alamatnya, dan grup keamanan yang mengizinkan pertukaran. Penerusan untuk host lain tidak membuktikan satu pun dari itu: ia memakai alamat sumber berbeda, tujuan berbeda, dan instance dalam peran yang belum tentu dibangun untuknya. Tulis kedua pengujian secara terpisah dan catat mana yang gagal, karena perbaikan masing-masing berada di konsol yang berbeda. Instance gateway yang dibangun hanya untuk mengakhiri terowongan tidak punya alasan meneruskan untuk hal lain, dan nilai bawaannya mencerminkan itu. Karena itu pengujian kedua membutuhkan penyiapannya sendiri, bukan penyesuaian kecil pada yang pertama.
Ping yang berhasil ke gateway dan ping yang gagal ke host di baliknya bukan masalah berkala. Itu perilaku yang diharapkan dari instance yang belum diberi tahu bahwa ia boleh meneruskan.
Tuliskan jalurnya sebelum menyentuh pengaturan
Catat prefiks klien, instance atau antarmuka jaringan penerusan, subnet tujuan, dan rute balasan. Entri tabel rute VPC yang menunjuk ke instance tidak mengonfigurasi sistem operasi instance untuk meneruskan, dan kernel tamu dengan penerusan aktif tidak membuat rute VPC. Kedua ujung hubungan itu harus ada, dan keduanya diedit di tempat berbeda oleh orang dengan akses berbeda.
Lalu periksa pengaturan pemeriksaan sumber/tujuan pada komponen penerusan yang sebenarnya, bukan pada setiap instance di VPC. AWS mendokumentasikan mengapa instance yang meneruskan lalu lintas untuk orang lain perlu menonaktifkan pemeriksaan itu, dan juga mengapa pengaturan itu keputusan per instance, bukan nilai bawaan seluruh VPC.
Empat batas, dan pemeriksaan hanya salah satunya
Perlakukan jalur sebagai empat pertanyaan dan jawab berurutan. Jawaban pertama yang gagal adalah tempat pekerjaannya, dan tidak satu pun dari yang lain akan menutupinya.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Urutannya penting karena memeriksanya murah: rute terlihat di satu halaman, pemeriksaan adalah satu atribut, dan pendapat tujuan biasanya hal terakhir yang ditanyakan orang.
Penerjemahan mengubah sumber mana yang dilihat tujuan
Desain dengan perutean mempertahankan alamat sumber klien, jadi tujuan membutuhkan rute balik ke prefiks klien. Desain yang diterjemahkan justru menyajikan alamat gateway, yang menghapus persyaratan itu dan menggantinya dengan tabel status di gateway. Putuskan sesuai arsitektur yang Anda maksud, bukan menambahkan penerjemahan karena contoh yang tidak terkait memakainya dan tampak berhasil.
Jika Anda menerjemahkan, batasi aturannya pada prefiks klien dan tujuan yang dimaksud. Jika Anda mempertahankan, pastikan sisi jauh benar-benar mengetahui rute itu, bukan mengasumsikan akan mempelajarinya.
Uji dari klien asli, lalu pertahankan perubahan
Permintaan yang dibuat di gateway bisa berhasil sementara permintaan yang diteruskan gagal, karena sumbernya berbeda dan kasus penerusannya berbeda. Setelah koreksi yang tertarget, ulangi pengujian klien-ke-sumber-daya yang persis gagal itu, dari klien yang sama, dan pastikan balasannya kembali, bukan hanya bahwa permintaannya sampai.
Terakhir, masukkan pengaturan itu ke konfigurasi terkelola gateway agar instance pengganti menerimanya. Pengujian yang berhasil yang bergantung pada pengecualian manual adalah pengujian yang kedaluwarsa pada pembangunan ulang berikutnya, dan orang yang menemukannya tidak akan ada di sana untuk mengingat alasannya.