Co spowodowałoby, że ruch SIP byłby widziany jako przełączany, ale nie wychodzący?

tło

Walczyłem o to, aby moje telefony SIP zarejestrowały się za nowym routerem i przeszły do naszego nowego biura. Nasza PBX jest hostowana poza siedzibą. Współpracowałem z naszym dostawcą, aby wypróbować kilka różnych podejść. Próbowaliśmy zwykłego NAT, aby połączyć się z kontrolerem granicznym sesji obsługującym NAT. Próbowaliśmy użyć siproxd (pakiet pfSense), aby przechwycić żądania rejestracji SIP i zarejestrować się w imieniu telefonu. Wreszcie próbowaliśmy ręcznie skonfigurować telefony, aby zarejestrować się w demonie siproxd w mojej sieci lokalnej.

Podczas testów widzieliśmy, że telefony wykonują wszystkie następujące czynności:

Skontaktuj się z hostowanym serwerem FTP według adresu IP
Pobierz konfigurację ze wspomnianego serwera
Wykonaj zapytania DNS, aby rozwiązać adres IP serwera NTP
Zapytaj serwer NTP, aby ustawić czas
Wykonuj zapytania DNS, aby rozwiązać adres IP serwerów SIP

Objawy

Po pomyślnym wykonaniu wszystkich zadań wstępnej rejestracji telefony nigdy nie zobaczą próby rejestracji w polu pfSense ani w PBX dostawcy. Włączyłem najwyższy poziom debugowania w siproxd na moim końcu i nie widziałem połączenia TCP ani pakietu UDP. Jednak prosty telnet do portu 5060 ze stacji roboczej wygeneruje oczekiwane komunikaty dziennika. Przeprowadzenie przechwytywania pakietów na polu pfSense nie wykazało absolutnie żadnych prób ruchu SIP.

Co za cholera?

Mój ostatni krok rozwiązywania problemów, który całkowicie mnie zaskoczył i zmusił do zadania tego pytania, był następujący. Najpierw dublowałem port przełącznika, do którego podłączono telefon do portu przełącznika stacji roboczej. Wykonałem przechwytywanie pakietów całego ruchu w interfejsie. Ku mojemu zdziwieniu zobaczyłem pakiety rejestracyjne SIP przychodzące z telefonu. Oto przykład:

Przechwytywanie pakietów telefonicznych

Najwyraźniej telefon próbuje zarejestrować się w centrali PBX (są to również poprawne adresy IP).

Kolejnym krokiem było dublowanie portu przełącznika, który zasila stronę LAN routera pfSense. Widziałem cały ruch FTP, NTP i DNS z telefonu 172.200.22.102 wychodzącego z przełącznika, ale nie było śladu pakietów SIP. To jest dla mnie całkowicie zaskakujące! Co powoduje znikanie tylko ruchu SIP w przełączniku?

Środowisko

Sprzęt komputerowy
- Router / Firewall: Netgate m1n1wall 2D2
- Przełącznik: HP 1810G-24
- Telefony: Polycom SoundPoint IP 501
Oprogramowanie: pfSense 2.0-RC3

Przełącz konfigurację

Telefon o adresie IP 172.22.200.102 znajduje się w porcie 4 tego przełącznika, łącze LAN routera znajduje się w porcie 22.

Konfiguracja VLAN

Udział w VLAN 200

Mogę udostępnić więcej ustawień, które mogą być potrzebne.

pfsense sip switch

— hobodave
źródło

Wiem, że to zdrowy rozsądek, że pakiety powinny być kierowane do interfejsu LAN routera, ale nie bierzmy niczego za pewnik. Czy możesz dostać wireshark, aby pokazać ci docelowe adresy MAC na tych pakietach wychodzących z telefonu i potwierdzić, że w rzeczywistości są to adresy MAC routera? Jeśli z jakiegoś powodu tak nie było, to wyjaśniałoby, dlaczego nie widziałeś ich na porcie lustrzanym.

— MadHatter

@Mad: potwierdzono poprawny docelowy adres MAC routera

— hobodave

Cholera. Warto było to sprawdzić. Przepraszam, że nie mam lepszych pomysłów.

— MadHatter

Znalazłem rozwiązanie po spędzeniu około 40 godzin na tym problemie.

Przełącznik ma ustawienie, które włącza ochronę „Auto DoS”. Najwyraźniej uważa ruch TCP lub UDP, który ma pasujące porty źródłowe lub docelowe, za atak typu blat i odrzuca pakiet. Jest to absurdalnie krótkowzroczne, ponieważ ruch SIP często (zawsze?) Zależy od portu źródłowego i docelowego wynoszącego 5060.

W przypadku, gdy opis tekstowy był niewystarczający:

wprowadź opis zdjęcia tutaj

— hobodave
źródło

wow, to brutalne. Dobra robota, znajdowanie tego. Założę się, że to też nie pojawia się w logach, prawda?

— gravyface

@gravyface: poprawne, nic nie jest rejestrowane. Wszystkie logi pokazują podstawowe próby łączenia / uwierzytelniania

— hobodave

Whaaaaaaaaaaaaaaaat? Dobra robota HP!

— voretaq7

To jest do bani; wkręciłby (np.) NTP i DNS-serwer. Słowami voretaq: „dobra robota. HP”. Jednak dobrze zdiagnozowany hobodave; zasługujesz na piwo!

— MadHatter

+1 - Natknąłem się na to dzisiaj z tym samym przełącznikiem w innej aplikacji. Protokół SonicWALL „Single Sign-On” używa datagramów UDP z tymi samymi portami źródłowymi / docelowymi. Chciałbym tu zajrzeć przed wyśledzeniem go za pomocą kranu Ethernet. Warto zauważyć, że ramki „obrażające” są nawet usuwane podczas tworzenia kopii lustrzanej portu wejściowego. Całkowity błąd, HP. Mogę potwierdzić, że oprogramowanie wewnętrzne PK 1.15, wydane w styczniu, nadal ma tę wadę.

— Evan Anderson