SIP trafiğinin bir anahtara girdiğini ancak dışarı çıkmadığını görmenize ne sebep olur?


15

Arka fon

SIP telefonumu yepyeni bir yönlendiricinin arkasına kaydettirmek ve yeni ofisimize geçmek için uğraşıyorum. PBX'imiz tesis dışında barındırılmaktadır. Sağlayıcımızla birkaç farklı yaklaşım denemek için çalıştım. NAT farkında oturum sınır denetleyicilerine bağlanmak için düzenli NAT denedik. SIP kayıt isteklerini durdurmak ve telefonlar adına kayıt olmak için siproxd (pfSense paketi) kullanmayı denedik. Son olarak, yerel ağımdaki siproxd arka plan programına kaydolmak için telefonları manuel olarak yapılandırmayı denedik.

Testler boyunca telefonların aşağıdakilerin tümünü başarıyla gerçekleştirdiğini gördük:

  • Barındırılan FTP sunucusuyla IP adresine göre iletişim kurun
  • Söz konusu sunucudan yapılandırmayı indirin
  • NTP sunucusunun IP adresini çözmek için DNS sorguları gerçekleştirin
  • Saati ayarlamak için NTP sunucusunu sorgulama
  • SIP sunucularının IP adreslerini çözmek için DNS sorguları gerçekleştirin

belirtiler

Telefonlar tüm ön kayıt görevlerini başarıyla tamamladıktan sonra, kayıt girişiminin pfSense kutusuna veya sağlayıcının PBX'ine çarptığını asla göremeyiz. Sonunda siproxd hata ayıklama en üst düzeyde etkinleştirdi ve bir TCP bağlantısı veya UDP paketi nary gördüm. Ancak, bir iş istasyonundan 5060 numaralı bağlantı noktasına giden basit bir telnet, beklenen günlük iletileri oluşturur. PfSense kutusunda paket yakalama yapmak kesinlikle hiçbir SIP trafiği girişimi göstermedi.

Bu da ne?

Beni tamamen şaşırtan ve bu soruyu sormamı sağlayan son sorun giderme adımım aşağıdaki gibiydi. İlk olarak bir telefonun iş istasyonu anahtar bağlantı noktasına takıldığı anahtar bağlantı noktasını yansıttım. Arayüzdeki tüm trafiği bir paket olarak yakaladım. Şaşırtıcı bir şekilde, telefondan gelen SIP kayıt paketlerini gördüm. İşte bir örnek:

Telefon Paketi Yakalama

Açıkçası telefon PBX'lere kaydolmaya çalışıyor (bunlar da doğru IP adresleri).

Bir sonraki adımım, pfSense yönlendiricinin LAN tarafına beslenen anahtar bağlantı noktasını yansıtmaktı. 172.200.22.102 telefondan gelen tüm FTP, NTP ve DNS trafiğinin anahtardan çıktığını gördüm, ancak SIP paketlerinin izi yoktu. Bu benim için tamamen şaşırtıcı! Anahtarda yalnızca SIP trafiğinin kaybolmasına neden olan nedir ?

çevre

Anahtar Yapılandırması

IP Adresi 172.22.200.102 olan telefon bu anahtarın 4 numaralı bağlantı noktasında, yönlendirici LAN bağlantısı 22 numaralı bağlantı noktasındadır.

VLAN Yapılandırması

VLAN 200 katılımı

Gerekli olabilecek diğer ayarları paylaşabilirim.


Paketlerin yönlendiricinin LAN arabirimine yönelmesinin sağduyulu olduğunu biliyorum, ancak izin verilen herhangi bir şey almayalım. Wireshark'ı, telefondan çıkan paketlerdeki hedef MAC adreslerini gösterebilir ve bunların aslında yönlendiricinin MAC adresi olduğunu doğrulayabilir misiniz? Bir nedenden dolayı olmasalardı, bu onları neden ayna bağlantı noktasında görmediğinizi açıklardı.
MadHatter

@Mad: yönlendiricinin doğru hedef MAC adresini doğruladı
hobodave

Lanet olsun. Eh, kontrol etmeye değerdi. Daha iyi fikirlere sahip olmadığım için üzgünüm.
MadHatter

Yanıtlar:


16

Bu soruna yaklaşık 40 saat geçirdikten sonra çözümü buldum.

Anahtarda "Otomatik DoS" korumasını etkinleştiren bir ayar vardır. Görünüşe göre, eşleşen kaynak veya hedef portlara sahip TCP veya UDP trafiğinin bir blat saldırısı olduğunu düşünüyor ve paketi düşürüyor. SIP trafiği sık sık (her zaman?) Kaynak ve hedef bağlantı noktalarının 5060 olmasına bağlı olduğundan bu gülünç derecede kısa görüşlüdür.

Metinsel bir tanımın yetersiz olması durumunda:

resim açıklamasını buraya girin


vay, bu acımasız. Bunu bulmak iyi iş. Bahse girerim günlüklerde de görünmez, değil mi?
gravyface

@gravyface: doğru, hiçbir şey kaydedilmedi. Tüm günlükler gösterisi temel bağlantı yukarı / aşağı ve kimlik doğrulama girişimleri
hobodave

2
Whaaaaaaaaaaaaaaaat? İyi işti HP!
voretaq7

1
Bu berbat; NTP ve sunucu-sunucu DNS'sini de (örn.) bozar. Voretaq'ın sözleriyle, "iyi iş. HP". İyi teşhis edilir, ancak hobodave; bir bira hak ediyorsun!
MadHatter

1
+1 - Bugün farklı bir uygulamada aynı anahtarla karşılaştım. SonicWALL "Tek Oturum Açma" protokolü, aynı kaynak / hedef bağlantı noktalarına sahip UDP datagramlarını kullanır. Keşke buraya bir Ethernet bağlantısıyla izlemeden önce baksaydım. "Sorunlu" çerçevelerin, giriş bağlantı noktasını yansıtırken bile kaldırıldığını belirtmek ilginçtir. Tamamlanma başarısız, HP. Ocak ayında piyasaya sürülen PK 1.15 ürün yazılımının hala bu yanlış özelliği içerdiğini doğrulayabilirim.
Evan Anderson
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.