Menjangkau klien IKEv2 pada IP virtual yang ditetapkan

Gateway perlu memulai koneksi ke laptop yang terhubung dengannya melalui IKEv2, dengan memakai alamat virtual yang ditetapkan untuk klien tersebut. Terowongan sudah aktif, klien menjangkau semua yang ada di belakang gateway, dan arah sebaliknya tetap gagal. Asimetri itu normal: kebijakan yang dinegosiasikan menjabarkan alamat mana yang boleh berbicara, bukan sisi mana yang boleh memulai. Tiga hal harus selaras sebelum permintaan yang dimulai gateway bisa bekerja.

Terowongan tidak memperbaiki alamat sumber

CHILD SA mencakup sepasang selektor lalu lintas, satu per sisi, dan mengizinkan lalu lintas di kedua arah pasangan itu. Ia tidak mengatakan apa pun tentang peer mana yang membuka pertukaran IKE lebih dulu. Gateway yang semula mendengarkan terowongan masih dapat mengirim paket aplikasi pertama, asalkan sumber dan tujuan yang dipilih berada di dalam selektor yang terpasang. Ketika permintaan keluar dari antarmuka yang salah, permintaan itu sama sekali tidak memenuhi syarat untuk terowongan.

Perutean menuju klien perlu dan tidak cukup. Kebijakan harus mengizinkan sumber yang benar-benar Anda pakai.

Baca kebijakan yang terpasang, bukan berkas konfigurasi

Mulailah dari asosiasi aktif dan selektornya, karena penetapan dinamis mengubah apa yang terpasang di kernel.

ipsec statusall
ip xfrm policy

Keluaran status menyebutkan koneksi, alamat virtual yang ditetapkan, dan selektor yang berlaku saat ini untuk peer tersebut. Dump kebijakan menampilkan selektor yang sama sebagai status kernel, dan itulah yang benar-benar dikonsultasikan oleh pemilihan paket. Bandingkan selektor di sisi gateway dengan sumber yang akan dipakai aplikasi Anda, karena ketidakcocokan langsung menjelaskan kegagalan itu. Baca alamat klien saat ini, bukan alamat dari sesi sebelumnya, karena VIP yang ditetapkan ulang membatalkan kebijakan lama.

Klien harus mendengarkan di tempat paket tiba

Bahkan kebijakan yang sempurna mencapai port tertutup ketika layanan hanya terikat ke loopback. Pendengar harus berada di alamat yang ditetapkan atau di alamat lokal wildcard.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Daftar soket menunjukkan apakah port terikat ke alamat virtual, dan aturan firewall menunjukkan apakah koneksi baru diterima dari sumber yang dilindungi. Aturan yang ditulis untuk koneksi yang sudah ada tidak mengizinkan koneksi yang dimulai gateway. Pertahankan autentikasi layanan itu sendiri, karena datang melalui terowongan hanya menetapkan dari jaringan mana paket itu berasal. Klien di belakang NAT-nya sendiri tetap tidak memerlukan penerusan port masuk, karena permintaan ini berjalan di dalam terowongan yang sudah ada.

Uji arah baru secara terpisah

Permintaan klien-ke-server yang berhasil tidak pernah menguji jalur ini. Hasilkan permintaan dari gateway dan amati kedua ujungnya.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Pencarian rute menjawab sumber dan antarmuka mana yang akan dipakai gateway, dan itulah nilai yang harus diizinkan kebijakan. Tangkapan harus menunjukkan permintaan keluar di dalam ESP, bukan sebagai TCP biasa di antarmuka publik. Di klien, tangkap lalu lintas yang didekripsi untuk memastikan kedatangan dan apakah layanan menjawab. Jika permintaan hilang tanpa ESP di jalur, curigai alamat sumber sebelum firewall klien.

Ulangi pengujian setelah pergantian kunci atau sambung ulang, karena VIP bisa berubah. Jalur yang hanya bekerja sampai sesi berikutnya bukan jalur yang bekerja.