อะไรจะทำให้การรับส่งข้อมูลของ SIP ถูกมองว่ากำลังเข้าสู่สวิตช์ แต่ไม่ออกมา


15

พื้นหลัง

ฉันพยายามรับโทรศัพท์ SIP ของฉันเพื่อลงทะเบียนด้านหลังเราเตอร์ใหม่และเปลี่ยนสำนักงานใหม่ของเรา PBX ของเราโฮสต์อยู่นอกสถานที่ ฉันทำงานร่วมกับผู้ให้บริการของเราเพื่อลองวิธีการที่แตกต่างกัน เราได้ลองใช้ NAT ปกติเพื่อเชื่อมต่อกับตัวควบคุมชายแดนของเซสชัน NAT ที่ทราบ เราได้ลองใช้ siproxd (แพ็คเกจ pfSense) เพื่อสกัดกั้นการร้องขอการลงทะเบียน SIP และลงทะเบียนในนามของโทรศัพท์ ในที่สุดเราได้ลองกำหนดค่าโทรศัพท์ด้วยตนเองเพื่อลงทะเบียนกับ siproxd daemon บนเครือข่ายท้องถิ่นของฉัน

ตลอดการทดสอบเราเห็นว่าโทรศัพท์ทำสิ่งต่อไปนี้สำเร็จ:

  • ติดต่อเซิร์ฟเวอร์ FTP ที่โฮสต์โดยที่อยู่ IP
  • ดาวน์โหลดการกำหนดค่าจากเซิร์ฟเวอร์ดังกล่าว
  • ดำเนินการค้นหา DNS เพื่อแก้ไขที่อยู่ IP ของเซิร์ฟเวอร์ NTP
  • ค้นหาเซิร์ฟเวอร์ NTP เพื่อตั้งเวลา
  • ดำเนินการค้นหา DNS เพื่อแก้ไขที่อยู่ IP ของเซิร์ฟเวอร์ SIP

อาการ

หลังจากโทรศัพท์ดำเนินการลงทะเบียนล่วงหน้าเรียบร้อยแล้วเราไม่เคยเห็นความพยายามในการลงทะเบียนกดที่กล่อง pfSense หรือ PBX ของผู้ให้บริการ ฉันได้เปิดใช้งานการดีบักในระดับสูงสุดใน siproxd ที่ส่วนท้ายของฉันและได้เห็นการเชื่อมต่อ TCP หรือแพ็กเก็ต UDP ที่ดี อย่างไรก็ตาม telnet ง่ายไปยังพอร์ต 5060 จากเวิร์กสเตชันจะสร้างข้อความบันทึกที่คาดหวัง การทำการดักจับแพ็คเก็ตบนกล่อง pfSense แสดงว่าไม่มีความพยายามในการรับส่งข้อมูลของ SIP

ห่า?

ขั้นตอนการแก้ไขปัญหาขั้นสุดท้ายของฉันที่ทำให้ฉันนิ่งงันและนำฉันไปถามคำถามนี้มีดังนี้ ก่อนอื่นฉันทำมิเรอร์พอร์ตสวิตช์ที่โทรศัพท์ต่อเข้ากับพอร์ตสวิตช์ของเวิร์กสเตชัน ฉันทำการจับแพ็คเก็ตของปริมาณข้อมูลทั้งหมดบนอินเทอร์เฟซ ด้วยความประหลาดใจของฉันฉันเห็นแพ็กเก็ตการลงทะเบียน SIP ที่มาจากโทรศัพท์ นี่คือตัวอย่าง:

จับแพ็คเก็ตโทรศัพท์

เห็นได้ชัดว่าโทรศัพท์กำลังพยายามลงทะเบียนกับ PBX (ซึ่งเป็นที่อยู่ IP ที่ถูกต้องเช่นกัน)

ขั้นตอนต่อไปของฉันคือทำมิเรอร์พอร์ตสวิตช์ที่ป้อนเข้าในด้าน LAN ของเราเตอร์ pfSense ฉันเห็นการรับส่งข้อมูล FTP, NTP และ DNS ทั้งหมดจากโทรศัพท์ 172.200.22.102 ออกมาจากสวิตช์ แต่ไม่ได้ติดตามร่องรอยของแพ็กเก็ต SIP นี่เป็นเรื่องยุ่งสำหรับฉันอย่างสมบูรณ์! สิ่งที่เป็นสาเหตุเพียงการจราจร SIP ที่จะหายไปภายในสวิทช์?

