Problem z komunikacją przez SNMP

Problem z komunikacją przez SNMP wskazuje na zablokowany port UDP 161 przez zaporę lub wyłączoną usługę monitorowania na urządzeniu docelowym.

Problem z komunikacją przez SNMP – czym jest i co oznacza

Problem z komunikacją przez SNMP dotyczy sytuacji, w której urządzenie monitorujące nie może pobrać danych z urządzenia sieciowego, komputera, drukarki, zasilacza awaryjnego albo innego elementu infrastruktury wyposażonego w agenta SNMP. Sam skrót SNMP oznacza Simple Network Management Protocol, czyli protokół służący do odczytywania informacji o stanie urządzenia oraz, w określonych warunkach, do odbierania komunikatów o zdarzeniach. Dzięki niemu można sprawdzać między innymi obciążenie interfejsów, dostępność urządzenia, poziom materiałów eksploatacyjnych, temperaturę, stan pamięci, błędy sprzętowe i inne parametry udostępnione przez producenta.

Brak komunikacji nie musi oznaczać awarii fizycznej. Często przyczyną jest zablokowany ruch UDP, niezgodna konfiguracja wersji protokołu, błędna nazwa społeczności, niewłaściwy adres źródłowy zapytania albo wyłączony agent na urządzeniu docelowym. Zdarza się także, że monitoring wskazuje urządzenie jako niedostępne, chociaż można się z nim połączyć inną metodą. Wynika to z faktu, że dostępność przez panel administracyjny, połączenie ICMP i odpowiedź na zapytanie SNMP są od siebie niezależne.

W praktyce analizę należy prowadzić od warstwy fizycznej i adresacji, przez reguły zapory, aż do ustawień samego agenta. Pozwala to oddzielić problem sieciowy od problemu z uprawnieniami lub formatem zapytania. Istotne jest również ustalenie, czy występuje całkowity brak odpowiedzi, czy tylko brak wybranych danych. Odpowiedź częściowa może wskazywać na ograniczony zestaw obiektów MIB, błąd identyfikatora OID albo ograniczenia zastosowane po stronie urządzenia.

Problem z komunikacją przez SNMP a port, transport i wersja protokołu

Najczęściej używanym portem dla zapytań SNMP jest UDP 161. Jeżeli zapora sieciowa blokuje ruch do tego portu, system monitorujący nie otrzyma odpowiedzi, nawet gdy urządzenie działa prawidłowo. W przypadku komunikatów wysyłanych przez urządzenie do systemu monitorującego stosowany jest zwykle port UDP 162. Trzeba więc rozróżnić zapytania cykliczne od powiadomień typu trap lub inform. Otwarcie jednego kierunku ruchu nie gwarantuje poprawnego działania drugiego.

UDP nie ustanawia trwałego połączenia przed przesłaniem danych. Z tego powodu brak odpowiedzi może wynikać zarówno z filtracji pakietu, jak i z błędnej trasy zwrotnej, nieprawidłowej translacji adresów, przeciążenia urządzenia lub odrzucenia zapytania przez agenta. Warto sprawdzić, z jakiego adresu faktycznie wychodzą pakiety. W środowiskach z wieloma interfejsami narzędzie monitorujące może używać innego adresu źródłowego niż zakładano, a urządzenie docelowe może zezwalać na zapytania tylko z określonej podsieci.

Znaczenie ma także wersja SNMP. Warianty oparte na community string korzystają z prostego mechanizmu identyfikacji, natomiast SNMPv3 może wymagać poprawnego użytkownika, poziomu ochrony, uwierzytelniania oraz szyfrowania. Ustawienie SNMPv3 po stronie monitoringu przy urządzeniu działającym w innej wersji doprowadzi do braku odpowiedzi lub błędów autoryzacji. Podobnie niezgodność między trybem bez uwierzytelniania a trybem wymagającym kontroli integralności może wyglądać jak awaria portu.

W diagnostyce przydatne jest wykonanie kontrolnego zapytania do znanego OID, a następnie porównanie wyniku z zapytaniem używanym przez aplikację monitorującą. Jeżeli narzędzie testowe otrzymuje dane, należy sprawdzić ustawienia hosta, interfejsu, profilu urządzenia i mapowania OID w systemie monitoringu. Jeżeli również test nie daje odpowiedzi, dalsza analiza powinna objąć trasę, reguły zapory i konfigurację agenta.

Problem z komunikacją przez SNMP – typowe problemy konfiguracyjne

Jedną z częstych przyczyn jest wyłączona usługa monitorowania. W wielu urządzeniach agent SNMP może być domyślnie nieaktywny, uruchamiany dopiero po zapisaniu konfiguracji albo zależny od osobnego modułu. Po zmianie ustawień może być wymagane ponowne uruchomienie usługi lub całego urządzenia. Należy też sprawdzić, czy konfiguracja została zatwierdzona, ponieważ część paneli administracyjnych rozdziela zapis ustawień roboczych od ich trwałego zastosowania.

Drugą grupę stanowią błędy w danych dostępowych. Community string musi być zgodny znak po znaku, a wielkość liter może mieć znaczenie. W SNMPv3 trzeba zweryfikować nazwę użytkownika, metodę uwierzytelniania, klucz, metodę szyfrowania i klucz prywatny. Nawet pojedyncza spacja, odmienny algorytm albo użycie innego profilu bezpieczeństwa powoduje odrzucenie żądania. Warto także upewnić się, czy monitoring odwołuje się do właściwego adresu IP, a nie do starego wpisu DNS lub nieaktualnego rekordu urządzenia.

