Diagnostyka sieci

WebHMI jako router umożliwia wykorzystanie standardowym poleceń terminala w celu diagnostyki problemów sieciowych.

Diagnostyka sieci w WebHMI

W celu przejścia do narzędzi do diagnostyki sieci należy wejść do ustawień sieciowych, a następnie do zakładki „Sieć” (1) → „Diagnostyka” (2).

Dostępne mamy trzy polecenia:

• ping (1),
• traceroute (2),
• nslookup (3).

Każde z nich posiada osobne pole adresu. Po kliknięciu na jeden z przycisków poleceń zobaczymy wynik działania polecenia.

Polecenie „ping”

Opis i zastosowanie

Polecenie „ping” jest jedną z podstawowych metod służących do diagnostyki sieci komputerowych TCP/IP. Oparty jest on o protokół ICMP i polega na wysyłaniu zapytań ICMP Echo Request oraz odbiorze komunikatów ICMP Echo Reply. WebHMI wykonując polecenie „ping” wysyła 5 zapytań.

Za pomocą polecenia „ping” możemy zbadać na WebHMI:

• Osiągalność innych urządzeń sieciowych – Wysyłając „ping” na konkretny adres IP możemy sprawdzić czy WebHMI widzi w sieci inne urządzenie, np. sterownik PLC czy router.
  Może się zdarzyć tak, że urządzenie będzie osiągalne w sieci, ale nie będzie odpowiadać na polecenie „ping”, ponieważ reguły fire-walla na urządzeniu docelowym nie pozwalają na odbiór żądań ICMP Echo Request. W ten sposób są skonfigurowane np. domyślne ustawienia Windows Firewall.
• Osiągalność routera – Jeśli potrzebujesz mieć dostęp do urządzeń spoza podsieci, w której znajduje się WebHMI, lub dostęp do Internetu, lecz widzimy, że go nie mamy, to należy sprawdzić czy WebHMI widzi w sieci router. Jeśli router odpowiada na polecenie „ping”, to oznacza że problem jest poza WebHMI i naszą lokalną siecią. Wtedy należy sprawdzić poprawność konfiguracji routera i poprawnośc jego działania, a w przypadku potrzeby dostępu do Internetu czy problem nie leży po stronie ISP.
• Opóźnienie w przesyle pakietów – Zbyt duże opóźnienie w przesyłaniu pakietów może powodować opóźnienia również w komunikacji przy wykorzystaniu protokołów typu Modbus TCP, a w efekcie również spowolnienie aplikacji SCADA na WebHMI.
• Czas życia pakietów TTL – Przekroczenia czasu Time-to-live mogą świadczyć o złej konfiguracji sieci, np. o występowaniu pętli w sieci.
• Adres IP domeny – Jeśli WebHMI sygnalizuje, że jest brak połączenia z Internetem albo widzimy że łącze działa nieprawidłowo ponieważ np. nie możemy przeprowadzić aktualizacji firmware’u lub nie możemy uzyskać stabilnego połączenia VPN z wykorzystaniem chmury level2, to należy sprawdzić czy nazwy domen rozwiązują się prawidłowo na adresy IP za pomocą polecenia „nslookup”. Jeśli nie, to może oznaczać, że WebHMI nie może odnaleźć serwera DNS,

Przykłady wyników działania polecenia

Na pierwszym przykładzie powyżej widzimy standardowy wynik polecenia „ping” wysłany do osiągalnego adresu domeny. Przeanalizujmy go krok po kroku.

W pierwszej linijce (1) widzimy kolejno:

• nazwę polecenia („PING”),
• nazwę docelowej domeny („webhmi.com.ua”),
• rozwiązany adres IP domeny (46.101.172.148)
• oraz ilość wysłanych bytów danych.

Kolejne linie (2) pokazują otrzymane odpowiedzi. WebHMI, które jest oparte na systemie operacyjnym OpenWRT bazującym na Linuxie, wysyła 5 żądań ICMP Echo Request. Kolejno widzimy informacje:

• ilość bytów w odpowiedzi („64 bytes”)
• skąd przyszła odpowiedź („from 46.101.172.148”),
• na które żądanie z kolei („seq=0”, „seq=2” itd.),
• czas życia pakietu („ttl=53”),
• czas od wysłania żądania do czasu otrzymania odpowiedzi („time=26.432 ms”).

W ostatniej części wydruku (3) widzimy statystyki obliczone na podstawie uzyskanych odpowiedzi – ile pakietów zostało wysłanych, ile zostało otrzymanych, ile procent zostało utraconych, a także średni, minimalny i maksymalny czas odpowiedzi.

Dla porównania wykonanie polecenia „ping” dla osiągalnego adresu IP – jedyna różnica będzie taka, że zamiast nazwy strony w wydruku zobaczymy adres IP. Widzimy też znacząco większe czasy TTL oraz krótsze czasy odpowiedzi, co wynika z tego, że żądania były wysyłane do maszyny wirtualnej WebHMI znajdujące się na laptopie w tej samej sieci lokalnej.

W kolejnym przykładzie widzimy komunikat o nieprawidłowym adresie strony: Przyczyną mogą być:

