IPsec di dalam IPsec: alamat mana yang harus dibawa terowongan luar

IPsec bersarang lebih mudah dipikirkan ketika kedua lapisan berakhir di mesin berbeda. Empat gateway, dua terowongan, dan satu pertanyaan yang menentukan apakah desainnya bekerja: apa yang sebenarnya dilihat terowongan luar ketika terowongan dalam selesai dengan paketnya? Jawab itu dan selector, rute, serta urutan pemecahan masalah mengikuti. Salah, dan Anda akan menghabiskan sehari men-debug terowongan yang secara teknis menyala.

Model empat gateway

Gateway luar A dan B membangun terowongan pertama antara dua situs. Di belakang A ada gateway dalam C dengan alamat transit 10.60.0.2; di belakang B ada gateway dalam D dengan alamat transit 10.70.0.2. Jaringan aplikasi berada di belakang C dan D, dan setiap alamat dalam contoh sengaja tidak tumpang tindih.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Membagi lapisan ke empat host berarti setiap mesin menegakkan satu batas. Satu host yang menjalankan kedua lapisan harus menyelaraskan dua set kebijakan, dua tabel rute, dan dua mode kegagalan pada satu mesin, yang mungkin dan jauh lebih sulit diamati.

Setiap lapisan hanya melepas perlindungannya sendiri

C mengenkripsi paket aplikasi untuk D. Hasilnya dialamatkan dari C ke D, dan itulah yang sampai ke A. Semua yang di hilir bergantung pada penulisan ulang itu.

A mengenkripsinya lagi untuk B. B mendekripsi lapisan luar, melihat paket dari C ke D, dan meneruskannya masih terenkripsi. D melepas perlindungan dalam dan mengantarkan paket aplikasi.

Jadi A dan B melihat titik akhir dalam dan metadatanya, tetapi bukan pihak yang mendekripsi muatan aplikasi. Itu sifat nyata dari desain, bukan klaim bahwa C, D, atau host aplikasi dapat dipercaya.

Selector luar menyebut gateway dalam

Di sinilah sebagian besar bangunan seperti ini gagal. Untuk terowongan luar berbasis kebijakan, selector yang Anda negosiasikan harus memuat alamat yang benar-benar ditangani A dan B: 10.60.0.2/32 dan 10.70.0.2/32, dalam urutan lokal dan jarak jauh yang benar.

Menaruh subnet aplikasi final di selector luar tidak berhasil, karena saat paket mencapai A, enkapsulasi dalam sudah menulis ulang apa yang harus dilindungi A. Kebijakan luar kemudian tidak akan cocok dengan apa pun, dan terowongan akan naik tanpa membawa data.

Jangan mempersempit izin luar ke UDP 500. Koneksi dalam punya jalur datanya sendiri, yang memakai ESP atau enkapsulasi UDP tergantung apa yang dinegosiasikan, dan kebijakan luar harus mengizinkan protokol itu.

Periksa hasilnya dengan swanctl --list-sas di setiap gateway dan pastikan asosiasi keamanan anak melaporkan alamat yang Anda maksud, bukan yang Anda asumsikan. Jika daftar menunjukkan subnet aplikasi, kebijakan luar ditulis untuk lapisan yang salah. Perbaiki selector sebelum men-debug perutean, karena perutean akan terlihat baik dan penghitung tidak akan bergerak.

Penerusan dan jebakan rekursi

Selector tidak menggantikan perutean. A dan B harus meneruskan lalu lintas antara C dan D di kedua arah, yang berarti penerusan IP aktif, rute yang menunjuk ke terowongan, dan jalur balik yang ada di sisi jauh.

Jika terowongan luar memakai antarmuka XFRM, rute memilih antarmuka sementara kebijakan yang dinegosiasikan masih membatasi apa yang dibawanya. Antarmuka tidak memperluas apa yang dilindungi; ia hanya mengubah bagaimana kernel mengambil paket.

Jebakannya adalah rekursi. Rute A ke titik akhir luar B harus mengikuti jaringan dasar, bukan terowongan yang sedang dibangun A, jika tidak enkapsulasi mencoba berjalan di dalam dirinya sendiri dan koneksi tidak pernah selesai.

Periksa terjemahan sebelum menambah lapisan

Lihat NAT sumber apa pun pada A dan B sebelum Anda menyetel hal lain. Aturan yang menulis ulang alamat C sebelum kebijakan IPsec berlaku dapat merusak selector yang disepakati, dan juga dapat mengubah apa yang diterima D di sisi lain.

Penyamaran yang luas tidak menjadi lebih aman karena ada dua lapisan. Ia menyembunyikan alamat mana yang dilihat sisi jauh, dan itulah tepatnya informasi yang Anda butuhkan ketika terowongan menyala dan aplikasi tidak.

Jika aturan NAT benar-benar diperlukan, tuliskan alamat mana yang dianggap masing-masing pihak sedang diajak bicara. Satu baris itu menyelesaikan sebagian besar perdebatan tentang apakah terowongan atau terjemahan yang salah. Itu juga memberi tahu insinyur berikutnya ke mana harus melihat ketika aturan dihapus setahun kemudian. Ping tidak akan melakukan semua itu.

Buktikan fail-closed dan periksa MTU

Rute yang hilang bukanlah kebijakan fail-closed dengan sendirinya. Tabel lain, rute default, atau aturan kebijakan dapat diam-diam memberi jalur cadangan, dan satu-satunya cara untuk tahu adalah menurunkan terowongan luar dan mengamati apa yang dilakukan lalu lintas aplikasi. Lakukan dengan sengaja, dalam jendela pemeliharaan, bukan menemukannya secara kebetulan.

Uji tiga keadaan: terowongan luar mati, terowongan dalam mati, dan pemulihan setelah keduanya kembali. Gunakan penghitung kebijakan di setiap gateway, karena dua sesi IKE yang terbentuk hanya membuktikan bahwa negosiasi bidang kendali berhasil.

Anggarkan kedua enkapsulasi. IKE yang berfungsi adalah hasil paket kecil, dan paket aplikasi ukuran penuh masih bisa gagal setelah dua header ditambahkan; uji dengan ukuran muatan yang diketahui di jalur nyata alih-alih menganggap angkanya bertambah. Aritmetikanya mudah, jalurnya tidak.