Come tracciare le interfacce in uscita?

Il comando Unix traceroutetraccia gli indirizzi IP dei nodi da un nodo di origine a un nodo di destinazione. Ogni nodo in mezzo ha un'interfaccia in entrata e in uscita.

traceroute

L'esecuzione di traceroute -n dston srcmostrerà gli indirizzi IP di src, dst e tutte le interfacce in entrata degli hop nel mezzo.

Ma come rintracciare gli indirizzi IP in uscita?

Aggiornare

Ho provato il ping -Rsuggerimento ma non sembra funzionare. Questo è il traceroute verso un web server pubblico:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) byte di dati.
64 byte da 212.227.222.9: icmp_req = 1 ttl = 57 tempo = 47.4 ms
RR: 192.168.2.111
        169.254.1.1
        87.186.224.94
        62.154.76.34
        62.154.12.175
        212.227.117.13
        212.227.117.8
        10.71.3.253
        212.227.222.9


--- 212.227.222.9 statistiche ping ---
1 pacchetti trasmessi, 1 ricevuto, 0% perdita pacchetti, tempo 0ms
rtt min / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

E questo è l'indirizzo IP della mia connessione remota.

$ curl -s https://toolbox.googleapps.com/apps/browserinfo/info/ | jq -r .remoteAddr
93.192.75.247

Ma non è stato registrato dal comando ping. Quale può essere la ragione?

ping traceroute

— ceving
fonte

Suggerimento: il modo più rapido per ottenere il tuo IP pubblico è curl ifconfig.me. La cosa più semplice su Internet. Mani giù.

— Ryan Foley,

ICMP non ti fornirà mai le informazioni che desideri ottenere in modo accurato. Il comportamento predefinito è utilizzare l'interfaccia di uscita del messaggio ICMP, ma in genere può essere configurato per essere fornito da altre interfacce. Supponiamo di avere un router Internet che utilizza l'indirizzamento RFC1918 tra le interfacce del router all'interno della mia rete, ma non voglio fornire tali indirizzi al pubblico, posso assegnare un IP pubblico a un'interfaccia di loopback e generare tutto il traffico ICMP da quell'interfaccia. Non stai ricevendo né le interfacce "in entrata" né "in uscita" e non lo farai mai da quel dispositivo.

— YLearn

@RyanFoley ifconfig.me non è affidabile (1 errore in 5 test) ed è lento: una query richiede 2,8 secondi. La cassetta degli attrezzi di Google richiede 0,7 secondi.

— ceving

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

Risposte:

Non sono esattamente la risposta alla tua domanda, ma quel modo semplice (ma limitato) di fare (in certi casi) quello che vuoi. Sto copiando-post l'opzione -R della pagina man ping:

-R Registra percorso. Include l'opzione RECORD_ROUTE nel pacchetto ECHO_REQUEST e visualizza il buffer di route sui pacchetti restituiti. Si noti che l'intestazione IP è abbastanza grande per nove di questi percorsi. Molti host ignorano o scartano questa opzione.

Quindi puoi vedere anche il percorso di ritorno di ECHO_REQUEST, che non è l'interfaccia di uscita (di cui stai chiedendo) a meno che il percorso in uscita sia lo stesso del percorso di ritorno. Solo in questo caso, il percorso di ritorno è l'indirizzo IP dell'interfaccia in uscita richiesta.

Questo è un vero esempio sulla mia rete di provider di Internet, forse non così chiaro, ma non ho solo un router per collegarmi l'un l'altro :) dest 10.2.105.178

traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  3.418 ms  3.575 ms  4.021 ms
 2  10.189.48.1 (10.189.48.1)  11.237 ms * *
 3  10.2.105.178 (10.2.105.178)  15.235 ms * *

ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56 (124) byte di dati.

64 byte dal 10.2.105.178: icmp_req = 5 ttl = 253 tempo = 74,1 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

---- omesso ----