• błędny adres strony, np. strona nie istnieje, jest niedostępna lub jest literówka a adresie,
• nazwa nie może być rozwiązana na adres IP, co zwykle oznacza brak połączenia z serwerem DNS.

W ostatnim przykładzie widzimy, że wszystkie wysłane pakiety zostały utracone. Możliwe przyczyny to:

• urządzenie o danym adresie IP jest niedostępne, np. jest wyłączone albo znajduje się w podsieci nieosiągalnej z poziomu danego WebHMI,
• zostaje przekroczony czas odpowiedzi, co może być spowodowane problemami z infrastrukturą sieciową, np. słaba moc sygnału Wi-FI,
• na docelowym urządzeniu jest zablokowana opcja odbierania pakietów ICMP Echo Request, np. domyślne ustawienia Windows Defender w systemie Windows 10.

Polecenie „traceroute”

Opis i zastosowanie

Polecenie „traceroute” służy do określania trasy przebiegu wysyłanych pakietów. WebHMI, które od strony systemu operacyjnego jest oparte na OpenWRT, wysyła w ramach wykonywania polecenia pakiety UDP podobnie jak to się dzieje w większości innych systemów Unixowowych, a w przeciwieństwie do polecenia „tracert” w systemie Windows.

Jego działanie polega na wysyłaniu kolejnych żądań UDP o coraz dłuższym limicie czasu życia pakietów TTL. Dzięki temu otrzymujemy informację gdzie znajdują się kolejne miejsca gdzie trafiają pakiety i w jakim czasie.

Podstawowym zastosowaniem „traceroute” jest śledzenie drogi pakietów, która w rozbudowanych sieciach może wykorzystywać kilka różnych tras. Pozwala też wykrywać błędy w konfiguracji sieci prowadzące do powstawania pętli.

Przykłady wyników działania polecenia

Na zrzucie ekranu powyżej widzimy efekt działania polecenia „traceroute” do adresu HTTP osiągalnego dla WebHMI. Widzimy w pierwszej linijce kolejno:

• nazwę polecenia („traceroute”),
• nazwę docelowej strony („webhmi.com.ua”),
• rozwiązany adres IP (46.101.172.148)
• informację o limicie ilości skoków wynoszącym 30 oraz o ilości wysłanych bytów danych.

W następnych widzimy efekt w postaci listy kolejnych miejsc skoku, gdzie na pierwszym miejscu jest router naszego ISP, a na ostatnim miejsce docelowe.

Gwiazdki ” * ” oznaczają brak odpowiedzi na dany pakiet. Może to świadczyć o celowej konfiguracji urządzeń znajdujących się na drodze danego pakietu (np. ustawienia firewalli) lub przeciążeniu sieci.

Powyżej widzimy przykład wykonania polecenia do adresu IP do maszyny wirtualnej WebHMI znajdującej się w tej samej sieci lokalnej. Warto zauważyć, że w tym przypadku pakiet trafił bezpośrednio do adresu docelowego, ponieważ obydwa interfejsy znajdują się w tej samej podsieci i nie było potrzebne pośrednictwo routera.

W kolejnym przykładzie widzimy komunikat o nieprawidłowym adresie strony: Przyczyną mogą być:

• błędny adres strony, np. strona nie istnieje, jest niedostępna lub jest literówka a adresie,
• nazwa nie może być rozwiązana na adres IP, co zwykle oznacza brak połączenia z serwerem DNS.

Może się też zdarzyć, że wszystkie wysyłane pakiety zostają utracone po drodze, co może być spowodowane:

• urządzenie o danym adresie IP jest niedostępne, np. jest wyłączone albo znajduje się w podsieci nieosiągalnej z poziomu danego WebHMI (w przypadku gdy adres docelowy znajduje się w innej podsieci, a mamy skonfigurowany adres bramy domyślnej, to pojawi się on w pierwszym wpisie – pakiety dotrą do bramy domyślnej, a dopiero później zostaną utracone),
• zostaje przekroczony czas odpowiedzi, co może być spowodowane problemami z infrastrukturą sieciową, np. słaba moc sygnału Wi-FI,
• na docelowym urządzeniu jest zablokowana opcja odbierania pakietów UDP, np. domyślne ustawienia Windows Defender.

W takiej sytuacji WebHMI wyśle maksymalną ilość pakietów, czyli 30.

Polecenie „nslookup”

Opis i zastosowania

Podstawowym przeznaczeniem polecenia „nslookup” jest dostarczanie informacji na temat serwerów DNS.

W WebHMI najczęściej jest używany do sprawdzenia czy mamy dostęp do serwera DNS podczas diagnostyki połączenia z Internetem.

Przykłady wyników działania polecenia

Po uruchomieniu polecenia „nslookup” otrzymamy następujący wynik:

• nazwę polecenia („nslookup”),
• nazwę celu („level2.webhmi.com.ua”),
• rozwiązany adres IPv4 (46.101.172.148)
• revDNS („webhmi.com.ua).

W drugim przykładzie pokazujemy sytuację, w której nazwa nie może być prawidłowo rozwiązana na adres IP. Możliwe przyczyny to:

• błędny adres strony, np. strona nie istnieje, jest niedostępna lub jest literówka a adresie,
• brak dostępu do serwera DNS, np. nieprawidłowo skonfigurowany router lub blokada dostępu przez administratora.