Лічаныя дні застаюцца да старту новага патоку па курсе ад OTUS. У сувязі з гэтым жадаем падзяліцца з вамі перакладам карыснага матэрыялу па тэме.
Серыя артыкулаў у блогу, прысвечаных парадам і рэкамендацыям па ўхіленні непаладак, звязаных з пінгам IPv6 (ICMPv6 Echo Request/Echo Reply)
Звярніце ўвагу, што я выкарыстоўваю Linux (у прыватнасці, Fedora 31), аднак сінтаксіс каманды ping для іншых аперацыйных сістэм, спадзяюся, павінен быць вельмі падобным.
Пінг усіх вузлоў IPv6 на канале
Першая і самая простая рада — прапінгаваць усе вузлы IPv6 на канале.
IPv6 выкарыстоўвае мультыкаст-адрасы для ўсіх тыпаў сувязі "адзін да многіх". Не існуе валацужных (ці шырокавяшчальных) IPv6-адрасоў. Гэта адрознівае IPv6 ад IPv4, дзе існуе некалькі тыпаў валацужных адрасоў, напрыклад, "limited broadcast" адрас 255.255.255.255 [RFC1122].
Аднак існуе “all-nodes multicast” (агульны мультыкаст) IPv6-адрас, таму мы будзем выкарыстоўваць яго для пінгу ўсіх вузлоў IPv6 у канале. («Шырокавяшчальны» адрас насамрэч з'яўляецца проста адмыслова названым мультыакасцным адрасам, які з'яўляецца групай шматадраснага рассылання, улучальнай усе вузлы. Звярніце ўвагу, што, напрыклад, біт «групы» або мультыкастнага адрасу ўключаны ў бродкастных адрасах Ethernet на канальным узроўні).
All-nodes multicast IPv6-адрас для канала: ff02::1. ff абазначае мультыкаставы IPv6-адрас. Наступны 0 - гэта частка сцяга з неўстаноўленымі бітамі.
Далей 2 вызначае вобласць мультыкаставай групы. У адрозненне ад мультыкаст IPv4-адрасоў, мультыкаст IPv6-адрасы маюць scope (вобласць бачнасці). Значэнне scope паказвае частку сеткі, па якой можна перасылаць мультыкасцёвы пакет. Як толькі пакет дасягае мяжы паказанага scope, пакет павінен быць адкінуты, незалежна ад таго, ці з'яўляецца яго поле лічыльніка пераходаў (Hop Count) ненулявое. Вядома, калі лічыльнік пераходаў дасягае за нуль да дасягнення названай мяжы мультыкаставай групы, ён таксама неадкладна скідаецца. Вось поўны спіс мультыкаст scope IPv6.
Нарэшце, ::1 паказвае all-nodes multicast групу.
Аб адрасе ff02::1 трэба заўважыць, што ён неадназначны. На вузле IPv6 з некалькімі інтэрфейсамі, такімі як маршрутызатар ці шматсеткавы хост, у адрасе ff02::1 няма нічога, дзе б можна было паказаць, якому інтэрфейсу адпраўляць рэха-запыты ICMPv6 ці чакаць атрымання рэха-адказаў ICMPv6, калі яны прыходзяць. ff02::1 сапраўдны і можа выкарыстоўвацца на любым з інтэрфейсаў і каналаў, прымацаваных да шматінтэрфейснага вузла.
Таму, калі мы прапінгуем усе вузлы IPv6 на канале, нам трэба неяк таксама паведаміць утыліце ping для IPv6, які інтэрфейс выкарыстоўваць.
Вызначэнне інтэрфейсаў - параметр каманднага радка
Як мы ўжо бачылі, all-nodes multicast адрас, які мы хочам выкарыстоўваць ff02::1 — не дае ніякай інфармацыі адносна таго, на які інтэрфейс адпраўляць і атрымліваць пакеты рэха-запыту і рэха-адказу ICMPv6.
Такім чынам, як нам паказаць інтэрфейс, які будзе выкарыстоўвацца для прасторы мультыкаставых адрасоў або юнікаставых 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 ~]$З дапамогай гэтага all-nodes multicast пінгу мы атрымалі адказы ад 6 IPv6-вузлоў. Адказы паступілі ад вузлавых Link-Local IPv6-адрасоў, пачынаючы з прэфікса fe80::/10.
Каб ping не працягваў бясконца адпраўляць рэха-запыты ICMPv6 датуль, пакуль мы не перапынім яго, мы звычайна паказваем колькасць пакетаў для адпраўкі праз опцыю -c. Аднак гэта таксама не дазваляе ping прыняць і адлюстраваць больш аднаго рэха-адказу ICMPv6 пры адпраўцы мультыкаст рэха-запыту ICMPv6. Замест гэтага мы выкарыстоўвалі параметр -w, каб паказаць, што ping павінен завяршацца праз 1 секунду, незалежна ад таго, колькі рэха-запытаў ці рэха-адказаў ICMPv6 было адпраўлена ці атрымана.
Яшчэ адна рэч, на якую варта звярнуць увагу, гэта (DUP!) вывад на другім і наступных адказах. Гэтыя пакеты ідэнтыфікуюцца як дублікаты адказу, паколькі яны маюць тое ж значэнне паслядоўнасці ICMP, што і асобныя рэха-запыты ICMPv6, якія былі адпраўлены ў першую чаргу. Яны з'яўляюцца, таму што мультыкаст рэха-запыт ICMPv6 прыводзіць да некалькіх індывідуальных юнікаст адказаў. Колькасць дублікатаў таксама ўказваецца ў зводцы статыстыкі.
Вызначэнне інтэрфейсаў – Zone 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". Хоць звычайна яны завуцца інтэрфейсам аперацыйнай сістэмы, яны насамрэч вызначаюць нешта больш агульнае – "зона" ці "вобласць дзеяння".
Чыннік наяўнасці больш агульных зон ці scope зон складаецца ў тым, што, як згадваецца ў [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 ~]$Адказы Link-Local адрасоў
Ад гэтага all-nodes multicast пінгу мы атрымалі ў агульнай складанасці 6 унікальных адказаў.
Гэтыя адказы паступілі ад юнікаст Link-Local адрасоў вузлоў IPv6. Напрыклад, вось першы адказ:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msЮнікаст Link-Local IPv6-адрасы патрабуюцца на ўсіх інтэрфейсах з падтрымкай IPv6 [RFC4291], "Архітэктура адрасацыі IP версіі 6". Чыннік гэтага складаецца ў тым, што вузел IPv6 заўсёды аўтаматычна мае юнікаставы 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 мс у параўнанні з 0,453 мс) паходзіць ад 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. Калі мы адпраўляем пінг all-nodes multicast з гэтым сцягам, то адказы абмяжоўваюцца выдаленымі вузламі. Мы не атрымліваем адказ ад 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!)
...Пінг Link-Local Адрасы
Як вы можаце здагадацца, юнікаставыя Link-Local адрасы самі па сабе таксама не даюць дастаткова інфармацыі, каб паказаць, які інтэрфейс выкарыстоўваць для іх дасягнення. Як і ў выпадку all-nodes multicast пінгу, нам таксама неабходна ўказаць інтэрфейс у якасці параметру каманднага радка ping ці zone 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-вузлы на канале, выкарыстоўваючы all-nodes multicast IPv6-адрас ff02::1. Мы таксама бачылі, як пазначыць, які інтэрфейс выкарыстоўваць з all-nodes multicast IPv6-адрасам, паколькі сам па сабе адрас не можа падаць гэтую інфармацыю. Мы выкарыстоўвалі альбо параметр каманднага радка ping, альбо паказалі інтэрфейс праз суфікс %<zone_id>.
Затым мы даведаліся аб юнікаставых Link-Local адрасах, якія з'яўляюцца адрасамі, выкарыстоўванымі для адказаў на all-nodes multicast рэха-запыты ICMPv6.
Мы таксама бачылі, як мультыкаст пакеты вяртаюцца ў які адпраўляе вузел па змаўчанні і як адключыць гэта для ўтыліты ping.
Нарэшце, мы прапінгавалі адзінкавы Link-Local адрас, выкарыстоўваючы суфікс %<zone_id>, так як Link-Local адрасы самі па сабе таксама не даюць інфармацыю аб выходным інтэрфейсе.
Так як наконт пінгу ўсіх іншых вузлоў і атрымання іх глабальных юнікаст адрасоў (GUA) (гэта значыць іх агульнадаступных адрасоў у Інтэрнэце) або іх унікальных лакальных юнікаст адрасоў (ULA)? Мы разгледзім гэта ў наступным артыкуле блога.
На гэтым усё.
Даведацца падрабязней пра наш курс можна ў.
Крыніца: habr.com