Ping ყველა IPv6 კვანძის არხზე

რამდენიმე დღე რჩება ახალი ნაკადის დაწყებამდე კურსით "ქსელის ინჟინერი" OTUS-დან. ამასთან დაკავშირებით, გვინდა გაგიზიაროთ ამ თემაზე სასარგებლო მასალის თარგმანი.

ბლოგის პოსტების სერია IPv6 პინგ საკითხების გადაჭრის რჩევებსა და ხრიკებზე (ICMPv6 Echo Request/Echo Reply)

გთხოვთ გაითვალისწინოთ, რომ მე ვიყენებ Linux (კონკრეტულად Fedora 31), თუმცა სხვა ოპერაციული სისტემებისთვის ping ბრძანების სინტაქსი, იმედია, ძალიან მსგავსი უნდა იყოს.

Ping ყველა IPv6 კვანძის არხზე

პირველი და უმარტივესი რჩევაა ლინკზე ყველა IPv6 კვანძის პინგირება.

IPv6 იყენებს მულტიკასტის მისამართებს ყველა ტიპის ერთიდან რამდენიმე კომუნიკაციისთვის. არ არის სამაუწყებლო (ან სამაუწყებლო) IPv6 მისამართები. ეს განასხვავებს IPv6-ს IPv4-ისგან, სადაც არის რამდენიმე ტიპის სამაუწყებლო მისამართები, მაგალითად, „შეზღუდული მაუწყებლობის“ მისამართი 255.255.255.255 [RFC1122].

თუმცა, არსებობს IPv6 „ყველა კვანძის მულტიკასტის“ მისამართი, ამიტომ ჩვენ მას გამოვიყენებთ ბმულზე ყველა IPv6 კვანძის პინგისთვის. ("მაუწყებლობის" მისამართი რეალურად არის მხოლოდ სპეციალურად დასახელებული მულტიcast მისამართი, რომელიც წარმოადგენს მულტიკასტის ჯგუფს, რომელიც მოიცავს ყველა კვანძს. გაითვალისწინეთ, რომ, მაგალითად, "ჯგუფური" ან მულტიმაუწყებლობის მისამართის ბიტი ჩართულია Ethernet სამაუწყებლო მისამართებში ბმულის შრეზე. ).

ყველა კვანძის მულტიკასტული IPv6 მისამართი არხისთვის: ff02::1. ff აღნიშნავს მულტიკასტის IPv6 მისამართს. შემდეგი 0 არის დროშის ნაწილი დაუყენებელი ბიტებით.

შემდგომი 2 განსაზღვრავს მულტიკასტული ჯგუფის არეალს. Multicast IPv4 მისამართებისგან განსხვავებით, Multicast IPv6 მისამართებს აქვთ ფარგლები. მასშტაბის მნიშვნელობა მიუთითებს ქსელის იმ ნაწილზე, რომელზედაც ნებადართულია მულტიკასტის პაკეტის გადაგზავნა. მას შემდეგ, რაც პაკეტი მიაღწევს განსაზღვრული არეალის საზღვრებს, პაკეტი უნდა ჩამოიშალოს, მიუხედავად იმისა, არის თუ არა მისი Hop Count ველი ნულოვანი. რა თქმა უნდა, თუ ჰოპის რაოდენობა მიაღწევს ნულს მითითებულ მულტიკასტის ჯგუფის საზღვრამდე მიღწევამდე, ის ასევე დაუყოვნებლივ აღდგება. აქ არის IPv6 მულტიკასტის არეალის სრული სია.

და ბოლოს, ::1 განსაზღვრავს ყველა კვანძის მულტიკასტის ჯგუფს.

მისამართის შესახებ ff02::1 უნდა აღინიშნოს, რომ ის ორაზროვანია. IPv6 ჰოსტზე მრავალი ინტერფეისით, როგორიცაა როუტერი ან მრავალსახლიანი ჰოსტი, მისამართი ff02::1 არაფერია, სადაც შეგიძლიათ მიუთითოთ რომელ ინტერფეისს გაუგზავნოთ ICMPv6 ექო მოთხოვნები ან ელოდოთ ICMPv6 ექო პასუხების მიღებას, როდესაც ისინი ჩამოდიან. ff02::1 მოქმედებს და შეიძლება გამოყენებულ იქნას მრავალ ინტერფეისის კვანძზე მიმაგრებულ ნებისმიერ ინტერფეისსა და არხზე.

