strongSwan di EC2: buat VPC merutekan beban kerja

Tunnel sudah aktif, instans gateway dapat melakukan ping ke jaringan jauh, dan instans aplikasi di sebelahnya tidak dapat mencapai apa pun. Tidak ada yang rusak. Uji yang berhasil berasal dari host VPN, dan uji itu tidak pernah menanyakan apakah host tersebut dapat membawa alamat sumber lain melalui hubungan IPsec yang sama. Runbook ini menutup celah itu dalam empat langkah, dengan urutan yang menjaga setiap kegagalan tetap terlihat.

Tuliskan keempat alamat itu lebih dahulu

Setiap langkah di bawah merujuk ke alamat tersebut, jadi isi untuk akun Anda sendiri sebelum menyentuh tabel rute.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Contoh ini mengasumsikan koneksi IPsec berbasis kebijakan yang disetujui dan berfungsi, serta aliran yang mempertahankan sumber. Ini bukan klien akses jarak jauh ber-NAT yang meminjam satu alamat yang diberikan, dan perbedaan itu menentukan apakah selektor harus diubah.

Langkah 1: beri subnet beban kerja sebuah rute

Tabel rute yang benar-benar terkait dengan subnet beban kerja memerlukan jalur untuk prefiks jauh yang menunjuk ke antarmuka jaringan gateway. Rute tamu yang dipasang di dalam instans bukanlah entri dalam tabel rute AWS tersebut, dan tidak ada konfigurasi strongSwan sebanyak apa pun yang akan membuatnya.

Panduan perutean melalui perangkat dari AWS menjelaskan target antarmuka jaringan dan persyaratan pemeriksaan sumber/tujuan instans yang meneruskan. Batasi perubahan pemeriksaan itu pada peran gateway, dan biarkan instans aplikasi biasa apa adanya.

Jangan mengganti rute lokal VPC atau setiap entri yang ada untuk memberi ruang bagi satu jaringan yang disetujui. Periksa apa yang terkait dan aktif, bukan apa yang ditampilkan halaman konsol untuk tabel rute yang tidak digunakan siapa pun. Dua tabel yang terlihat sama bisa memiliki asosiasi berbeda. Yang penting adalah tabel tempat subnet beban kerja terpasang.

Langkah 2: aktifkan penerusan di tamu

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Kernel harus meneruskan, dan firewall host harus mengizinkan transit. Tambahkan aturan penerusan yang dimaksud untuk prefiks beban kerja dan prefiks jauh alih-alih menerima semuanya, dan pastikan subnet gateway tetap memiliki rute transport yang dapat digunakan untuk lalu lintasnya sendiri.

Grup keamanan adalah tempat langkah ini biasanya macet. Perangkat perantara tidak mewarisi perilaku referensi grup keamanan dari komunikasi instans langsung, sehingga aturan yang disalin dari contoh Client VPN terkelola mungkin tidak pernah cocok. Periksa grup keamanan dan ACL subnet pada jalur sebenarnya, di kedua arah.

Langkah 3: perluas selektor ke sumber sebenarnya

Kebijakan yang hanya mencakup 10.60.1.10/32 di sisi AWS menjelaskan keberhasilan yang berasal dari gateway tanpa mencakup 10.60.2.20. Rute menuju tujuan jauh tidak memperluas selektor lalu lintas, dan itulah paruh kedua dari kejutan yang sama.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Jika desain yang disepakati melindungi seluruh VPC, kedua peer harus menerima 10.60.0.0/16 dan 10.90.0.0/24. Jika melindungi satu beban kerja, gunakan prefiks yang lebih sempit itu dengan sengaja. Bagaimanapun, periksa kebijakan CHILD-SA yang terpasang, karena konfigurasi yang Anda ubah dan peer yang menyempitkannya secara berbeda bukanlah kesepakatan yang sama.

Situs jauh juga harus merutekan balasan untuk sumber VPC yang dipertahankan kembali melalui gateway IPsec yang dimaksud. Pertahankan pengecualian NAT yang didukung untuk lalu lintas terlindungi di tempat ada aturan NAT sumber lain; menerjemahkan beban kerja yang tidak disetujui menjadi alamat host yang diizinkan adalah kontrak identitas yang berbeda, bukan jalan pintas menuju akses yang Anda inginkan.

Langkah 4: verifikasi, lalu kembalikan jika perlu

Uji dari beban kerja itu sendiri dengan operasi aplikasi baru yang diizinkan, lalu ulangi dengan tujuan yang seharusnya dikecualikan. Catat alamat sumber yang dilihat layanan jauh dan jalur balik yang digunakannya. Ping gateway atau status IKE hijau bukanlah uji tersebut.

Jika beban kerja masih gagal sementara gateway berfungsi, telusuri kembali langkah-langkahnya secara berurutan: selektor, lalu penerusan dan grup keamanan, lalu tabel rute terkait. Masing-masing punya gejala berbeda, dan menebak akan melewati yang sebenarnya salah.

Pengembalian membalik urutan yang sama. Hapus rute subnet beban kerja terakhir, setelah memulihkan selektor sebelumnya, agar tidak meninggalkan subnet yang menunjuk ke gateway yang tidak lagi melindungi sumbernya. Hosting sendiri dapat melayani lebih dari host gateway ketika kontrak ini terpenuhi, dan Site-to-Site VPN yang dikelola AWS adalah model operasi berbeda tempat strongSwan dapat berada di ujung gateway pelanggan.