I pacchetti restituiscono ma il traceroute non riesce

Ottengo questa output da traceroute:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72 1 192.168.12.1 (192.168.12.1) 1.410 ms 2.076 ms 2.251 ms 2 * * * 3 * * * etc.. 

Ma in un altro terminal posso vedere le risposte corrette (Porta irraggiungibile) che arrivano dall'host di destinazione:

 9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable) 

In un primo momento ho pensato che fosse un problema di firewall, ma ho controllato e nessun pacchetto viene eliminato. L'unica cosa che viene in mente è che questa è la seconda NIC …

Se eseguo traceroute allo stesso host sulla prima NIC, ottengo la stessa traccia di wireshark come sopra (ovviamente con un'altra IP di origine), ma il command traceroute riesce.

Non capisco come il wireshark possa vedere le risposte ma la traceroute fallisce sulla seconda NIC.

Penso che mi manca qualcosa di piuttosto semplice qui …

  • Quali sono i cavi / scatole richiesti per l'ascolto su un cavo RJ45?
  • È ansible eseguire una cattura di pacchetti (wireshark) mentre è stata eseguita in runtime su un server?
  • Il modo migliore per analizzare i file PCAP da Wireshark?
  • Cosa provoca una port switch per ricevere dati non destinati?
  • Stampa a printingnti condivise tramite VPN
  • Come faccio a scoprire che cosa è tutto questo traffico?
  • Qual è la syntax corretta per tcp.dstport nei filtri di visualizzazione
  • Come posso monitorare il traffico HTTPS con Wireshark?
  • 2 Solutions collect form web for “I pacchetti restituiscono ma il traceroute non riesce”

    Wireshark mostrerà cosa arriva sull'interface di networking. Il kernel ha ovviamente visto quei pacchetti, ma per qualche ragione ha deciso che non devono essere consegnati al command traceroute.

    Ci sono alcune cose che potrebbero essere andate storte, causando che il kernel decida di non consegnare tali pacchetti.

    • Puoi avere un routing asimmetrico che non è adatto per il filter del path inverso, ma ha lasciato abilitato rp_filter .
    • Il kernel potrebbe non essere in grado di corrispondere il contenuto del messaggio di errore ICMP con una socket locale. Ciò potrebbe accadere perché il pacchetto è stato troncato con informazioni insufficienti disponibili per prendere questa decisione. Ciò potrebbe accadere anche a causa di una configuration NAT rotta in cui i pacchetti in una direzione vengono inviati attraverso un NAT, ma non nell'altra direzione.
    • Il kernel potrebbe abbandonare i pacchetti a causa di un errore di checksum.

    Di quelli che penso che il rp_filter suona come la spiegazione più probabile. Non è stato specificato un sistema operativo, ma sembra che potrebbe essere un sistema Linux, quindi provate questo command: head /proc/sys/net/ipv4/conf/*/rp_filter . Voi probabilmente vednetworking 1 su ciascuno di essi, il che significa che il filter è abilitato. Provate a scrivere una lettera 0 a quella corrispondente all'interface che viene rimossa dai pacchetti e al nome di all dispositivi.

    Posso submit l'output della tabella di routing di each casella qui? Se si dispone di un path predefinito non valido o mancante, i pacchetti non avranno un path di return. Inserisci l'output di:

    # ip route list

    su each casella di Linux.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.