ასე რომ, როდესაც ჩვენ ყველა IPv6 კვანძს ლინკზე ვაგზავნით, ჩვენ უნდა როგორმე ვუთხრათ ასევე კომუნალურ პროგრამას ping IPv6-ისთვის, რომელი ინტერფეისი გამოიყენოს.

ინტერფეისების განსაზღვრა - ბრძანების ხაზის ვარიანტი

როგორც უკვე ვნახეთ, ყველა კვანძის მულტიკასტის მისამართი, რომლის გამოყენებაც გვინდა არის - ff02::1 - არ გვაწვდის ინფორმაციას იმის შესახებ, თუ რომელი ინტერფეისის გაგზავნა და მიღება უნდა მოხდეს ICMPv6 echo მოთხოვნისა და ექო პასუხის პაკეტების შესახებ.

მაშ, როგორ განვსაზღვროთ ინტერფეისი, რომელიც გამოყენებული იქნება მულტიკასტის მისამართების სივრცისთვის ან unicast Link-Local მისამართის სივრცისთვის?

პირველი და ყველაზე აშკარა გზა არის მისი მიწოდება, როგორც პარამეტრი იმ აპლიკაციისთვის, რომელსაც ჩვენ ვიყენებთ.

სარგებლობისთვის ping ჩვენ ვაძლევთ მას ოფციონის საშუალებით -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 ~]$

ამ ყველა კვანძის მულტიcast პინგის გამოყენებით, ჩვენ მივიღეთ პასუხები 6 IPv6 კვანძიდან. პასუხები მოვიდა Link-Local IPv6 კვანძის მისამართებიდან, დაწყებული პრეფიქსით fe80::/10.

რომ ping არ აგრძელებს ICMPv6 echo მოთხოვნის გაგზავნას განუსაზღვრელი ვადით, სანამ არ შეწყვეტთ მას, ჩვენ ჩვეულებრივ ვაზუსტებთ პაკეტების რაოდენობას გასაგზავნად -c ოფციის საშუალებით. თუმცა, ეს ასევე ხელს უშლის პინგს მიიღოს და აჩვენოს ერთზე მეტი ICMPv6 ექო პასუხი, როდესაც აგზავნით ICMPv6 ექოზე მრავალჯერადი მოთხოვნის გაგზავნას. ამის ნაცვლად, ჩვენ გამოვიყენეთ -w ოფცია იმის დასაზუსტებლად, რომ ping უნდა დასრულდეს 1 წამის შემდეგ, არ აქვს მნიშვნელობა რამდენი ICMPv6 ექო მოთხოვნა ან ექო პასუხი იყო გაგზავნილი ან მიღებული.

კიდევ ერთი რამ, რასაც ყურადღება უნდა მიაქციოთ არის (DUP!) გამოტანა მეორე და შემდგომ პასუხებზე. ეს პაკეტები იდენტიფიცირებულია, როგორც დუბლიკატი პასუხები, რადგან მათ აქვთ იგივე ICMP თანმიმდევრული მნიშვნელობა, როგორც ინდივიდუალური ICMPv6 ექო მოთხოვნები, რომლებიც პირველად იქნა გაგზავნილი. ისინი ჩნდება იმის გამო, რომ ICMPv6 multicast echo მოთხოვნა იწვევს მრავალ ინდივიდუალურ unicast პასუხს. სტატისტიკურ რეზიუმეში ასევე მითითებულია დუბლიკატების რაოდენობა.

ინტერფეისების განსაზღვრა - ზონის ID

ინტერფეისის გამოსაყენებლად გამოვლენის კიდევ ერთი გზა არის IPv6 მისამართის პარამეტრის ნაწილი.

ამის მაგალითს ვხედავთ პინგ გამომავალში, სადაც პასუხი IPv6 ჰოსტების მისამართებს ასევე აქვთ სუფიქსი. %enp3s2, მაგალითად:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

ინტერფეისების დაზუსტების ეს მეთოდი ოფიციალურად არის აღწერილი [RFC4007]-ში, „IPv6 განსაზღვრული მისამართის არქიტექტურა“. მიუხედავად იმისა, რომ მათ ჩვეულებრივ უწოდებენ ოპერაციული სისტემის ინტერფეისს, ისინი რეალურად განსაზღვრავენ რაღაც უფრო ზოგადს - "ზონას" ან "ფარგლებს".

უფრო ზოგადი ზონების ან მოცულობის ზონების არსებობის მიზეზი არის ის, რომ, როგორც აღნიშნულია [RFC4007]-ში, IPv6 კვანძს შეიძლება ჰქონდეს რამდენიმე განსხვავებული IPv6 ინტერფეისი დაკავშირებული იმავე არხთან. ეს ინტერფეისები ერთი და იგივე ზონის წევრები არიან.

შესაძლებელი უნდა იყოს მრავალი ინტერფეისის დაჯგუფება ოპერაციული სისტემის ქვეშ არსებულ ზონაში; ამჟამად არ ვიცი, შესაძლებელია თუ არა ეს Linux-ში ან როგორ გავაკეთო ეს.

სუფიქსის გამოყენება %<zone_id>, ჩვენ შეგვიძლია წავშალოთ ბრძანების ხაზის ვარიანტი -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 ~]$

ბმული-ლოკალური მისამართის პასუხები

ამ ყველა კვანძის მრავალჯერადი პინგიდან მივიღეთ სულ 6 უნიკალური პასუხი.

ეს პასუხები მოვიდა unicast Link-Local IPv6 ჰოსტის მისამართებიდან. მაგალითად, აქ არის პირველი პასუხი:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

Unicast Link-Local IPv6 მისამართები საჭიროა ყველა IPv6 ჩართული ინტერფეისზე [RFC4291], „IP Version 6 Addressing Architecture“. ამის მიზეზი ის არის, რომ IPv6 კვანძს ყოველთვის ავტომატურად აქვს unicast IPv6 მისამართი, რომელიც მას მინიმუმ შეუძლია გამოიყენოს სხვა კვანძებთან კომუნიკაციისთვის პირდაპირ დაკავშირებულ ბმულებზე. ეს მოიცავს აპლიკაციებთან კომუნიკაციას სხვა ჰოსტებზე Link-Local ჰოსტის მისამართების მეშვეობით.

ეს ამარტივებს პროტოკოლების დიზაინსა და განხორციელებას, როგორიცაა IPv6 Neighbor Discovery და OSPFv3. ის ასევე საშუალებას აძლევს საბოლოო მომხმარებლის აპლიკაციებს ჰოსტებზე, დაუკავშირდნენ არხს არხზე რაიმე სხვა დამხმარე IPv6 ინფრასტრუქტურის მოთხოვნის გარეშე. დაკავშირებულ IPv6 ჰოსტებს შორის პირდაპირი კომუნიკაცია არ საჭიროებს IPv6 როუტერს ან DHCPv6 სერვერს კავშირზე.

Link-Local მისამართები იწყება 10-ბიტიანი პრეფიქსით fe80, რასაც მოჰყვება 54 ნულოვანი ბიტი და შემდეგ 64-ბიტიანი ინტერფეისის იდენტიფიკატორი (IID). ზემოთ მოყვანილ პირველ პასუხში 2392:6213:a15b:66ff არის 64-ბიტიანი ID.

Looped Multicast

ნაგულისხმევად, Multicast პაკეტები იძულებით უბრუნდება კვანძს, რომელმაც ისინი გაგზავნა. ეს ხდება როგორც IPv6, ასევე IPv4 მისამართისთვის.

ამ ნაგულისხმევი ქცევის მიზეზი არის ის, რომ როდესაც Multicast პაკეტები იგზავნება, შეიძლება ასევე იყოს მოსასმენი ლოკალური multicast პროგრამა, რომელიც გაშვებულია თავად გაგზავნის ჰოსტზე, ისევე როგორც სადმე ქსელში. ამ ლოკალურმა აპლიკაციამ ასევე უნდა მიიღოს მულტიcast პაკეტები.

