IKEv2 menggunakan UDP 500 dan 4500: yang mana membawa data?

Pertukaran pertama dan laluan yang membawa data bukan aliran yang sama. Semak kedua-dua port, dan ingat bahawa ESP asli ialah nombor protokol, bukan port.

Membuka UDP 500 dalam tembok api membolehkan terowong berunding, kemudian sambungan berhenti menghantar trafik. Senarai port itu tidak lengkap, bukan salah. IKEv2 bermula pada satu soket dan dalam banyak penggunaan sebenar bersambung pada soket lain, manakala muatan mungkin bukan port sama sekali. Membaca peringkat mengikut urutan menjelaskan peraturan mana yang hilang.

Dua port, dua tugas

IKEv2 bermula dengan pertukaran kunci pada UDP 500, tempat kedua-dua pihak mengesahkan diri dan membentuk persatuan keselamatan untuk terowong. Laluan data selepas itu ialah perkara berasingan: ia boleh jadi ESP asli, iaitu nombor protokol IP dan bukan port, atau trafik yang dikapsulkan dalam UDP pada 4500. Memisahkan kedua-duanya dalam semakan tembok api ialah perbezaan antara terowong yang berunding dan terowong yang berfungsi. Satu soket membawa kawalan dan satu lagi membawa muatan.

Sebab itulah peraturan yang hanya membenarkan 500 menghasilkan gejala paling mengelirukan dalam seluruh keluarga protokol: rundingan berjaya dan tiada apa yang berguna menyusul. Keadaan menunjukkan rakan, log menunjukkan IKE SA yang terbentuk, dan aplikasi masih tamat masa. Kebenaran yang hilang tergolong dalam aliran berbeza daripada yang baru berjaya.

Mengapa 4500 wujud

Banyak peranti NAT tidak dapat memajukan protokol selain TCP atau UDP, dan sesetengahnya menulis semula alamat dengan cara yang merosakkan semakan integriti ESP. Mengkapsulkan ESP dalam UDP menyelesaikan kedua-dua masalah, dengan kos pengepala tambahan dan port kedua yang perlu dibenarkan. Kapsulan itulah sebabnya port kedua wujud.

Sebaik NAT dikesan, IKE sendiri juga berpindah ke 4500 supaya semua trafik berkongsi satu laluan melalui penterjemah. Penanda empat bait yang bukan ESP membezakan mesej kawalan daripada data pada soket itu. Peralihan itu keputusan protokol, bukan keutamaan pentadbir.

Di mana port sumber berubah

Penterjemah boleh menulis semula port sumber klien, jadi tuple yang dilihat di pelayan tidak sepadan dengan tuple pada klien. Lihat kedua-dua belah setiap lompatan NAT sebelum membuat kesimpulan bahawa sesuatu peraturan diabaikan. Penyelesaian masalah hanya pada klien boleh menghasilkan peraturan yang kelihatan betul dan masih gagal.

Pelaksanaan yang menyokong MOBIKE juga boleh berpindah ke 4500 tanpa NAT dikesan, dan sesetengah penggunaan sengaja memaksa laluan itu. Melihat 4500 kerana itu ialah bukti keputusan, bukan bukti penghala rumah.

Periksa kedua-dua aliran di setiap sempadan

Lalui tiga sempadan: rangkaian klien, mana-mana tembok api perantaraan, dan pelayan. Setiap satu memerlukan aliran yang didokumenkan oleh penggunaan, bukan aliran daripada artikel tentang kes lain.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Baris ESP dalam senarai tembok api ialah padanan protokol, jadi peraturan port tidak pernah meliputinya. Jika pengendali menggunakan port tersuai, ikut konfigurasi yang didokumenkan di kedua-dua hujung, kerana klien tidak boleh mencipta pendengar di pelayan dengan memilih nombor yang biasa.

Catat di mana rundingan berhenti dan sama ada persatuan keselamatan anak dipasang, kerana pasangan itu memisahkan laluan yang disekat daripada ralat pengesahan atau dasar. Kemudian ulangi ujian dengan pengesahan pelayan diaktifkan, kerana kebolehcapaian bukan pengesahan. Langkah terakhir itu memisahkan port yang dibenarkan daripada rakan yang dipercayai.

Artikel berkaitan