สิ่งแวดล้อม

สลับการกำหนดค่า

โทรศัพท์ที่มีที่อยู่ IP 172.22.200.102 อยู่ในพอร์ต 4 ของสวิตช์นี้เราเตอร์ LAN ลิงค์จะอยู่ในพอร์ต 22

การกำหนดค่า VLAN

การมีส่วนร่วมของ VLAN 200

ฉันสามารถแบ่งปันการตั้งค่าเพิ่มเติมที่อาจจำเป็น


ฉันรู้ว่ามันเป็นเรื่องธรรมดาที่แพ็กเก็ตควรมุ่งหน้าไปที่ LAN interface ของเราเตอร์ แต่เราจะไม่ยอมทำอะไรเลย คุณช่วยให้ wireshark แสดงที่อยู่ MAC ปลายทางให้คุณเห็นได้จากแพ็กเก็ตเหล่านั้นที่ออกจากโทรศัพท์และยืนยันว่าเป็นที่อยู่ MAC ของเราเตอร์หรือไม่ หากพวกเขาไม่ได้ด้วยเหตุผลบางอย่างที่จะอธิบายว่าทำไมคุณไม่เห็นพวกเขาในพอร์ตมิเรอร์
MadHatter

@Mad: ยืนยันที่อยู่ MAC ปลายทางที่ถูกต้องของเราเตอร์
hobodave

ประณาม. มันก็คุ้มค่าที่จะตรวจสอบ ขออภัยที่ไม่มีแนวคิดที่ดีกว่านี้อีก
MadHatter

คำตอบ:


16

ฉันพบวิธีแก้ปัญหาหลังจากใช้เวลาประมาณ 40 ชั่วโมงกับปัญหานี้

มีการตั้งค่าในสวิตช์ที่เปิดใช้งานการป้องกัน "Auto DoS" เห็นได้ชัดว่ามันพิจารณาปริมาณการใช้ TCP หรือ UDP ที่มีการจับคู่พอร์ตต้นทางหรือปลายทางเป็นโจมตี blatและแพ็คเก็ตลดลง นี่คือสายตาสั้นอย่างน่าขันเนื่องจากทราฟฟิก SIP มักจะ (เสมอ?) อาศัยพอร์ตต้นทางและปลายทางเป็น 5060

ในกรณีที่คำอธิบายที่เป็นข้อความไม่เพียงพอ:

ป้อนคำอธิบายรูปภาพที่นี่


ว้าวนั่นมันโหดร้าย หางานที่ดี ฉันพนันได้เลยว่ามันจะไม่ปรากฏในบันทึกใช่มั้ย
gravyface

@gravyface: ถูกต้องไม่มีอะไรถูกบันทึก บันทึกทั้งหมดแสดงเป็นลิงค์พื้นฐานขึ้น / ลงและความพยายามในการตรวจสอบสิทธิ์
hobodave

2
Whaaaaaaaaaaaaaaaat? เป็นงานที่ดีของ HP!
voretaq7

1
ที่ดูด; มันจะขัน (เช่น) NTP และ DNS เซิร์ฟเวอร์ - เซิร์ฟเวอร์เช่นกัน ในคำพูดของ voretaq "nice nice. HP" การวินิจฉัยที่ดีแม้ว่า hobodave; คุณสมควรได้รับเบียร์!
MadHatter

1
+1 - วันนี้ฉันได้พบกับสวิตช์เดียวกันในแอปพลิเคชันอื่น โปรโตคอล SonicWALL "Single Sign-On" ใช้ดาตาแกรม UDP ที่มีพอร์ตต้นทาง / ปลายทางเดียวกัน ฉันหวังว่าฉันจะดูที่นี่ก่อนที่จะติดตามมันด้วยการแตะอีเธอร์เน็ต เป็นที่น่าสนใจที่จะทราบว่าเฟรม "offending" จะถูกลบออกเมื่อทำการมิเรอร์พอร์ตที่พอร์ต ingress ล้มเหลวโดยสิ้นเชิง HP ฉันสามารถยืนยันได้ว่าเฟิร์มแวร์ PK 1.15 ที่วางจำหน่ายในเดือนมกราคมยังคงมีฟีเจอร์ผิดปกติอยู่
Evan Anderson
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.