64 byte dal 10.2.105.178: icmp_req = 6 ttl = 253 tempo = 13,0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ## cambia ogni volta, non so perché ##

10.189.48.1

192.168.1.254

192.168.1.133

— feligiotti
fonte

Non sono sicuro di aver capito correttamente cosa fa RECORD_ROUTE, ma non sembra, di cosa ho bisogno. L'ho provato con una connessione remota. Conosco l'indirizzo pubblico del mio router di accesso remoto e ho un percorso di nove hop per un server Web pubblico. Per ciascuno dei luppoli ho provato l' -Ropzione. Il quarto hop è stato il primo a rispondere alla richiesta. Ma la risposta non contiene il mio indirizzo pubblico. E sebbene fosse solo il quarto hop, la risposta contiene 9 indirizzi.

— ceving

solo un momento, sto preparando un esempio

— feligiotti

Il ping -Rsarà utile solo per hop molto limitata. Prima dico che è un modo limitato

— Feligiotti,

Lo stesso esempio non funziona per la mia rete di accesso remoto. Non ho idea del perché. Forse NAT?

— ceving

Ciao @Ceving, fai un traceroute 212.227.222.9e poi fai un ping -R al terzo hop che hai trovato nel traceroute. In questo modo hai lo stesso schema che ho fatto per leggere la risposta. La media totale delle nove rotte va e torna, quindi se lo fai ping -R 212.227.222.9non puoi vedere l'intero percorso, ma solo l'ultima parte

— feligiotti

Secondo RFC1812 l'indirizzo di origine del messaggio ICMP generato dal router dovrebbe essere quello dell'interfaccia di uscita su cui il pacchetto ritornerebbe normalmente al mittente.

In realtà, è molto probabile che si verifichi un comportamento non standard in cui il router invierà la risposta ICMP con l'origine dell'interfaccia di ingresso. Questo di solito rende il traceroute molto più facile da leggere.

Come seguito alla domanda di YLearn sto pubblicando uno schema di rete e alcuni output. Topologia di esempio per illustrare come funziona traceroute

Supponiamo che stiamo inacidendo il traceroute dal loopback di R5 5.5.5.5 al loopback di R1 1.1.1.1. Come puoi vedere, il percorso in avanti è tramite R4-R2, mentre il percorso inverso è R3-R4.

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 4", distance 20, metric 0
Tag 2, type external
Last update from 10.1.24.2 00:02:42 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:02:42 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 10.1.13.3 00:14:18 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.13.3, 00:14:18 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2
  Route tag 3
  MPLS label: none

L'output traceroute di R5 è simile al seguente:

R5#traceroute
Protocol [ip]:
Target IP address: 1.1.1.1
Source address: 5.5.5.5
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 208 msec 140 msec 100 msec
2 10.1.24.2 96 msec 44 msec 104 msec
3 10.1.12.1 224 msec 220 msec 112 msec

Pertanto, mentre il traffico ICMP effettivo generato da R1 torna a R5 tramite R3, l'intestazione IP del messaggio Non raggiungibile ICMP avrà la sorgente dell'interfaccia di ingresso 10.1.12.1.

Nella mia esperienza, come si comportano i router Cisco e Juniper, non sono sicuro degli altri fornitori.

— mkurek
fonte

Probabilmente solo io, ma la seconda frase mi ha un po 'confuso. Stai dicendo che è comune che un dispositivo su Internet risponda utilizzando l'interfaccia di ingresso del traffico che ha causato la generazione del messaggio ICMP? Quindi, se il traffico viene ricevuto su Int1 e il messaggio ICMP esce da Int2, viene da Int1? O ti riferisci a un'altra interfaccia di ingresso (e se sì, quale)? Nella mia esperienza, la maggior parte dei router funziona come indicato dalla RFC, utilizzando l'interfaccia di uscita del messaggio per impostazione predefinita e che nella maggior parte dei casi si tratta della stessa interfaccia su cui è stato ricevuto il traffico.

— YLearn