Mengapa IKEv2 di Android gagal pada port UDP non-standar
Formulir IKEv2 bawaan menerima alamat, bukan port. Pastikan klien mendukungnya, atur kedua port server, lalu periksa pembingkaian dan log.
Gateway menjawab IKEv2 pada UDP 4443 karena suatu alasan, profil memiliki kolom bernama Server, Anda mengetik nama host dan port, dan ponsel melaporkan tidak dapat menjangkau server atau tidak dapat menyelesaikan alamat. Tidak ada yang diblokir. Formulir bawaan Android mengharapkan host, dan hal yang sama berlaku di Windows. Port khusus adalah kemampuan klien sebelum menjadi pengaturan server, dan hanya sebagian klien yang mengizinkan Anda menyatakannya. Telusuri ketiga bagian secara berurutan: apa yang dapat dikatakan klien, apa yang didengarkan server, dan apakah kedua ujung membingkai paket dengan cara yang sama.
Apa yang sebenarnya dikirim ponsel
String host:port di kolom yang dimaksudkan untuk nama akan diselesaikan sebagai nama. Resolver tidak mengembalikan apa pun untuk vpn.example.net:4443, dan galat yang Anda lihat adalah kegagalan resolusi nama atau ketidaktersediaan, bukan habis waktu pada port. Perbedaan itu penting, karena mencoba lagi dengan nama lebih pendek atau jaringan lain tidak akan pernah memperbaiki string yang tidak dapat diuraikan formulir.
Profil IKEv2 bawaan di Android, seperti klien VPN bawaan Windows, dipatok ke port IKE standar. Keduanya tidak menampilkan kolom port, dan tidak ada penyuntingan profil yang menambahkannya. Jika pendengar operator benar-benar berada di 4443, klien bawaan adalah alat yang salah, bukan yang salah dikonfigurasi.
Gunakan klien yang menampilkan port
Klien strongSwan untuk Android mendokumentasikan port server yang dapat dikonfigurasi di pengaturan profil lanjutan, itulah sebabnya klien ini muncul di hampir setiap resep yang berhasil untuk desain ini. Dukungan itu milik klien tersebut: aplikasi IKEv2 lain, atau fork vendor dari aplikasi yang sama, mungkin tidak menampilkan kolom yang sama meskipun daemon strongSwan di bawahnya mendukungnya.
Mintalah seluruh rangkaian sekaligus kepada operator: nama gateway, port UDP, metode autentikasi, dan identitas server yang harus diharapkan klien. Port khusus bukan alasan untuk menonaktifkan pemeriksaan sertifikat atau mengganti protokol. Masukkan port di tempat klien yang terpasang mengharapkannya, dan jika klien itu tidak memiliki kolom tersebut, jawabannya adalah klien lain yang disetujui, bukan akal-akalan yang ditebak.
Server memiliki dua port, dan keduanya harus cocok
IKE dimulai pada UDP 500, dan traversal NAT biasanya memindahkan IKE serta ESP yang dienkapsulasi ke UDP 4500. Ini adalah pengaturan terpisah di strongSwan, jadi server yang dipindahkan ke satu port khusus harus mengubah keduanya ke nilai yang sama:
plugins {
socket-default {
port = 4443
port_nat_t = 4443
}
}
Dengan satu port untuk kedua peran, daemon harus membedakan IKE dari ESP-dalam-UDP pada soket yang sama, yang dilakukannya melalui penanda empat byte non-ESP yang mendahului pesan IKE. Itulah sebabnya klien tidak dapat bernegosiasi pada port khusus lalu diam-diam melanjutkan di 4500, dan itulah sebabnya frasa “cukup ubah portnya” menyembunyikan syarat pembingkaian.
Penerusan bukan pendengar
Meneruskan 4443 ke pendengar IKE biasa adalah mode kegagalan yang tampak hampir berhasil. Pertukaran pertama tiba, server menjawab, lalu koneksi terhenti atau membarui kunci menjadi tidak ada, karena balasan keluar dari port lain dan lalu lintas terenkapsulasi berikutnya tidak pernah cocok dengan keadaan yang dibuat kedua ujung. Aturan yang menulis ulang port tujuan tanpa memindahkan pendengar menghasilkan tepat hasil setengah terbuka ini.
Jalur juga harus mengizinkan UDP dari ujung ke ujung. Lolosnya TCP 443 melalui jaringan hotel atau operator tidak mengatakan apa pun tentang IKEv2 pada port UDP, bahkan dengan nomor yang sama. Di tempat yang hanya mengizinkan TCP 443, port UDP khusus tidak mengubah IKEv2 menjadi HTTPS, dan jawaban yang benar mungkin jalur akses lain, bukan eksperimen port lagi.
Pisahkan ketiga tahap saat menguji
Tangkap di server saat klien mencoba sekali. Permintaan yang tidak pernah tiba adalah soal titik akhir atau firewall; permintaan yang tiba tanpa jawaban adalah soal pendengar atau kebijakan; jawaban yang diikuti kesunyian adalah soal pembingkaian atau identitas.
tcpdump -ni eth0 -vv udp port 4443
Lalu bacalah pesan klien, bukan indikator berputarnya. Galat proposal berarti algoritme tidak cocok, kegagalan autentikasi berarti identitas atau sertifikat tidak cocok, dan pengiriman ulang berulang tanpa jawaban berarti tidak ada yang menjawab di port itu. Uji satu tahap sekaligus dan ubah satu kolom di antara percobaan; dokumentasi strongSwan tentang traversal NAT menjelaskan penanda dan perilaku port yang ditunjukkan tangkapan kepada Anda.