Do zahájení nového toku v rychlosti zbývá několik dní od společnosti OTUS. V tomto ohledu bychom se s vámi rádi podělili o překlad užitečného materiálu na toto téma.
Série blogových příspěvků s tipy a triky pro řešení problémů s pingem IPv6 (ICMPv6 Echo Request/Echo Reply)
Vezměte prosím na vědomí, že používám Linux (konkrétně Fedoru 31), nicméně syntaxe příkazu ping pro ostatní operační systémy by snad měla být velmi podobná.
Otestujte všechny uzly IPv6 na kanálu
Prvním a nejjednodušším tipem je ping na všechny uzly IPv6 na odkazu.
IPv6 používá vícesměrové adresy pro všechny typy komunikace typu one-to-many. Neexistují žádné broadcast (nebo broadcast) adresy IPv6. To odlišuje IPv6 od IPv4, kde existuje několik typů broadcast adres, například adresa „omezeného vysílání“ 255.255.255.255 [RFC1122].
Existuje však adresa IPv6 „vícenásobného vysílání všech uzlů“, takže ji použijeme k pingování všech uzlů IPv6 na odkazu. ("Broadcast" adresa je ve skutečnosti jen speciálně pojmenovaná multicastová adresa, což je multicastová skupina, která zahrnuje všechny uzly. Všimněte si, že například bit "group" nebo multicast adresa je zapnut v ethernetových broadcast adresách na linkové vrstvě. ).
Adresa IPv6 vícesměrového vysílání všech uzlů pro kanál: ff02::1. ff označuje vícesměrovou IPv6 adresu. Další 0 je část příznaku s nenastavenými bity.
Další 2 definuje oblast multicastové skupiny. Na rozdíl od vícesměrových adres IPv4 mají vícesměrové adresy IPv6 rozsah. Hodnota oboru označuje část sítě, přes kterou je povoleno předávání paketů vícesměrového vysílání. Jakmile paket dosáhne hranice zadaného rozsahu, musí být zahozen bez ohledu na to, zda je jeho pole Počet skoků nenulové. Samozřejmě, pokud počet skoků dosáhne nuly před dosažením zadané hranice skupiny vícesměrového vysílání, je také okamžitě resetován. Zde je úplný seznam rozsahu vícesměrového vysílání IPv6.
Konečně, ::1 určuje skupinu vícesměrového vysílání všech uzlů.
O adrese ff02::1 Nutno podotknout, že je nejednoznačný. Na hostiteli IPv6 s více rozhraními, jako je směrovač nebo hostitel s více adresami, adresa ff02::1 není nic, kde byste mohli určit, na které rozhraní se mají odesílat požadavky na echo ICMPv6 nebo očekávat, že při jejich příchodu obdržíte odpovědi na echo ICMPv6. ff02::1 je platný a lze jej použít na kterémkoli z rozhraní a kanálů připojených k uzlu s více rozhraními.
Takže když pingneme všechny IPv6 uzly na odkaz, musíme to nějak také říct obslužnému programu ping pro IPv6, které rozhraní použít.
Definování rozhraní – možnost příkazového řádku
Jak jsme již viděli, adresa vícesměrového vysílání všech uzlů, kterou chceme použít, je − ff02::1 - neposkytuje žádné informace o tom, které rozhraní má odesílat a přijímat ICMPv6 echo request a echo pakety odpovědí.
Jak tedy určíme rozhraní, které se má použít pro vícesměrový adresní prostor nebo unicastový Link-Local adresní prostor?
První a nejzřejmější způsob je poskytnout jej jako parametr aplikaci, kterou používáme.
Pro užitek ping poskytujeme prostřednictvím opce -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 ~]$Pomocí tohoto pingu vícesměrového vysílání všech uzlů jsme obdrželi odpovědi od 6 uzlů IPv6. Odpovědi přicházely z adres uzlů Link-Local IPv6, počínaje předponou fe80::/10.
Že ping nepokračuje v odesílání požadavků ICMPv6 echo do nekonečna, dokud to nepřerušíme, obvykle zadáváme počet paketů k odeslání přes volbu -c. To však také zabrání pingu v přijetí a zobrazení více než jedné ICMPv6 echo odpovědi při odesílání multicast ICMPv6 echo požadavku. Místo toho jsme použili volbu -w k určení, že ping má být dokončen po 1 sekundě, bez ohledu na to, kolik ICMPv6 echo požadavků nebo echo odpovědí bylo odesláno nebo přijato.
Další věc, které je třeba věnovat pozornost, je (DUP!) výstup na druhou a další odpovědi. Tyto pakety jsou identifikovány jako duplicitní odpovědi, protože mají stejnou hodnotu sekvence ICMP jako jednotlivé požadavky echo ICMPv6, které byly odeslány jako první. Objevují se, protože požadavek na echo vícesměrového vysílání ICMPv6 má za následek více individuálních odpovědí unicast. Počet duplikátů je také uveden v přehledu statistik.
Definování rozhraní - ID zóny
Dalším způsobem, jak zpřístupnit rozhraní pro použití, je jako součást parametru adresy IPv6.
Příklad toho můžeme vidět na výstupu pingu, kde adresy odpovídajících hostitelů IPv6 mají také příponu %enp3s2, Například:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msTato metoda specifikování rozhraní je formálně popsána v [RFC4007], "IPv6 Defined Address Architecture." Ačkoli se obvykle nazývají rozhraním operačního systému, ve skutečnosti definují něco obecnějšího – „zónu“ nebo „rozsah“.
Důvodem pro obecnější zóny nebo zóny rozsahu je to, jak je uvedeno v [RFC4007], uzel IPv6 může mít několik různých rozhraní IPv6 připojených ke stejnému kanálu. Tato rozhraní jsou členy stejné zóny.
Mělo by být možné seskupit více rozhraní v rámci zóny pod operačním systémem; Momentálně nevím, jestli je to možné pod Linuxem nebo jak to udělat.
Použití přípony %<zone_id>, můžeme odebrat volbu příkazového řádku -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 Address Response
Z tohoto multicastového pingu všech uzlů jsme obdrželi celkem 6 jedinečných odpovědí.
Tyto odpovědi pocházely z adres hostitelů IPv6 unicast Link-Local. Zde je například první odpověď:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msAdresy Unicast Link-Local IPv6 jsou vyžadovány na všech rozhraních podporujících IPv6 [RFC4291], “IP verze 6 Addressing Architecture”. Důvodem je, že uzel IPv6 má vždy automaticky unicastovou adresu IPv6, kterou může alespoň použít ke komunikaci s ostatními uzly na svých přímo připojených linkách. To zahrnuje komunikaci s aplikacemi na jiných hostitelích prostřednictvím adres hostitelů Link-Local.
To zjednodušuje návrh a implementaci protokolů, jako je IPv6 Neighbor Discovery a OSPFv3. Umožňuje také aplikacím koncových uživatelů na hostitelích komunikovat přes kanál, aniž by na kanálu vyžadovaly další podpůrnou infrastrukturu IPv6. Přímá komunikace mezi připojenými hostiteli IPv6 nevyžaduje na připojení router IPv6 ani server DHCPv6.
Adresy Link-Local začínají 10bitovou předponou fe80následuje 54 nulových bitů a poté 64bitový identifikátor rozhraní (IID). Ve výše uvedené první odpovědi 2392:6213:a15b:66ff je 64bitové IID.
Vícesměrové vysílání ve smyčce
Ve výchozím nastavení se pakety vícesměrového vysílání vracejí interně do uzlu, který je odeslal. To se děje u adresování IPv6 i IPv4.
Důvodem tohoto výchozího chování je, že při odesílání paketů vícesměrového vysílání může být na odesílajícím hostiteli i někde v síti spuštěna naslouchající místní aplikace vícesměrového vysílání. Tato místní aplikace musí také přijímat pakety vícesměrového vysílání.
Tuto místní smyčku vícesměrového vysílání můžeme vidět v našem výstupu 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!)
...První a nejrychlejší odezva (0,106 ms oproti 0,453 ms) pochází z adresy Link-Local nakonfigurované na samotném rozhraní. enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Užitečnost ping poskytuje způsob, jak potlačit místní multicast zpětnou vazbu pomocí parametru -L. Pokud s tímto příznakem odešleme multicastový ping všech uzlů, pak jsou odpovědi omezeny na vzdálené uzly. Z adresy Link-Local odesílajícího rozhraní neobdržíme odpověď.
[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-Local Addresses
Jak asi tušíte, unicastové adresy Link-Local samy o sobě také neposkytují dostatek informací k tomu, aby naznačovaly, jaké rozhraní k nim použít. Stejně jako u pingu vícesměrového vysílání všech uzlů musíme také zadat rozhraní jako parametr příkazového řádku ping nebo ID zóny s adresou při ping na adresy Link-Local.
Tentokrát můžeme využít -comezit počet odeslaných a přijatých paketů a odpovědí ping, protože provádíme unicastový 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 ~]$Pingovat (všechny) další adresy IPv6?
V tomto článku jsme viděli, jak pingnout všechny uzly IPv6 na kanálu pomocí vícesměrové adresy IPv6 všech uzlů ff02::1. Také jsme viděli, jak určit, které rozhraní se má použít s adresou IPv6 pro vícesměrové vysílání všech uzlů, protože samotná adresa tyto informace poskytnout nemůže. Použili jsme buď možnost příkazového řádku ping, nebo specifikovat rozhraní pomocí přípony %<zone_id>.
Poté jsme se dozvěděli o adresách unicast Link-Local, což jsou adresy používané k odpovědi na požadavky multicast ICMPv6 echo všech uzlů.
Viděli jsme také, jak se ve výchozím nastavení vracejí pakety vícesměrového vysílání do odesílajícího uzlu a jak to nástroji zakázat ping.
Nakonec jsme pomocí přípony provedli příkaz ping na jednu adresu Link-Local %<zone_id>, protože adresy Link-Local samy o sobě také neposkytují informace o odchozím rozhraní.
Co tedy pingnout všechny ostatní uzly a získat jejich globální unicastové adresy (GUA) (tj. jejich veřejné adresy na internetu) nebo jejich jedinečné lokální unicastové adresy (ULA)? Na to se podíváme v příštím příspěvku na blogu.
To je všechno.
Více o našem kurzu se můžete dozvědět na.
Zdroj: www.habr.com