Tinggal beberapa hari lagi sehingga permulaan aliran baharu pada kadar daripada OTUS. Dalam hal ini, kami ingin berkongsi dengan anda terjemahan bahan berguna mengenai topik tersebut.
Satu siri catatan blog tentang petua dan helah untuk menyelesaikan masalah ping IPv6 (Permintaan Gema/Balasan Gema ICMPv6)
Sila ambil perhatian bahawa saya menggunakan Linux (khususnya Fedora 31), namun sintaks arahan ping untuk sistem pengendalian lain diharapkan sangat serupa.
Ping semua nod IPv6 pada saluran
Petua pertama dan paling mudah ialah ping semua nod IPv6 pada pautan.
IPv6 menggunakan alamat multicast untuk semua jenis komunikasi satu-ke-banyak. Tiada alamat IPv6 siaran (atau siaran). Ini membezakan IPv6 daripada IPv4, di mana terdapat beberapa jenis alamat siaran, contohnya, alamat "siaran terhad" 255.255.255.255 [RFC1122].
Walau bagaimanapun, terdapat alamat IPv6 "multicast semua nod", jadi kami akan menggunakannya untuk ping semua nod IPv6 pada pautan. (Alamat "siaran" sebenarnya hanyalah alamat berbilang siaran yang dinamakan khas, iaitu kumpulan berbilang hantaran yang merangkumi semua nod. Ambil perhatian bahawa, sebagai contoh, bit alamat "kumpulan" atau berbilang siaran dihidupkan dalam alamat siaran Ethernet pada lapisan pautan ).
Alamat IPv6 berbilang nod semua nod untuk saluran: ff02::1. ff menandakan alamat IPv6 multicast. 0 seterusnya ialah bahagian bendera dengan bit yang tidak ditetapkan.
Seterusnya 2 mentakrifkan kawasan kumpulan multicast. Tidak seperti alamat IPv4 multicast, alamat IPv6 multicast mempunyai skop. Nilai skop menunjukkan bahagian rangkaian di mana paket multicast dibenarkan untuk dimajukan. Setelah paket mencapai sempadan skop yang ditentukan, paket mesti digugurkan, tidak kira sama ada medan Hop Countnya bukan sifar. Sudah tentu, jika kiraan lompatan mencapai sifar sebelum mencapai sempadan kumpulan multicast yang ditentukan, ia juga ditetapkan semula dengan serta-merta. Berikut ialah senarai lengkap skop multicast IPv6.
Akhirnya, ::1 menentukan kumpulan multicast semua nod.
Mengenai alamat ff02::1 Perlu diingatkan bahawa ia adalah samar-samar. Pada hos IPv6 dengan berbilang antara muka, seperti penghala atau hos berbilang hos, alamatnya ff02::1 tiada apa-apa di mana anda boleh menentukan antara muka untuk menghantar permintaan gema ICMPv6 atau mengharapkan untuk menerima balasan gema ICMPv6 apabila ia tiba. ff02::1 adalah sah dan boleh digunakan pada mana-mana antara muka dan saluran yang dilampirkan pada nod berbilang antara muka.
Oleh itu, apabila kita ping semua nod IPv6 pada pautan, kita perlu juga memberitahu utiliti itu ping untuk IPv6, antara muka yang hendak digunakan.
Menentukan Antara Muka - Pilihan Baris Perintah
Seperti yang telah kita lihat, alamat multicast semua nod yang kita mahu gunakan ialah − ff02::1 - tidak memberikan sebarang maklumat mengenai antara muka untuk menghantar dan menerima permintaan gema ICMPv6 dan paket balasan gema.
Jadi, bagaimanakah cara kita menentukan antara muka yang akan digunakan untuk ruang alamat multicast atau ruang alamat Pautan-Tempatan unicast?
Cara pertama dan paling jelas ialah menyediakannya sebagai parameter kepada aplikasi yang kami gunakan.
Untuk utiliti ping kami menyediakannya melalui pilihan -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Menggunakan ping multicast semua nod ini, kami menerima respons daripada 6 nod IPv6. Respons datang daripada alamat nod IPv6 Link-Local, bermula dengan awalan fe80::/10.
Itu ping tidak terus menghantar permintaan gema ICMPv6 selama-lamanya sehingga kami mengganggunya, kami biasanya menentukan bilangan paket untuk dihantar melalui pilihan -c. Walau bagaimanapun, ini juga menghalang ping daripada menerima dan memaparkan lebih daripada satu balasan gema ICMPv6 apabila menghantar permintaan gema ICMPv6 multicast. Sebaliknya, kami menggunakan pilihan -w untuk menentukan bahawa ping harus selesai selepas 1 saat, tidak kira berapa banyak permintaan gema ICMPv6 atau balasan gema telah dihantar atau diterima.
Perkara lain yang perlu diberi perhatian ialah (DUP!) output pada jawapan kedua dan seterusnya. Paket ini dikenal pasti sebagai tindak balas pendua kerana ia mempunyai nilai jujukan ICMP yang sama seperti permintaan gema ICMPv6 individu yang dihantar pada mulanya. Ia muncul kerana permintaan gema multicast ICMPv6 menghasilkan berbilang respons unicast individu. Bilangan pendua juga ditunjukkan dalam ringkasan statistik.
Menentukan Antara Muka - ID Zon
Satu lagi cara untuk mendedahkan antara muka untuk digunakan adalah sebagai sebahagian daripada parameter alamat IPv6.
Kita boleh melihat contoh ini dalam output ping, di mana alamat hos IPv6 yang bertindak balas juga mempunyai akhiran %enp3s2, sebagai contoh:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msKaedah menentukan antara muka ini diterangkan secara rasmi dalam [RFC4007], "Seni Bina Alamat Ditentukan IPv6." Walaupun ia biasanya dipanggil antara muka sistem pengendalian, ia sebenarnya mentakrifkan sesuatu yang lebih umum—"zon" atau "skop."
Sebab untuk mempunyai lebih banyak zon umum atau zon skop ialah, seperti yang dinyatakan dalam [RFC4007], nod IPv6 boleh mempunyai beberapa antara muka IPv6 berbeza yang disambungkan ke saluran yang sama. Antara muka ini adalah ahli zon yang sama.
Ia sepatutnya boleh mengumpulkan berbilang antara muka dalam zon di bawah sistem pengendalian; Pada masa ini saya tidak tahu sama ada ini boleh dilakukan di bawah Linux atau bagaimana untuk melakukannya.
Menggunakan akhiran %<zone_id>, kita boleh mengalih keluar pilihan baris arahan -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Respons Alamat Pautan-Setempat
Daripada ping multicast semua nod ini, kami menerima sejumlah 6 respons unik.
Respons ini datang daripada alamat hos IPv6 Pautan-Tempatan unicast. Sebagai contoh, inilah jawapan pertama:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAlamat IPv6 Pautan Unicast-Tempatan diperlukan pada semua antara muka yang didayakan IPv6 [RFC4291], "Seni Bina Alamat IP Versi 6". Sebabnya ialah nod IPv6 sentiasa mempunyai alamat IPv6 unicast secara automatik, yang sekurang-kurangnya boleh digunakan untuk berkomunikasi dengan nod lain pada pautannya yang disambungkan secara langsung. Ini termasuk berkomunikasi dengan aplikasi pada hos lain melalui alamat hos Pautan-Setempat.
Ini memudahkan reka bentuk dan pelaksanaan protokol seperti IPv6 Neighbor Discovery dan OSPFv3. Ia juga membenarkan aplikasi pengguna akhir pada hos untuk berkomunikasi melalui saluran tanpa memerlukan sebarang infrastruktur IPv6 sokongan lain pada saluran tersebut. Komunikasi terus antara hos IPv6 yang disambungkan tidak memerlukan penghala IPv6 atau pelayan DHCPv6 pada sambungan.
Alamat Pautan-Setempat bermula dengan awalan 10-bit fe80, diikuti dengan 54 bit sifar dan kemudian pengecam antara muka (IID) 64-bit. Dalam jawapan pertama di atas 2392:6213:a15b:66ff ialah IID 64-bit.
Multicast bergelung
Secara lalai, paket multicast dikembalikan secara dalaman ke nod yang menghantarnya. Ini berlaku untuk kedua-dua pengalamatan IPv6 dan IPv4.
Sebab bagi tingkah laku lalai ini ialah apabila paket multicast dihantar, mungkin juga terdapat aplikasi multicast tempatan yang mendengar berjalan pada hos penghantar itu sendiri, serta di suatu tempat di rangkaian. Aplikasi tempatan ini juga mesti menerima paket multicast.
Kita boleh melihat gelung tempatan multicast ini dalam output ping kami:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...Respons pertama dan terpantas (0,106 ms berbanding 0,453 ms) datang daripada alamat Pautan-Setempat yang dikonfigurasikan pada antara muka itu sendiri enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utiliti ping menyediakan cara untuk menyekat maklum balas multicast tempatan menggunakan parameter -L. Jika kami menghantar ping multicast semua nod dengan bendera ini, maka respons terhad kepada nod jauh. Kami tidak menerima respons daripada alamat Pautan-Setempat bagi antara muka penghantaran.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping Link-Alamat Tempatan
Seperti yang anda fikirkan, alamat Pautan-Tempatan unicast dengan sendirinya juga tidak memberikan maklumat yang mencukupi untuk menunjukkan antara muka yang hendak digunakan untuk mencapainya. Seperti ping multicast semua nod, kami juga perlu menentukan antara muka sebagai parameter baris arahan ping atau ID zon dengan alamat apabila ping alamat Pautan-Setempat.
Kali ini kita boleh gunakan -cuntuk mengehadkan bilangan paket dan respons yang dihantar dan diterima ping, kerana kami melakukan ping unicast.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping (semua) alamat IPv6 lain?
Dalam artikel ini, kami melihat cara untuk ping semua nod IPv6 pada saluran menggunakan alamat IPv6 multicast semua nod ff02::1. Kami juga melihat cara untuk menentukan antara muka yang hendak digunakan dengan alamat IPv6 multicast semua nod, kerana alamat itu sendiri tidak dapat memberikan maklumat ini. Kami menggunakan sama ada pilihan baris arahan ping, atau menentukan antara muka menggunakan akhiran %<zone_id>.
Kemudian kami mengetahui tentang alamat Pautan-Tempatan unicast, yang merupakan alamat yang digunakan untuk bertindak balas kepada permintaan gema ICMPv6 multicast semua nod.
Kami juga melihat bagaimana paket multicast dikembalikan ke nod penghantaran secara lalai dan cara untuk melumpuhkan ini untuk utiliti ping.
Akhirnya, kami ping satu alamat Pautan-Setempat menggunakan akhiran %<zone_id>, memandangkan alamat Link-Local sendiri juga tidak memberikan maklumat tentang antara muka keluar.
Jadi bagaimana pula dengan ping semua nod lain dan dapatkan alamat unicast global (GUA) mereka (iaitu, alamat awam mereka di Internet) atau alamat unicast tempatan mereka yang unik (ULA)? Kita akan lihat perkara ini dalam catatan blog seterusnya.
Itu sahaja.
Anda boleh mengetahui lebih lanjut tentang kursus kami di.
Sumber: www.habr.com