Como rastrear interfaces de saída?

O comando Unix tracerouterastreia os endereços IP dos nós de um nó de origem para um nó de destino. Cada nó intermediário possui uma interface de entrada e saída.

traceroute

A execução traceroute -n dstem srcmostra os endereços IP de src, dst e todas as interfaces de entrada dos saltos intermediários.

Mas como rastrear os endereços IP de saída?

Atualizar

Eu tentei a ping -Rsugestão, mas ela não parece funcionar. Este é o traceroute para um servidor web público:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) bytes de dados.
64 bytes de 212.227.222.9: icmp_req = 1 ttl = 57 time = 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 estatísticas de ping ---
1 pacotes transmitidos, 1 recebido, 0% de perda de pacotes, tempo 0ms
rtt min / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

E este é o endereço IP da minha conexão dial-up.

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

Mas não foi gravado pelo comando ping. Qual pode ser a razão?

ping traceroute

— ceving
fonte

Dica: a maneira mais rápida de obter seu IP público é curl ifconfig.me. Coisa mais simples da internet. Mãos para baixo.

— Ryan Foley

O ICMP nunca fornecerá as informações que você deseja obter com precisão. O comportamento padrão é usar a interface de saída da mensagem ICMP, mas geralmente ela pode ser configurada para ser originada de outras interfaces. Digamos que eu tenha um roteador da Internet que esteja usando o endereçamento RFC1918 entre as interfaces do roteador dentro da minha própria rede, mas não quero fornecer esses endereços ao público, posso atribuir um IP público a uma interface de loopback e obter todo o tráfego ICMP da fonte essa interface. Você não está recebendo as interfaces "de entrada" nem "de saída" e nunca receberá esse dispositivo.

— YLearn

@RyanFoley ifconfig.me não é confiável (1 erro em 5 testes) e é lento: uma consulta demora 2,8 segundos. A caixa de ferramentas do Google precisa de 0,7s.

— ceving

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.

— Ron Maupin

Respostas:

Não sou exatamente a resposta da sua pergunta, mas é uma maneira simples (mas limitada) de fazer (em certos casos) o que você deseja. Estou lidando com a opção -R da página do manual ping:

-R Gravar rota. Inclui a opção RECORD_ROUTE no pacote ECHO_REQUEST e exibe o buffer de rota nos pacotes retornados. Observe que o cabeçalho IP é grande o suficiente apenas para nove dessas rotas. Muitos hosts ignoram ou descartam essa opção.

Assim, você também pode ver o caminho de retorno do ECHO_REQUEST, que não é a interface de saída (sobre a qual você está perguntando), a menos que o caminho de saída seja o mesmo do caminho de retorno. Somente nesse caso, o caminho de retorno é o endereço IP da interface de saída que você está solicitando.

Esse é um exemplo real da minha rede de provedores de internet, talvez não seja tão claro, mas agora não tenho um roteador para se conectar :) 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) bytes de dados.

64 bytes de 10.2.105.178: icmp_req = 5 ttl = 253 time = 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

---- omitido ----

64 bytes de 10.2.105.178: icmp_req = 6 ttl = 253 time = 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 ## mudam sempre, não sei por que ##

10.189.48.1

192.168.1.254

192.168.1.133

— feligiotti
fonte

Não sei se entendi corretamente o que RECORD_ROUTE faz, mas não parece ser o que eu preciso. Eu tentei com uma conexão dial-up. Conheço o endereço público do meu roteador dial-up e tenho uma rota de nove saltos para um servidor público na web. Para cada um dos saltos, tentei a -Ropção. O quarto salto foi o primeiro, que respondeu ao pedido. Mas a resposta não contém meu endereço público. E embora tenha sido apenas o quarto salto, a resposta contém 9 endereços.

— ceving

só um momento, estou preparando um exemplo

— feligiotti

O ping -Rdeve ser útil apenas para saltos muito limitados. Eu digo antes que é uma maneira restrita

— feligiotti

O mesmo exemplo não funciona na minha rede dial-up. Eu não tenho ideia do porquê. Talvez NAT?

— ceving 08/10/19

Oi @Ceving, faça um traceroute 212.227.222.9e depois faça um ping -R para o terceiro salto que você encontrou no traceroute. Dessa forma, você tem o mesmo esquema que eu fiz para ler a resposta. Os nove rota total de movimento média e voltar, por isso, se você faz ping -R 212.227.222.9que você não pode ver o caminho completo, mas apenas a última parte

— feligiotti

De acordo com o RFC1812, o endereço de origem da mensagem ICMP gerada pelo roteador deve ser o da interface de saída pela qual o pacote normalmente retornaria ao remetente.

Na realidade, é muito provável que você enfrente um comportamento fora do padrão, em que o roteador fornecerá a resposta ICMP com a fonte da interface de entrada. Isso geralmente facilita a leitura do traceroute.

Como acompanhamento da pergunta do YLearn, estou postando um diagrama de rede e algumas saídas. Exemplo de topologia para ilustrar como o traceroute funciona

Vamos supor que estamos buscando o traceroute do loopback R5 5.5.5.5 para o loopback R1 1.1.1.1. Como você pode ver, o caminho direto é via R4-R2, enquanto o caminho reverso é 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

A saída do traceroute do R5 é a seguinte:

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

Portanto, enquanto o tráfego ICMP real gerado por R1 está voltando para R5 via R3, o cabeçalho IP da mensagem Inacessível ICMP terá a fonte da interface de entrada 10.1.12.1.

Na minha experiência, como os roteadores Cisco e Juniper se comportam, não tenho certeza sobre outros fornecedores.

— mkurek
fonte

Provavelmente só eu, mas a segunda frase me deixa um pouco confuso. Você está dizendo que é comum que um dispositivo na Internet responda usando a interface de entrada do tráfego que causou a geração da mensagem ICMP? Portanto, se o tráfego for recebido no Int1 e a mensagem ICMP sair do Int2, ele será originado no Int1? Ou você está se referindo a uma interface de entrada diferente (e se sim, qual)? Na minha experiência, a maioria dos roteadores funciona como os estados da RFC, usando a interface de saída da mensagem por padrão, e na maioria dos casos essa é a mesma interface em que o tráfego foi recebido.

— YLearn