Istotne bywają ograniczenia dostępu. Agent może przyjmować zapytania tylko z podanego adresu, zakresu adresów albo interfejsu. Reguły mogą ograniczać dostęp do określonych obiektów MIB, przez co podstawowa kontrola dostępności działa, ale szczegółowe metryki pozostają puste. Niekiedy producent udostępnia osobne profile dla drukarki, przełącznika, punktu dostępowego lub zasilacza. Wybranie niepasującego profilu może skutkować błędami OID, mimo że sama komunikacja jest poprawna.

Występują również problemy wynikające ze zmian w sieci. Zmiana adresacji, maski, bramy, segmentu logicznego lub reguł filtracji może przerwać dostęp do portu UDP 161. W przypadku połączeń przez tunel albo dodatkowe urządzenie filtrujące należy ustalić, czy pakiety są przekazywane w obu kierunkach. Pomocne jest porównanie działającego urządzenia z urządzeniem niedostępnym oraz sprawdzenie logów zapory, agenta i aplikacji monitorującej w zbliżonym czasie.

Problem z komunikacją przez SNMP – praktyczne wskazówki diagnostyczne

Najpierw warto zapisać dokładny objaw: brak odpowiedzi, przekroczenie czasu, błąd autoryzacji, nieznany OID, puste wartości czy alarm pojawiający się tylko okresowo. Każdy z tych sygnałów prowadzi do innego obszaru. Przekroczenie czasu częściej wskazuje na filtrację, trasę lub nieaktywny agent, natomiast jawny błąd bezpieczeństwa może oznaczać, że urządzenie odpowiada, lecz odrzuca dane uwierzytelniające.

Następnie należy potwierdzić podstawową łączność z właściwego systemu monitorującego. Sam test ping nie wystarcza, ponieważ może być dozwolony niezależnie od UDP 161. Trzeba sprawdzić adres docelowy, trasę i możliwość wysłania zapytania SNMP. Przydatne jest przechwycenie ruchu na odpowiednim interfejsie. Widoczne zapytania bez odpowiedzi sugerują odrzucenie po stronie urządzenia, filtrację po drodze albo problem z usługą. Brak zapytań w miejscu, w którym powinny się pojawić, kieruje uwagę na aplikację monitorującą, jej harmonogram lub konfigurację hosta.

Zmiany należy wprowadzać pojedynczo i po każdej z nich ponowić test. Nie powinno się jednocześnie zmieniać wersji protokołu, reguł zapory, adresu źródłowego i danych uwierzytelniających, ponieważ utrudnia to ustalenie przyczyny. Przed modyfikacją warto zachować kopię konfiguracji oraz zanotować poprzednie wartości. Jeżeli problem pojawił się po aktualizacji oprogramowania urządzenia, należy porównać dostępne ustawienia agenta i listę obsługiwanych MIB z dokumentacją producenta.

Gdy komunikacja działa tylko czasami, trzeba zwrócić uwagę na opóźnienia, obciążenie urządzenia, limity liczby zapytań i interwał odpytywania. Zbyt częste pobieranie dużej liczby tabel może powodować pomijanie odpowiedzi lub przeciążenie słabszego urządzenia. W takim przypadku pomaga zmniejszenie zakresu odczytywanych danych, wydłużenie interwału oraz rozdzielenie monitorowanych parametrów na mniejsze zestawy. Nie należy jednak traktować tego jako rozwiązania bez sprawdzenia logów i potwierdzenia, że agent rzeczywiście osiąga limit.

Kiedy zgłosić problem z komunikacją przez SNMP do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy podstawowe testy nie wskazują jednoznacznie winnej reguły, a problem utrzymuje się mimo poprawnej adresacji i zgodnych ustawień. Dotyczy to zwłaszcza sytuacji, w której inne urządzenia w tej samej sieci odpowiadają, lecz konkretny sprzęt nie reaguje, konfiguracja jest nieczytelna albo dostęp do panelu administracyjnego jest ograniczony. Warto przekazać opis objawu, adres urządzenia, używaną wersję SNMP, czas wystąpienia problemu oraz informacje o ostatnich zmianach.

Pomoc techniczna może obejmować sprawdzenie konfiguracji sieciowej, reguł zapory, usługi agenta, zgodności profilu monitorującego i poprawności odczytywanych OID. Jeżeli urządzenie traci komunikację także z innymi usługami, konieczne może być szersze badanie jego stanu, interfejsu sieciowego lub oprogramowania. W przypadku sprzętu używanego lokalnie można również zweryfikować, czy problem nie wynika z uszkodzonego przewodu, portu, zasilania albo nieprawidłowej konfiguracji po przywróceniu ustawień fabrycznych.

W Warszawie takie zgłoszenie można przekazać do firmy Serwis laptopów i komputerów PC - Warszawa; naprawy z reguły realizowane są do 3 dni roboczych. Przed przekazaniem urządzenia dobrze jest przygotować kopię konfiguracji, dane kontaktowe do osoby odpowiedzialnej za monitoring oraz informację, czy wymagane jest zachowanie istniejących ustawień. Uporządkowany opis skraca czas rozpoznania i ułatwia ocenę, czy źródłem problemu jest urządzenie, sieć, aplikacja monitorująca czy reguły bezpieczeństwa.