Pokaż wyniki 1 do 8 z 8

Temat: traceroute tego samego adresu działa, ping nie - zagadka

  1. #1
    Avatar michalski007
    michalski007 jest offline michalski
    Zarejestrowany
    Sep 2006
    Skąd
    Warszawa
    Postów
    137

    Domyślnie traceroute tego samego adresu działa, ping nie - zagadka

    Witam

    Mam taki problem, kiedy uruchamiam komende tracert do śledzenia trasy hosta, program pokazuje mi poszczególne przeskoki (adresy ip), natomiast póżnej chcąc zpingować jeden z podanych porzez tracert adres , ping nie odpowiada. Dodam że firewall, został wyłączony i w systemie i na routerze którego nie da się pingować. Przesyłam dodatkowo zdjecie podanej sytuacji.

    Ma ktoś jakiś pomysł?

    Ponieżej podaje link do sytuacji, spójrzcie na adres 192.168.1.254
    http://www.interka.pl/~zielak/foto.png

  2. #2
    Zarejestrowany
    Sep 2009
    Skąd
    Z Nienacka
    Postów
    396

    Domyślnie

    Witam,

    jeśli dobrze pamiętam to traceroute domyślnie wysyła pakiety udp, a nie icmp...ale mogę się mylić

    Spróbuj traceroute -I adres_ip wtedy będziesz wiedział czy blokuje tylko pingi...

    Pozdrawiam

    EDIT: skoro firewall jest wyłączony sprawdź czy nie masz takich wpisów w sys.ctl:

    net.ipv4.icmp_echo_ignore_broadcasts = 1
    net.ipv4.icmp_echo_ignore_all = 1
    Ostatnio edytowane przez lojciecdyrektor : 10-07-2010 - 16:47

  3. #3
    Zarejestrowany
    Oct 2009
    Postów
    16

    Domyślnie

    hm... mi to wyglada na skopany lan, ewentualnie mocno zagmatwana konfiguracje. Wnioskuje ze maske podsieci masz 255.255.255.0, wiec takim wypadku komp bedzie szukac ip 192.168.1.254 na lanie zamiast wysylac pakiety do 1 routera.

  4. #4
    Zarejestrowany
    Sep 2009
    Skąd
    Z Nienacka
    Postów
    396

    Domyślnie

    Cytat Napisał yumad Zobacz post
    hm... mi to wyglada na skopany lan, ewentualnie mocno zagmatwana konfiguracje. Wnioskuje ze maske podsieci masz 255.255.255.0, wiec takim wypadku komp bedzie szukac ip 192.168.1.254 na lanie zamiast wysylac pakiety do 1 routera.
    tyle, że wtedy imho nie byłoby widocznego przeskoku w traceroute na tym adresie...

    pozdrawiam

  5. #5
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie

    192.168.1.1 to jest twoja brama

    jej zadaniem jest kierowanie pakietow na 192.168.1.254.

    192.168.1.254 to jest urzadzenie robiace nat.


    192.168.1.159 to jakis haxor robiacy arp spoofing ze zle skonfigurowanym systemem.


    ot taka moja opinia.

  6. #6
    Zarejestrowany
    Oct 2009
    Postów
    16

    Domyślnie

    Cytat Napisał lojciecdyrektor Zobacz post
    tyle, że wtedy imho nie byłoby widocznego przeskoku w traceroute na tym adresie...

    pozdrawiam
    Bylby widoczny bo kazdy pakiet wysylany przez traceroute ma google jako adres docelowy (rozwazajac sytuacje ze screena), wiec pakiet leci tak jak go wysylaja... komp na swoja brame czyli router1, router1 na swoja brame czyli router2. Zakladajac nawet ze z router2 pakiet moze wrocic pomijajac router1, to traceroute o tym nie bedzie wiedziec.

    Cytat Napisał linux_aa Zobacz post
    192.168.1.159 to jakis haxor robiacy arp spoofing ze zle skonfigurowanym systemem.


    ot taka moja opinia.
    ale haxor albo jego brak nie daje odpowiedzi na pytanei zadane przez autora watku. Czyli wlasciwie nie ma nic wspolnego z tematem

  7. #7
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    traceroute pod linuxem i pod windows dzialaja roznie - jeden w UDP drugi w ICMP, druga sprawa taka, ze jeden protokol moze byc blokowany, drugi nie... poza tym jak firewall dobrze skonfigurowany to moze blokowac ping a zezwalac na traceroute'a bo widzialem takie dziwactwa czasami w roznych sieciach ale nie wiem dokladnie jak to admini poustawiali

    nie musi byc zadnego haxiora co robi spoofing... wystarczy kreatywny albo bardzo skopany firewall :P
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  8. #8
    Zarejestrowany
    Aug 2007
    Postów
    104

    Domyślnie

    racja, albo ktos jest sprytny, albo skopal konfiguracje; wydaje mi sie, ze to pomoze:
    Kod:
    ping Adres_IP source Adres_IP_intefejsu
    czyli wykorzystanie ping'a z opcja source; czesto takie zabiegi wykonuje sie przy NAT albo podczas tworzenia VPN, zeby wyeliminowac maloznaczacy ruch. Jezeli to nie pomoze wtedy pobaw sie tcpdump na kazdym hoscie przez ktory powinny przechodzic pingi, zobacz gdzie polaczenie sie urywa, dokad dochodzi, jakie sa odpowiedzi, jak wygladaja tablice rutingu albo rutowane. Przyczyna leży w konfiguracji sprzetu. O ile na prawde wylaczyles wszystkie firewall'e. Te na hostach lokalnych jak i te na sprzecie, na I/O sieci

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj