strongSwan ESP-in-UDP: saat tidak ada NAT untuk dideteksi

Deteksi NAT menjawab satu pertanyaan: apakah alamat atau port berubah di perjalanan? Ia tidak menjawab apakah firewall mengizinkan protokol IP 50. Gateway situs tanpa penerjemahan apa pun masih bisa berada di balik kebijakan yang membuang native ESP, dan persyaratan itu harus dikonfigurasi, bukan ditemukan. Mekanismenya adalah ESP-in-UDP, dan itu keputusan, bukan cadangan yang muncul sendiri.

Deteksi adalah aritmetika pada alamat, bukan pemeriksaan firewall

IKEv2 membawa muatan deteksi NAT yang berisi hash alamat dan port sumber serta tujuan. Setiap sisi membandingkan yang diterimanya dengan yang terlihat secara lokal, dan ketidakcocokan memberitahunya bahwa sesuatu menerjemahkan paket itu. Tidak ada dalam pertukaran itu yang menguji apakah router di tengah meneruskan protokol 50.

Konsekuensi praktisnya layak dikatakan terus terang. Tunnel yang bekerja dengan native ESP tidak akan menemukan sendiri firewall baru yang membatasi, dan upaya berikutnya gagal pada tahap data sementara IKE terus berhasil. Anda akan melihat asosiasi keamanan IKE yang terbentuk dan tidak ada lalu lintas terlindungi, yang tampak seperti kesalahan perutean sampai Anda menangkap di kabel.

Enkapsulasi karena itu adalah sifat koneksi yang Anda konfigurasikan, bukan hasil yang dinegosiasikan para peer dari perilaku jaringan.

Bagaimana encap mengubah pertukaran

Dalam penyebaran strongSwan modern yang dikelola melalui swanctl.conf, pengaturan encap = yes pada koneksi memengaruhi pertukaran deteksi NAT sehingga kedua peer menggunakan enkapsulasi UDP untuk ESP. Paket yang dilindungi lalu berjalan di dalam UDP, biasanya pada port 4500, dan kedua ujung harus menyepakati susunan itu.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Fragmen itu berada di dalam definisi koneksi nyata dan bukan profil situs yang lengkap. Pertahankan alamat peer, autentikasi, dan pemilih lalu lintas child yang sudah Anda jalankan; satu kunci yang ditambahkan mengubah cara data terlindungi dibungkus, bukan apa yang dilindunginya.

Panduan strongSwan tentang NAT-traversal menjelaskan perilaku ini, termasuk interaksi dengan port mengambang saat MOBIKE digunakan.

Gunakan pengaturan yang sesuai dengan backend Anda

strongSwan memiliki dua backend konfigurasi, dan kuncinya berbeda di antara keduanya. swanctl.conf koneksi mengambil encap, sedangkan ipsec.conf koneksi lama mengambil forceencaps. Menaruh kata kunci satu backend ke backend lain menghasilkan konfigurasi yang dimuat tanpa keluhan dan tidak mengubah apa pun, yang lebih buruk daripada kesalahan.

Periksa daemon mana yang benar-benar berjalan sebelum Anda menyunting apa pun. Di banyak distribusi kedua berkas ada karena salah satunya sisa migrasi sebelumnya, dan yang aktif adalah yang dijalankan unit layanan. Baca unit itu alih-alih menebak dari stempel waktu berkas. Pemeriksaan lima detik di sini mencegah berjam-jam menguji pengaturan yang tidak dimuat oleh apa pun.

Terapkan perubahan melalui pemilik koneksi dan bangun kembali asosiasi selama jendela terkendali. Child yang sudah terpasang mempertahankan enkapsulasi saat ini sampai diganti, jadi menyunting berkas saja tidak membuktikan susunan baru sedang digunakan.

Verifikasi data yang dibungkus, bukan hanya port

Tangkap di gateway saat lalu lintas terlindungi mengalir, lalu bandingkan dengan pandangan strongSwan sendiri:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP muncul sebagai protokol IP 50 dan sama sekali tidak mirip UDP. ESP terbungkus muncul sebagai datagram UDP pada 4500 yang muatannya bukan IKE. Lalu lintas IKE pada port yang sama bukan bukti enkapsulasi, karena MOBIKE dapat memindahkan IKE ke sana sementara jalur data tetap native, jadi baca muatannya, bukan nomor portnya.

Ingat juga MTU jalur. Pembungkus menambah overhead, dan jalur yang membawa native ESP mungkin perlu penyesuaian saat paket tumbuh. Penanganan ICMP yang diperlukan seharusnya sudah menjadi bagian dari rancangan; enkapsulasi tidak menghapus ketergantungan itu.

Terima perubahan ketika lalu lintas aplikasi baru di dalam tunnel terlihat dalam tangkapan sebagai ESP terbungkus di kedua ujung, dan ketika layanan dalam serta rute baliknya masih bekerja. Apa pun yang kurang adalah konfigurasi yang tampak benar di berkas.