Apa yang menyebabkan lalu lintas SIP terlihat beralih tetapi tidak keluar?

Latar Belakang

Saya telah berjuang untuk mendapatkan ponsel SIP saya untuk mendaftar di belakang router baru dan beralih di kantor baru kami. PBX kami di-host di luar kantor. Saya telah bekerja dengan penyedia kami untuk mencoba beberapa pendekatan berbeda. Kami telah mencoba NAT reguler untuk terhubung ke pengontrol perbatasan sesi sadar-NAT mereka. Kami telah mencoba menggunakan siproxd (paket pfSense) untuk mencegat permintaan pendaftaran SIP dan mendaftar atas nama ponsel. Akhirnya, kami telah mencoba mengkonfigurasi ponsel secara manual untuk mendaftar dengan daemon siproxd di jaringan lokal saya.

Sepanjang pengujian kami telah melihat ponsel melakukan semua hal berikut ini dengan sukses:

Hubungi server FTP yang dihosting dengan alamat IP
Unduh konfigurasi dari server tersebut
Lakukan permintaan DNS untuk menyelesaikan alamat IP server NTP
Permintaan server NTP untuk mengatur waktu
Melakukan kueri DNS untuk menyelesaikan alamat IP server SIP

Gejala

Setelah ponsel berhasil melakukan semua tugas pra-registrasi, kami tidak pernah melihat upaya registrasi mengenai kotak pfSense, atau PBX penyedia. Saya telah mengaktifkan level tertinggi dari debugging di siproxd di ujung saya dan telah melihat koneksi TCP atau paket UDP. Namun, telnet sederhana ke port 5060 dari workstation akan menghasilkan pesan log yang diharapkan. Melakukan penangkapan paket pada kotak pfSense sama sekali tidak menunjukkan upaya lalu lintas SIP.

Apa apaan?

Langkah pemecahan masalah terakhir saya yang benar-benar mengejutkan saya dan membawa saya untuk mengajukan pertanyaan ini adalah sebagai berikut. Saya pertama kali mencerminkan port switch yang telepon terhubung ke port switch workstation saya. Saya melakukan penangkapan paket semua lalu lintas di antarmuka. Yang mengejutkan saya, saya melihat paket pendaftaran SIP datang dari telepon. Berikut ini sebuah contoh:

Pengambilan Paket Telepon

Jelas telepon sedang mencoba mendaftar dengan PBX (itu adalah alamat IP yang benar juga).

Langkah saya selanjutnya adalah mirror port switch yang mengumpankan ke sisi LAN dari router pfSense. Saya melihat semua lalu lintas FTP, NTP, dan DNS dari ponsel 172.200.22.102 keluar dari sakelar, tetapi bukan jejak paket SIP. Ini benar-benar membingungkan saya! Apa yang menyebabkan hanya lalu lintas SIP yang hilang dalam sakelar?

Lingkungan Hidup

Perangkat keras
- Router / Firewall: Netgate m1n1wall 2D2
- Beralih: HP 1810G-24
- Telepon: Polycom SoundPoint IP 501
Perangkat lunak: pfSense 2.0-RC3

Ganti Konfigurasi

Ponsel dengan Alamat IP 172.22.200.102 ada di port 4 switch ini, tautan LAN router ada di port 22.

Konfigurasi VLAN

Partisipasi VLAN 200

Saya dapat berbagi pengaturan lagi yang mungkin diperlukan.

pfsense sip switch

— hobodave
sumber

Saya tahu itu masuk akal bahwa paket harus menuju antarmuka LAN dari router, tapi jangan anggap remeh. Bisakah Anda mendapatkan wireshark untuk menunjukkan alamat MAC tujuan pada paket-paket yang meninggalkan telepon, dan mengkonfirmasi bahwa mereka sebenarnya alamat MAC router? Jika karena alasan tertentu tidak, itu akan menjelaskan mengapa Anda tidak melihat mereka di port mirror.

— MadHatter

@ Mad: dikonfirmasi alamat MAC tujuan yang benar dari router

— hobodave

Sial. Ya, itu layak untuk diperiksa. Maaf tidak punya ide yang lebih baik.

— MadHatter

Saya menemukan solusinya setelah menghabiskan sekitar 40 jam untuk masalah ini.

Ada pengaturan di sakelar yang memungkinkan perlindungan "Auto DoS". Tampaknya itu menganggap lalu lintas TCP atau UDP yang memiliki sumber yang cocok atau port tujuan menjadi serangan blat dan menjatuhkan paket. Ini sangat tidak masuk akal karena lalu lintas SIP sering (selalu?) Bergantung pada port sumber dan tujuan menjadi 5060.

Jika deskripsi teks tidak mencukupi:

masukkan deskripsi gambar di sini

— hobodave
sumber

wow, itu brutal. Kerja bagus menemukan itu. Saya yakin itu tidak muncul di log juga, kan?

— gravyface

@gravyface: benar, tidak ada yang dicatat. Semua tampilan log adalah tautan dasar naik / turun dan upaya otentikasi

— hobodave

Whaaaaaaaaaaaaaaaat? Kerja bagus HP!

— voretaq7

Itu menyebalkan; itu akan mengacaukan (misalnya) NTP dan DNS server-server juga. Dalam kata-kata voretaq, "pekerjaan bagus. HP". Meskipun didiagnosis dengan baik, hobodave; kamu layak minum bir!

— MadHatter

+1 - Saya mengalami ini hari ini w / saklar yang sama di aplikasi yang berbeda. Protokol SonicWALL "Single Sign-On" menggunakan datagram UDP dengan port sumber / tujuan yang sama. Saya berharap saya telah melihat di sini sebelum melacaknya dengan ketukan Ethernet. Sangat menarik untuk dicatat bahwa frame "menyinggung" bahkan dihapus ketika port-mirroring port masuknya. Gagal total, HP. Saya dapat mengkonfirmasi bahwa firmware PK 1.15, dirilis pada bulan Januari, masih memiliki kesalahan ini.

— Evan Anderson