strongSwan di EC2: biar VPC menghalakan beban kerja

Terowong yang berfungsi dari gateway hanya membuktikan gateway. Halakan subnet beban kerja, aktifkan penghantaran pada tetamu, luaskan pemilih, kemudian uji daripadanya.

Terowong sudah aktif, instans gateway boleh ping rangkaian jauh, dan instans aplikasi di sebelahnya tidak dapat mencapai apa-apa. Tiada apa yang rosak. Ujian yang berjaya bermula pada hos VPN, dan ia tidak pernah bertanya sama ada hos itu boleh membawa alamat sumber yang berbeza melalui hubungan IPsec yang sama. Runbook ini menutup jurang itu dalam empat langkah, mengikut urutan yang memastikan setiap kegagalan kelihatan.

Tulis keempat-empat alamat itu dahulu

Setiap langkah di bawah merujuk kepada ini, jadi isikan untuk akaun anda sendiri sebelum menyentuh jadual laluan.

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 menganggap sambungan IPsec berasaskan dasar yang diluluskan dan berfungsi, serta aliran yang mengekalkan sumber. Ini bukan klien akses jauh ber-NAT yang meminjam satu alamat yang diperuntukkan, dan perbezaan itulah yang menentukan sama ada pemilih perlu diubah.

Langkah 1: beri subnet beban kerja satu laluan

Jadual laluan yang benar-benar bergabung dengan subnet beban kerja memerlukan laluan untuk awalan jauh yang menunjuk ke antara muka rangkaian gateway. Laluan tetamu yang dipasang di dalam instans bukanlah entri dalam jadual laluan AWS itu, dan tiada konfigurasi strongSwan sebanyak mana pun akan menciptanya.

Panduan penghalalan melalui perkakas AWS menerangkan sasaran antara muka rangkaian dan keperluan semakan sumber/destinasi instans yang menghantar. Hadkan perubahan semakan itu kepada peranan gateway, dan biarkan instans aplikasi biasa seperti sedia ada.

Jangan ganti laluan tempatan VPC atau setiap entri sedia ada untuk memberi ruang kepada satu rangkaian yang diluluskan. Periksa apa yang bergabung dan aktif, bukan apa yang ditunjukkan oleh halaman konsol untuk jadual laluan yang tiada siapa gunakan. Dua jadual yang kelihatan serupa boleh mempunyai persatuan yang berbeza. Yang penting ialah jadual yang subnet beban kerja dipasang padanya.

Langkah 2: aktifkan penghantaran pada tetamu

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

Kernel mesti menghantar, dan tembok api hos mesti membenarkan transit. Tambahkan peraturan penghantaran yang dimaksudkan untuk awalan beban kerja dan jauh daripada menerima semuanya, dan sahkan subnet gateway mengekalkan laluan pengangkutan yang boleh digunakan untuk trafiknya sendiri.

Kumpulan keselamatan ialah tempat langkah ini biasanya tersekat. Perkakas perantaraan tidak mewarisi kelakuan rujukan kumpulan keselamatan komunikasi instans langsung, jadi peraturan yang disalin daripada contoh Client VPN terurus mungkin tidak pernah sepadan. Periksa kumpulan keselamatan dan ACL subnet pada laluan sebenar, dalam kedua-dua arah.

Langkah 3: luaskan pemilih kepada sumber sebenar

Dasar yang hanya meliputi 10.60.1.10/32 di sebelah AWS menerangkan kejayaan yang bermula dari gateway tanpa meliputi 10.60.2.20. Laluan ke destinasi jauh tidak meluaskan pemilih trafik, dan itulah separuh kedua kejutan yang sama.

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

Jika reka bentuk yang dipersetujui melindungi seluruh VPC, kedua-dua rakan mesti menerima 10.60.0.0/16 dan 10.90.0.0/24. Jika ia melindungi satu beban kerja, gunakan awalan yang lebih sempit itu dengan sengaja. Walau apa pun, periksa dasar CHILD-SA yang dipasang, kerana konfigurasi yang anda sunting dan rakan yang menyempitkannya secara berbeza bukanlah perjanjian yang sama.

Tapak jauh juga mesti menghalakan balasan untuk sumber VPC yang dikekalkan kembali melalui gateway IPsec yang dimaksudkan. Kekalkan pengecualian NAT yang disokong untuk trafik terlindung di tempat peraturan NAT sumber lain wujud; menterjemah beban kerja yang tidak diluluskan kepada alamat hos yang dibenarkan ialah kontrak identiti yang berbeza, bukan jalan pintas kepada akses yang anda mahukan.

Langkah 4: sahkan, kemudian gulung semula jika perlu

Uji dari beban kerja itu sendiri dengan operasi aplikasi baharu yang dibenarkan, kemudian ulangi dengan destinasi yang sepatutnya dikecualikan. Catat alamat sumber yang dilihat oleh perkhidmatan jauh dan laluan balik yang digunakannya. Ping gateway atau status IKE hijau bukanlah ujian itu.

Jika beban kerja masih gagal sementara gateway berfungsi, undur melalui langkah-langkah mengikut urutan: pemilih, kemudian penghantaran dan kumpulan keselamatan, kemudian jadual laluan yang bergabung. Setiap satu mempunyai gejala yang berbeza, dan meneka akan melangkau yang sebenarnya salah.

Penggulungan semula membalikkan urutan yang sama. Buang laluan subnet beban kerja terakhir, selepas memulihkan pemilih terdahulu, supaya anda tidak meninggalkan subnet yang menunjuk ke gateway yang tidak lagi melindungi sumbernya. Pengehosan sendiri boleh melayani lebih daripada hos gateway apabila kontrak ini kekal, dan Site-to-Site VPN yang diuruskan AWS ialah model operasi berbeza di mana strongSwan mungkin berada di hujung gateway pelanggan.

Artikel berkaitan