Mengapa IKEv2 di Android gagal pada port UDP bukan standard

Borang IKEv2 asli menerima alamat, bukan port. Sahkan klien menyokongnya, tetapkan kedua-dua port pelayan, kemudian periksa pembingkaian dan log.

Gerbang menjawab IKEv2 pada UDP 4443 atas sesuatu sebab, profil mempunyai medan bernama Server, anda menaip nama hos dan port, dan telefon melaporkan ia tidak dapat mencapai pelayan atau tidak dapat menyelesaikan alamat. Tiada apa yang disekat. Borang asli Android menjangkakan hos, dan perkara sama berlaku di Windows. Port tersuai ialah keupayaan klien sebelum ia menjadi tetapan pelayan, dan hanya sesetengah klien membenarkan anda menyatakannya. Lalui ketiga-tiga bahagian mengikut urutan: apa yang klien boleh katakan, apa yang pelayan dengar, dan sama ada kedua-dua hujung membingkai paket dengan cara yang sama.

Apa yang telefon sebenarnya hantar

Rentetan host:port dalam medan yang dimaksudkan untuk nama diselesaikan sebagai nama. Penyelesai tidak memulangkan apa-apa untuk vpn.example.net:4443, dan ralat yang anda lihat ialah kegagalan penyelesaian nama atau ketidaksampaian, bukan tamat masa pada port. Perbezaan itu penting, kerana mencuba semula dengan nama lebih pendek atau rangkaian lain tidak akan membaiki rentetan yang borang tidak dapat menghuraikan.

Profil IKEv2 asli pada Android, seperti klien VPN terbina dalam Windows, dipaku pada port IKE standard. Kedua-duanya tidak memaparkan medan port, dan tiada penyuntingan profil menambah satu. Jika pendengar pengendali benar-benar berada di 4443, klien terbina dalam ialah alat yang salah, bukan yang salah dikonfigurasikan.

Gunakan klien yang memaparkan port

Klien strongSwan untuk Android mendokumenkan port pelayan yang boleh dikonfigurasikan dalam tetapan profil lanjutan, sebab itulah ia muncul dalam hampir setiap resipi yang berfungsi untuk reka bentuk ini. Sokongan itu milik klien tersebut: aplikasi IKEv2 lain, atau cabang vendor aplikasi yang sama, mungkin tidak memaparkan medan yang sama walaupun daemon strongSwan di bawahnya menyokongnya.

Minta keseluruhan set sekali gus daripada pengendali: nama gerbang, port UDP, kaedah pengesahan, dan identiti pelayan yang klien mesti jangkakan. Port tersuai bukan sebab untuk mematikan pemeriksaan sijil atau menukar protokol. Masukkan port di tempat klien yang dipasang menjangkakannya, dan jika klien itu tiada medan sedemikian, jawapannya ialah klien lain yang diluluskan, bukan jalan pintas yang diteka.

Pelayan mempunyai dua port, dan kedua-duanya mesti sepadan

IKE bermula pada UDP 500, dan traversal NAT biasanya memindahkan IKE serta ESP berkapsul ke UDP 4500. Ini tetapan berasingan dalam strongSwan, jadi pelayan yang dipindahkan ke satu port tersuai mesti menukar kedua-duanya kepada nilai yang sama:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Dengan satu port untuk kedua-dua peranan, daemon mesti membezakan IKE daripada ESP-dalam-UDP pada soket yang sama, yang dilakukannya melalui penanda empat bait bukan ESP yang mendahului mesej IKE. Sebab itulah klien tidak boleh berunding pada port tersuai dan kemudian terus senyap pada 4500, dan sebab itulah frasa “cukup tukar port” menyembunyikan syarat pembingkaian.

Pemajuan bukan pendengar

Memajukan 4443 ke pendengar IKE biasa ialah mod kegagalan yang kelihatan hampir berjaya. Pertukaran pertama tiba, pelayan menjawab, dan kemudian sambungan terhenti atau menjana semula kunci ke tiada apa, kerana balasan keluar dari port lain dan trafik berkapsul kemudiannya tidak pernah sepadan dengan keadaan yang dicipta oleh kedua-dua hujung. Peraturan yang menulis semula port destinasi tanpa memindahkan pendengar menghasilkan tepat hasil separuh terbuka ini.

Laluan juga mesti membenarkan UDP dari hujung ke hujung. TCP 443 melepasi rangkaian hotel atau pengendali tidak mengatakan apa-apa tentang IKEv2 pada port UDP, walaupun nombornya sama. Di tempat yang hanya TCP 443 dibenarkan, port UDP tersuai tidak menjadikan IKEv2 sebagai HTTPS, dan jawapan yang betul mungkin laluan akses lain, bukan percubaan port lagi.

Asingkan tiga peringkat semasa menguji

Tangkap di pelayan semasa klien mencuba sekali. Permintaan yang tidak pernah tiba ialah persoalan titik akhir atau tembok api; permintaan yang tiba tanpa jawapan ialah persoalan pendengar atau dasar; jawapan yang diikuti kesunyian ialah persoalan pembingkaian atau identiti.

tcpdump -ni eth0 -vv udp port 4443

Kemudian baca mesej klien dan bukan penunjuk berpusingnya. Ralat cadangan bermakna algoritma tidak sepadan, kegagalan pengesahan bermakna identiti atau sijil tidak sepadan, dan penghantaran semula berulang tanpa jawapan bermakna tiada apa yang menjawab pada port itu. Uji satu peringkat pada satu masa dan tukar satu medan antara percubaan; dokumentasi strongSwan tentang traversal NAT menerangkan penanda dan tingkah laku port yang ditunjukkan oleh tangkapan kepada anda.

Artikel berkaitan