RootUsers (Polski)

większość z nas zna proste polecenie 'ping' oparte na ICMP, które pozwala nam przetestować podstawową odpowiedź z jakiegoś urządzenia podłączonego do sieci. Chociaż świetnie nadaje się do podstawowego rozwiązywania problemów, nie pozwala nam potwierdzić, czy dany host na drugim końcu odpowiada na portach TCP lub UDP, na których prawdopodobnie zostanie dostarczona większość usług.,

Ping to nie wszystko i nie koniec rozwiązywania problemów z siecią, jeśli zapora ogniowa blokuje przychodzący ruch ICMP, ping nie powiedzie się, co może spowodować fałszywe postrzeganie, że host jest wyłączony, ponieważ nie reaguje na ping, jednak inne usługi mogą nadal reagować dobrze.

alternatywnie, podczas gdy ping może wrócić dobrze z odpowiedzią, nie wskazuje, czy serwer WWW odpowiada na porcie 80 na żądania HTTP, serwer WWW może nie działać i już nie odpowiada.

więc jeśli ping jest oparty na ICMP, czy możemy zamiast tego wybrać port TCP lub UDP?, Odpowiedź brzmi: tak, rzućmy okiem.

wprowadź tcping

tcping jest jednym z takich narzędzi, które można użyć do sprawdzenia, czy port TCP odpowiada, istnieje kilka wersji dostępnych jednak używam tej: http://www.elifulkerson.com/projects/tcping.php

podręcznik znajduje się na tej samej stronie, w zasadzie można uruchomić polecenie podobne do poniższego.

tutaj używamy tcping aby sprawdzić port 443 na google.com. jak widać port jest wyświetlany jako otwarty i odpowiada, jeśli port nie jest otwarty, domyślnie będzie wyświetlany jako Brak odpowiedzi po 2000ms.,

Możesz również użyć telnetu do testowania połączenia TCP z portem, jednak narzędzie tcping zapewnia dalsze funkcje opisane w sekcji użycie tutaj. Niektóre takie funkcje obejmują możliwość ciągłego uruchamiania testu, pozwalając na generowanie ruchu, na który należy uważać w przechwytywaniu pakietów NA ŻYWO, a także czas reakcji.

a co z UDP?

ponieważ UDP jest protokołem bezpołączeniowym, określenie, czy odpowiada, jest nieco inne., TCP' ping ' działa poprzez wykonanie trójdrożnego uścisku dłoni, źródło wyśle SYN do miejsca docelowego, miejsce docelowe odpowie SYN-ACK, a źródło wyśle ACK kończący uścisk dłoni i nawiązujący połączenie. Ponieważ UDP nie ustanawia połączenia, nie możemy po prostu szukać tego, aby określić, czy port odpowiada, zamiast tego musimy wysłać konkretne dane i sprawdzić, czy otrzymamy odpowiedź.

NMAP jest do tego świetnym narzędziem, możesz go pobrać i użyć do skanowania portu adresu docelowego w celu określenia, które porty są otwarte.,

w tym przykładzie pytamy, czy 8.8.8.8 odpowiada na porcie UDP 53, ponieważ obsługuje DNS, spodziewamy się, że będzie otwarty.<|p>

wynik open / filtered jest używany, gdy nmap nie jest w stanie określić, czy port jest otwarty lub filtrowany, otwarty port może nie dać odpowiedzi. Pokazuje, że usługa została zidentyfikowana jako „domena”, ponieważ służy do obsługi DNS. Przetestowałem to na innych serwerach DNS w Internecie, a niektóre pokazują jako otwarte tylko potwierdzając, że odpowiadają.

NMAP może być również użyty do sprawdzenia, czy port TCP jest otwarty w podobny sposób, wystarczy zmienić-sU na-sT.,

dlaczego port może nie odpowiedzieć

istnieje kilka prostych powodów, dla których port może nie odpowiedzieć na twój test.

• zapora sieciowa blokuje ruch: może istnieć zapora sieciowa działająca między źródłem a miejscem docelowym filtrująca ruch w zależności od obowiązujących reguł, nawet jeśli wiesz, że miejsce docelowe powinno odpowiadać na danym porcie.
• miejsce docelowe może nie nasłuchiwać na porcie: Mówiąc najprościej, miejsce docelowe, z którym próbujesz się połączyć, może nie mieć żadnych usług nasłuchujących na określonym porcie, więc nie będzie żadnej odpowiedzi., Może się to również zdarzyć, jeśli usługa została zatrzymana, na przykład jeśli zatrzymasz Apache serwer WWW nie będzie już odpowiadał na żądania Portu 80.
• istnieje inny problem sieciowy między źródłem a miejscem docelowym ruchu: może wystąpić dowolna liczba problemów z łącznością sieciową między źródłem a miejscem docelowym, jeśli to możliwe, sprawdź sieć jednak jeśli ruch przemieszcza się przez Internet, będziesz ograniczony w tym, co możesz sprawdzić.,

Możesz sprawdzić łączność wzdłuż ścieżki ruchu, uruchamiając przechwytywanie pakietów za pomocą czegoś takiego jak Wireshark lub tcpdump, to pokaże ci, gdzie ruch dociera i gdzie jest zatrzymywany na trasie. Możesz go uruchomić na serwerach źródłowych i docelowych, a także na urządzeniach, do których masz dostęp, takich jak zapory sieciowe lub routery. Śledź przepływ ruchu, dopóki nie określisz, gdzie jest problem.,

podsumowanie

podczas wykonywania 'Pingu' TCP do miejsca docelowego możesz potwierdzić, czy odpowiada zgodnie z przeznaczeniem, chociaż istnieje kilka powodów, dla których port może nie odpowiadać zgodnie z opisem. UDP można sprawdzić, jednak trochę trudniej jest mieć pewność, czy prawidłowo otrzymujesz odpowiedź, więc testy nie zawsze są wiarygodne, co ma sens, ponieważ UDP nie jest niezawodnym protokołem. Testy te mogą być przydatne podczas testowania zabezpieczeń, potwierdzając, czy porty są otwarte czy zamknięte.