Пинг на сите IPv6 јазли на каналот

Остануваат неколку дена до почетокот на нов проток по стапка „Мрежен инженер“ од ОТУС. Во овој поглед, би сакале да споделиме со вас превод на корисен материјал на темата.

Серија блог постови за совети и трикови за решавање проблеми со пинг IPv6 (ICMPv6 Echo Request/Echo Reply)

Ве молиме имајте предвид дека користам Linux (конкретно Fedora 31), но синтаксата на командата пинг за другите оперативни системи се надеваме дека треба да биде многу слична.

Пинг на сите IPv6 јазли на каналот

Првиот и наједноставен совет е да ги пингирате сите IPv6 јазли на врската.

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

Како и да е, постои IPv6 адреса за „all-nodes multicast“, така што ќе ја користиме за да ги пингираме сите IPv6 јазли на врската. (Адресата „емитувана“ е всушност само специјално именувана повеќекратна адреса, која е мултикаст група која ги вклучува сите јазли. Имајте предвид дека, на пример, битот за „група“ или повеќекратна адреса е вклучен во адресите за емитување на етернет на слојот за врска ).

Повеќекратна IPv6 адреса на сите јазли за каналот: ff02::1. ff означува повеќекратна IPv6 адреса. Следната 0 е дел од знамето со непоставени битови.

Понатаму 2 ја дефинира областа на мултикаст група. За разлика од повеќекратните IPv4 адреси, повеќекратните IPv6 адреси имаат опсег. Вредноста на опсегот го означува делот од мрежата преку кој е дозволено да се препраќа мултикаст пакет. Штом пакетот ќе ја достигне границата на наведениот опсег, пакетот мора да се исфрли, без разлика дали неговото поле за Hop Count е ненула. Се разбира, ако бројот на скокови достигне нула пред да се достигне одредената граница на мултикаст група, исто така веднаш се ресетира. Еве комплетна листа на IPv6 multicast опсег.

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

За адресата ff02::1 Треба да се напомене дека е двосмислена. На IPv6-домаќин со повеќе интерфејси, како што е рутер или домаќин со повеќе домови, адресата ff02::1 нема ништо каде што можете да одредите до кој интерфејс да испраќате барања за ехо ICMPv6 или да очекувате да добивате одговори за ехо на ICMPv6 кога ќе пристигнат. ff02::1 е валиден и може да се користи на кој било од интерфејсите и каналите прикачени на јазолот со повеќе интерфејси.

Значи, кога ги пингираме сите IPv6 јазли на врската, треба некако да ја кажеме и алатката ping за IPv6, кој интерфејс да се користи.

Дефинирање на интерфејси - Опција за командна линија

Како што веќе видовме, мултикаст адресата на сите јазли што сакаме да ја користиме е - ff02::1 - не дава никакви информации во врска со кој интерфејс да испраќа и прима ICMPv6 ехо барање и пакети за ехо одговор.

Значи, како да го одредиме интерфејсот што ќе се користи за мултикаст адресниот простор или 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 ~]$

Користејќи го овој мултикаст пинг за сите јазли, добивме одговори од 6 IPv6 јазли. Одговорите дојдоа од адресите на јазлите Link-Local IPv6, почнувајќи со префиксот fe80::/10.

Дека ping не продолжува да испраќа барања за ехо ICMPv6 на неодредено време додека не го прекинеме, обично го одредуваме бројот на пакети што треба да се испратат преку опцијата -c. Сепак, ова исто така го спречува пингот да прифати и прикаже повеќе од еден ICMPv6 ехо одговор при испраќање мултикаст ICMPv6 ехо барање. Наместо тоа, ја користевме опцијата -w за да одредиме дека пингот треба да заврши по 1 секунда, без разлика колку ICMPv6 ехо барања или ехо одговори се испратени или примени.

Друга работа на која треба да се обрне внимание е (DUP!) излез на вториот и следните одговори. Овие пакети се идентификувани како дупликат одговори бидејќи ја имаат истата вредност на секвенцата на ICMP како и поединечните барања за ехо ICMPv6 што беа испратени на прво место. Тие се појавуваат затоа што барањето за повеќекратно емитување ехо ICMPv6 резултира со повеќе индивидуални уникаст одговори. Бројот на дупликати е наведен и во резимето на статистиката.

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

Друг начин за изложување на интерфејс за употреба е како дел од параметарот за адреса IPv6.

Можеме да видиме пример за ова во излезот на пинг, каде што адресите на одговорните IPv6 домаќини исто така имаат наставка %enp3s2, на пример:

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

Овој метод на спецификација на интерфејси е формално опишан во [RFC4007], „IPv6 Defined Address Architecture“. Иако тие обично се нарекуваат интерфејс на оперативниот систем, тие всушност дефинираат нешто поопшто - „зона“ или „обем“.

Причината за постоењето на поопшти зони или зони на опфат е тоа што, како што е споменато во [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 верзија 6“. Причината за ова е што јазолот IPv6 секогаш автоматски има уникаст IPv6 адреса, која барем може да ја користи за да комуницира со други јазли на неговите директно поврзани врски. Ова вклучува комуникација со апликации на други хостови преку Link-Local адреси на домаќини.

Ова го поедноставува дизајнот и имплементацијата на протоколи како што се IPv6 Neighbor Discovery и OSPFv3. Исто така, им овозможува на апликациите на крајните корисници на хостовите да комуницираат преку каналот без да бараат друга инфраструктура за поддршка на IPv6 на каналот. Директната комуникација помеѓу поврзаните IPv6 домаќини не бара IPv6 рутер или DHCPv6 сервер на врската.

Линк-Локалните адреси започнуваат со 10-битен префикс fe80, проследено со 54 нула бита и потоа 64-битен идентификатор на интерфејс (IID). Во горниот прв одговор 2392:6213:a15b:66ff е 64-битен IID.

Looped Multicast

Стандардно, multicast пакетите се враќаат внатрешно во јазолот што ги испратил. Ова се случува и за IPv6 и за IPv4 адресирање.

Причината за ова стандардно однесување е тоа што кога се испраќаат мултикаст пакети, може да има и локална апликација за слушање мултикаст што работи на самиот домаќин што испраќа, како и некаде на мрежата. Оваа локална апликација мора да прима и мултикаст пакети.

Можеме да ја видиме оваа multicast локална јамка во нашиот излез за пинг:

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

Пинг врска-локални адреси

Како што може да претпоставите, 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 ~]$

Пинг (сите) други 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