Пинг на всички IPv6 възли на канал

Остават няколко дни до началото на нов поток по темп "Системен инженер" от OTUS. В тази връзка бихме искали да споделим с вас превод на полезен материал по темата.

Поредица от публикации в блогове относно съвети и трикове за отстраняване на проблеми с IPv6 ping (ICMPv6 Echo Request/Echo Reply)

Моля, имайте предвид, че използвам Linux (по-специално Fedora 31), но се надяваме, че синтаксисът на командата ping за други операционни системи трябва да е много подобен.

Пинг на всички IPv6 възли на канал

Първият и най-прост съвет е да пингвате всички IPv6 възли на връзката.

IPv6 използва мултикаст адреси за всички видове комуникации един към много. Няма излъчвани (или излъчвани) IPv6 адреси. Това отличава IPv6 от IPv4, където има няколко вида адреси за излъчване, например адресът за „ограничено излъчване“ 255.255.255.255 [RFC1122].

Въпреки това има IPv6 адрес за „мултикаст на всички възли“, така че ще го използваме, за да пингваме всички IPv6 възли на връзката. (Адресът за „излъчване“ всъщност е само специално наименуван адрес за множествено предаване, който е група за множествено предаване, която включва всички възли. Обърнете внимание, че например битът за „група“ или адрес за множествено предаване е включен в Ethernet адресите за излъчване на слоя за връзка ).

IPv6 адрес за мултикаст на всички възли за канала: ff02::1. ff обозначава мултикаст IPv6 адрес. Следващата 0 е частта от флага с ненастроени битове.

Още 2 дефинира зоната на мултикаст група. За разлика от мултикаст IPv4 адресите, мултикаст IPv6 адресите имат обхват. Стойността на обхвата показва частта от мрежата, през която е разрешено препращането на мултикаст пакет. След като пакетът достигне границата на посочения обхват, пакетът трябва да бъде премахнат, независимо дали полето му за брой скокове е различно от нула. Разбира се, ако броят на скоковете достигне нула, преди да достигне определената граница на групата за множествено предаване, той също се нулира незабавно. Ето пълен списък на IPv6 мултикаст обхват.

И накрая, ::1 определя мултикаст група с всички възли.

Относно адреса ff02::1 Трябва да се отбележи, че е двусмислено. На IPv6 хост с множество интерфейси, като рутер или многодомов хост, адресът ff02::1 няма нищо, където можете да посочите към кой интерфейс да изпращате ICMPv6 ехо заявки или да очаквате да получавате ICMPv6 ехо отговори, когато пристигнат. ff02::1 е валиден и може да се използва на всеки от интерфейсите и каналите, прикрепени към мултиинтерфейсния възел.

Така че, когато пингваме всички IPv6 възли на връзка, трябва по някакъв начин също да кажем на помощната програма ping за IPv6, кой интерфейс да използвате.

Дефиниране на интерфейси - опция за команден ред

Както вече видяхме, мултикаст адресът за всички възли, който искаме да използваме, е − ff02::1 - не предоставя никаква информация относно това кой интерфейс да изпраща и получава ICMPv6 ехо заявка и ехо отговор пакети.

И така, как да посочим интерфейса, който да се използва за адресното пространство за множествено предаване или локално адресно пространство за едноадресна връзка?

Първият и най-очевиден начин е да го предоставим като параметър на приложението, което използваме.

За полезност 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 ~]$

Използвайки този мултикаст пинг за всички възли, получихме отговор от 6 IPv6 възела. Отговорите идват от Link-Local IPv6 адреси на възли, започвайки с префикса fe80::/10.

Че ping не продължава да изпраща ICMPv6 ехо заявки за неопределено време, докато не го прекъснем, обикновено определяме броя на пакетите за изпращане чрез опцията -c. Това обаче не позволява на ping да приеме и покаже повече от един ICMPv6 ехо отговор при изпращане на мултикаст ICMPv6 ехо заявка. Вместо това използвахме опцията -w, за да посочим, че ping трябва да завърши след 1 секунда, без значение колко ICMPv6 ехо заявки или ехо отговори са изпратени или получени.

Друго нещо, на което трябва да обърнете внимание е (DUP!) изведете на втория и следващите отговори. Тези пакети се идентифицират като дублирани отговори, защото имат същата стойност на ICMP последователност като отделните ICMPv6 ехо заявки, които са били изпратени на първо място. Те се появяват, защото ICMPv6 мултикаст ехо заявка води до множество индивидуални едноадресни отговори. Броят на дубликатите също е посочен в обобщената статистика.

Дефиниране на интерфейси - ID на зона

Друг начин за излагане на интерфейс за използване е като част от параметър на IPv6 адрес.

Можем да видим пример за това в изхода на ping, където адресите на отговарящите 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 уникални отговора.

Тези отговори идват от едноадресни IPv6 хост адреси на Link-Local. Ето например първият отговор:

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 версия 6“. Причината за това е, че един 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-битов IID.

Looped Multicast

По подразбиране мултикаст пакетите се връщат вътрешно към възела, който ги е изпратил. Това се случва както за IPv6, така и за IPv4 адресиране.

Причината за това поведение по подразбиране е, че когато се изпращат мултикаст пакети, може също да има слушащо локално мултикаст приложение, работещо на самия изпращащ хост, както и някъде в мрежата. Това локално приложение трябва също да получава мултикаст пакети.

Можем да видим този мултикаст локален цикъл в нашия 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!)
...

Първият и най-бърз отговор (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 или идентификатор на зона с адрес, когато пингвате Link-Local адреси.

Този път можем да използваме -cза ограничаване на броя на изпратените и получените пакети и отговори ping, тъй като извършваме unicast 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 ехо заявки за всички възли.

Видяхме също как мултикаст пакетите се връщат към изпращащия възел по подразбиране и как да деактивираме това за помощната програма ping.

И накрая, ние пингвахме единичен адрес на Link-Local, използвайки суфикса %<zone_id>, тъй като самите Link-Local адреси също не предоставят информация за изходящия интерфейс.

И така, какво да кажем за ping на всички останали възли и да получите техните глобални едноадресни адреси (GUA) (т.е. техните публични адреси в Интернет) или техните уникални локални едноадресни адреси (ULA)? Ще разгледаме това в следващата публикация в блога.

Това е всичко.

Можете да научите повече за нашия курс на бележки за деня на отворените врати.

Източник: www.habr.com