ჩვენ შეგვიძლია დავინახოთ ეს მრავალჯერადი ლოკალური მარყუჟი ჩვენს პინგ გამომავალში:

[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!)
...

პირველი და ყველაზე სწრაფი პასუხი (0,106 ms 0,453 ms-თან შედარებით) მოდის Link-Local მისამართიდან, რომელიც კონფიგურირებულია თავად ინტერფეისზე. enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

კომუნალური ping უზრუნველყოფს პარამეტრის გამოყენებით ადგილობრივი მულტიკასტის გამოხმაურების ჩახშობის საშუალებას -L. თუ ამ დროშით გავაგზავნით ყველა კვანძის მულტიკასტის პინგს, მაშინ პასუხები შემოიფარგლება დისტანციური კვანძებით. ჩვენ არ ვიღებთ პასუხს გაგზავნის ინტერფეისის Link-Local მისამართიდან.

[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-ლოკალური მისამართები

როგორც თქვენ ალბათ მიხვდებით, unicast Link-Local მისამართები თავისთავად ასევე არ გვაწვდიან საკმარის ინფორმაციას იმის მითითებისთვის, თუ რომელი ინტერფეისი გამოიყენოს მათთან მისასვლელად. როგორც ყველა კვანძის მულტიკასტის პინგის შემთხვევაში, ჩვენ ასევე გვჭირდება ინტერფეისის მითითება, როგორც ბრძანების ხაზის პარამეტრი ping ან ზონის ID მისამართით Link-Local მისამართების პინგის დროს.

ამჯერად შეგვიძლია გამოვიყენოთ -cშეზღუდოს გაგზავნილი და მიღებული პაკეტებისა და პასუხების რაოდენობა ping, ვინაიდან ჩვენ ვასრულებთ უნიკასტის პინგს.

[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 (ყველა) სხვა IPv6 მისამართი?

ამ სტატიაში ჩვენ ვნახეთ, თუ როგორ უნდა ჩაწეროთ ყველა IPv6 კვანძი არხზე ყველა კვანძის მულტიკასტური IPv6 მისამართის გამოყენებით. ff02::1. ჩვენ ასევე ვნახეთ, თუ როგორ უნდა განვსაზღვროთ რომელი ინტერფეისი გამოვიყენოთ ყველა კვანძის მულტიკასტური IPv6 მისამართით, რადგან თავად მისამართი ვერ უზრუნველყოფს ამ ინფორმაციას. ჩვენ გამოვიყენეთ ბრძანების ხაზის ვარიანტი ping, ან მიუთითეთ ინტერფეისი სუფიქსის გამოყენებით %<zone_id>.

შემდეგ ჩვენ გავიგეთ unicast Link-Local მისამართების შესახებ, რომლებიც არის მისამართები, რომლებიც გამოიყენება ყველა კვანძის მულტიკასტის ICMPv6 echo მოთხოვნებზე პასუხის გასაცემად.

ჩვენ ასევე ვნახეთ, თუ როგორ უბრუნდება მრავალჯერადი პაკეტები გაგზავნის კვანძს ნაგულისხმევად და როგორ გამორთოთ ეს კომუნალური პროგრამისთვის ping.

საბოლოოდ, ჩვენ შევასრულეთ ერთი Link-Local მისამართი სუფიქსის გამოყენებით %<zone_id>, ვინაიდან თავად Link-Local მისამართები ასევე არ გვაწვდიან ინფორმაციას გამავალი ინტერფეისის შესახებ.

რა შეიძლება ითქვას ყველა სხვა კვანძზე პინგზე და მიიღეთ მათი გლობალური unicast მისამართები (GUAs) (ანუ მათი საჯარო მისამართები ინტერნეტში) ან მათი უნიკალური ადგილობრივი unicast მისამართები (ULAs)? ამას განვიხილავთ ბლოგის შემდეგ პოსტში.

ეს ყველაფერი.

შეგიძლიათ გაიგოთ მეტი ჩვენი კურსის შესახებ აქ ღია დღის შენიშვნები.

წყარო: www.habr.com