Bagaimana cara melacak antarmuka keluar?

Perintah Unix traceroutemelacak alamat IP dari node dari node sumber ke node tujuan. Setiap node di antaranya memiliki antarmuka masuk dan keluar.

traceroute

Menjalankan traceroute -n dstpada srcakan menunjukkan alamat IP src, dst dan semua antarmuka yang masuk dari hop di antaranya.

Tapi bagaimana cara melacak alamat IP outging?

Memperbarui

Saya mencoba ping -Rsaran tetapi sepertinya tidak berhasil. Ini adalah pelacak ke server web publik:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) byte data.
64 byte dari 212.227.222.9: icmp_req = 1 ttl = 57 waktu = 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 statistik ping ---
1 paket dikirimkan, 1 diterima, kehilangan paket 0%, waktu 0ms
rtt min / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

Dan ini adalah alamat IP dari koneksi dial-up saya.

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

Tapi itu belum direkam oleh perintah ping. Apa yang bisa menjadi alasan?

ping traceroute

— ceving
sumber

Kiat: cara tercepat untuk mendapatkan IP publik Anda adalah curl ifconfig.me. Hal paling sederhana di internet. Tangan ke bawah.

— Ryan Foley

ICMP tidak akan pernah memberi Anda informasi yang Anda cari secara akurat. Perilaku default adalah dengan menggunakan antarmuka egress dari pesan ICMP, tetapi umumnya dapat dikonfigurasi untuk bersumber dari antarmuka lain. Katakanlah saya memiliki router internet yang menggunakan pengalamatan RFC1918 antara antarmuka router dalam jaringan saya sendiri, tetapi saya tidak ingin memberikan alamat tersebut kepada publik, saya dapat menetapkan IP publik ke antarmuka loopback dan sumber semua lalu lintas ICMP dari antarmuka itu. Anda tidak mendapatkan antarmuka "masuk" maupun "keluar" dan tidak akan pernah dari perangkat itu.

— YPelajari

@RyanFoley ifconfig.me tidak dapat diandalkan (1 kesalahan dalam 5 tes) dan lambat: permintaan membutuhkan 2,8s. Toolbox Google membutuhkan 0.7s.

— ceving

Apakah ada jawaban yang membantu Anda? jika demikian, Anda harus menerima jawabannya sehingga pertanyaan tidak terus muncul selamanya, mencari jawaban. Atau, Anda bisa memberikan dan menerima jawaban Anda sendiri.

— Ron Maupin

Jawaban:

Saya tidak persis jawaban atas pertanyaan Anda, tetapi itu cara sederhana (tetapi terbatas) untuk melakukan (dalam kasus tertentu) apa yang Anda inginkan. Saya mengatasi-memposting opsi -R halaman ping manual:

-R Rekam rute. Termasuk opsi RECORD_ROUTE dalam paket ECHO_REQUEST dan menampilkan buffer rute pada paket yang dikembalikan. Perhatikan bahwa header IP hanya cukup besar untuk sembilan rute seperti itu. Banyak host mengabaikan atau membuang opsi ini.

Jadi, Anda juga dapat melihat jalur pengembalian ECHO_REQUEST, yang bukan antarmuka keluar (yang Anda tanyakan) kecuali jalur keluar sama dengan jalur kembali. Hanya dalam kasus ini, jalur kembali adalah alamat IP dari antarmuka keluar yang Anda minta.

Itu contoh nyata di internet penyedia internet saya, mungkin tidak begitu jelas, tapi saya tidak punya beberapa router untuk terhubung satu sama lain :) 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 data

64 byte dari 10.2.105.178: icmp_req = 5 ttl = 253 waktu = 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

---- dihilangkan ----

64 byte dari 10.2.105.178: icmp_req = 6 ttl = 253 waktu = 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 ## berubah setiap waktu, Saya tidak tahu mengapa ##

10.189.48.1

192.168.1.254

192.168.1.133

— feligiotti
sumber

Saya tidak yakin jika saya mengerti dengan benar apa yang RECORD_ROUTE lakukan, tetapi sepertinya tidak, apa yang saya butuhkan. Saya mencobanya dengan koneksi dial-up. Saya tahu alamat publik router dial-up saya dan saya memiliki rute sembilan hop ke server web publik. Untuk setiap hop saya mencoba -Ropsi. Hop keempat adalah yang pertama, yang menjawab permintaan itu. Tetapi jawabannya tidak mengandung alamat publik saya. Dan meskipun itu hanya hop keempat, jawabannya berisi 9 alamat.

— ceving

sesaat, saya sedang mempersiapkan contoh

— feligiotti

Ini ping -Rakan berguna hanya untuk hop yang sangat terbatas. Saya katakan sebelumnya bahwa itu adalah cara yang terbatas

— feligiotti

Contoh yang sama tidak berfungsi untuk jaringan dial-up saya. Saya tidak tahu kenapa. Mungkin NAT?

— ceving

Hai @Ceving, lakukan a traceroute 212.227.222.9lalu lakukan a ping -R hingga hop ketiga yang Anda temukan di traceroute. Dengan cara itu Anda memiliki skema yang sama yang saya lakukan untuk membaca jawabannya. Sembilan rute total berarti pergi dan kembali, jadi jika Anda melakukannya, ping -R 212.227.222.9Anda tidak dapat melihat jalur penuh, tetapi hanya bagian terakhir

— feligiotti

Menurut RFC1812 alamat sumber pesan ICMP yang dihasilkan oleh router harus dari antarmuka jalan keluar tempat paket biasanya akan kembali ke pengirim.

Pada kenyataannya, sangat mungkin bahwa Anda akan menghadapi perilaku tidak standar di mana router akan mencari balasan ICMP dengan sumber antarmuka masuknya. Ini biasanya membuat traceroute lebih mudah dibaca.

Sebagai tindak lanjut dari pertanyaan YLearn, saya memposting diagram jaringan dan beberapa output. Contoh topologi untuk menggambarkan cara kerja traceroute

Mari kita asumsikan kita membuat traceroute dari loopback R5 5.5.5.5 ke loopback R1 1.1.1.1. Seperti yang Anda lihat, jalur maju adalah melalui R4-R2, sedangkan jalur sebaliknya adalah 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

Output traceroute dari R5 terlihat sebagai berikut:

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

Jadi sementara lalu lintas ICMP aktual yang dihasilkan oleh R1 akan kembali ke R5 melalui R3, header IP dari pesan ICMP Unreachable akan memiliki sumber antarmuka masuknya 10.1.12.1.

Dalam pengalaman saya ini bagaimana perilaku router Cisco dan Juniper, saya tidak yakin tentang vendor lain.

— mkurek
sumber

Mungkin hanya saya, tetapi kalimat kedua membuat saya sedikit bingung. Apakah Anda mengatakan bahwa suatu perangkat di internet umum merespons dengan menggunakan antarmuka masuknya lalu lintas yang menyebabkan timbulnya pesan ICMP? Jadi jika lalu lintas diterima di Int1, dan pesan ICMP keluar Int2, bersumber dari Int1? Atau apakah Anda merujuk ke antarmuka masuknya berbeda (dan jika demikian, yang mana)? Dalam pengalaman saya, sebagian besar router berfungsi sebagai status RFC, menggunakan antarmuka jalan keluar pesan secara default, dan bahwa dalam kebanyakan kasus ini adalah antarmuka yang sama dengan lalu lintas yang diterima.

— YPelajari