Quedan uns días para o inicio dun novo fluxo ao ritmo de OTUS. Neste sentido, queremos compartir con vós unha tradución de material útil sobre o tema.
Unha serie de publicacións de blog sobre consellos e trucos para solucionar problemas de ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Teña en conta que estou usando Linux (específicamente Fedora 31), pero a sintaxe do comando ping para outros sistemas operativos debería ser moi semellante.
Fai ping a todos os nodos IPv6 dunha canle
O primeiro e máis sinxelo consello é facer ping a todos os nodos IPv6 da ligazón.
IPv6 usa enderezos de multidifusión para todo tipo de comunicacións un a varios. Non hai enderezos IPv6 de emisión (ou de difusión). Isto distingue IPv6 de IPv4, onde hai varios tipos de enderezos de difusión, por exemplo, o enderezo de "difusión limitada" 255.255.255.255 [RFC1122].
Non obstante, hai un enderezo IPv6 de "multidifusión de todos os nodos", polo que o usaremos para facer ping a todos os nodos IPv6 da ligazón. (Un enderezo de "difusión" é en realidade só un enderezo de multidifusión especialmente nomeado, que é un grupo de multidifusión que inclúe todos os nodos. Teña en conta que, por exemplo, o bit de enderezo "grupo" ou multidifusión está activado nos enderezos de difusión Ethernet na capa de enlace. ).
Enderezo IPv6 multicast de todos os nodos para a canle: ff02::1. ff indica un enderezo IPv6 multicast. O seguinte 0 é a parte da bandeira con bits sen establecer.
Máis 2 define a área dun grupo de multidifusión. A diferenza dos enderezos IPv4 multicast, os enderezos IPv6 multicast teñen un alcance. O valor de ámbito indica a parte da rede pola que se permite reenviar un paquete de multidifusión. Unha vez que un paquete alcanza o límite do ámbito especificado, o paquete debe ser eliminado, independentemente de que o seu campo Conta de saltos sexa distinto de cero. Por suposto, se o reconto de saltos chega a cero antes de alcanzar o límite especificado do grupo de multidifusión, tamén se restablece inmediatamente. Aquí tes unha lista completa do ámbito de multidifusión IPv6.
Finalmente ::1 especifica un grupo de multidifusión de todos os nodos.
Sobre o enderezo ff02::1 Hai que ter en conta que é ambiguo. Nun host IPv6 con varias interfaces, como un router ou un host multihomed, o enderezo ff02::1 non hai nada onde poidas especificar a que interface enviar solicitudes de eco ICMPv6 ou esperar recibir respostas de eco ICMPv6 cando cheguen. ff02::1 é válido e pódese usar en calquera das interfaces e canles conectados ao nodo de interfaces múltiples.
Entón, cando facemos ping a todos os nodos IPv6 nunha ligazón, necesitamos dicirlle dalgunha maneira tamén á utilidade ping para IPv6, que interface usar.
Definición de interfaces - Opción de liña de comandos
Como xa vimos, o enderezo de multidifusión de todos os nodos que queremos usar é - ff02::1 - non proporciona ningunha información sobre a interface para enviar e recibir paquetes de solicitude de eco e resposta de eco ICMPv6.
Entón, como especificamos a interface que se utilizará para o espazo de enderezos multicast ou unicast Link-Local?
A primeira e máis obvia forma é proporcionalo como parámetro á aplicación que estamos a usar.
Por utilidade ping proporcionámolo a través da opción -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 ~]$Usando este ping multicast de todos os nodos, recibimos respostas de 6 nodos IPv6. As respostas proviñan de enderezos de nodos IPv6 de Link-Local, comezando polo prefixo fe80::/10.
Que ping non segue enviando solicitudes de eco ICMPv6 indefinidamente ata que a interrompamos, normalmente especificamos o número de paquetes a enviar mediante a opción -c. Non obstante, isto tamén impide que ping acepte e amose máis dunha resposta de eco ICMPv6 ao enviar unha solicitude de eco ICMPv6 multidifusión. Pola contra, usamos a opción -w para especificar que o ping debe completarse despois de 1 segundo, sen importar cantas solicitudes de eco ICMPv6 ou respostas de eco se enviaron ou recibisen.
Outra cousa á que prestar atención é (DUP!) saída na segunda e seguintes respostas. Estes paquetes identifícanse como respostas duplicadas porque teñen o mesmo valor de secuencia ICMP que as solicitudes de eco ICMPv6 individuais que se enviaron en primeiro lugar. Aparecen porque unha solicitude de eco de multidifusión ICMPv6 dá lugar a varias respostas de unidifusión individuais. O número de duplicados tamén se indica no resumo das estatísticas.
Definición de interfaces - ID de zona
Outra forma de expoñer unha interface para usala é como parte dun parámetro de enderezo IPv6.
Podemos ver un exemplo disto na saída de ping, onde os enderezos dos hosts IPv6 que responden tamén teñen o sufixo %enp3s2, por exemplo:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msEste método para especificar interfaces descríbese formalmente en [RFC4007], "Arquitectura de enderezos definidos por IPv6". Aínda que normalmente se lles chama interface do sistema operativo, en realidade definen algo máis xeral: unha "zona" ou "ámbito".
A razón de ter zonas máis xerais ou zonas de alcance é que, como se menciona en [RFC4007], un nodo IPv6 pode ter varias interfaces IPv6 diferentes conectadas á mesma canle. Estas interfaces son membros da mesma zona.
Debería ser posible agrupar varias interfaces dentro dunha zona baixo o sistema operativo; Actualmente non sei se isto é posible en Linux ou como facelo.
Usando o sufixo %<zone_id>, podemos eliminar a opción da liña de comandos -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 ~]$Enlace-Respostas do enderezo local
Deste ping multicast de todos os nodos recibimos un total de 6 respostas únicas.
Estas respostas proviñan de enderezos de host IPv6 unicast Link-Local. Por exemplo, aquí está a primeira resposta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msOs enderezos IPv6 locais de enlace Unicast son necesarios en todas as interfaces habilitadas para IPv6 [RFC4291], "Arquitectura de direccionamento IP versión 6". A razón diso é que un nodo IPv6 sempre ten automaticamente un enderezo IPv6 unicast, que polo menos pode usar para comunicarse con outros nodos nas súas ligazóns directamente conectadas. Isto inclúe a comunicación con aplicacións noutros hosts a través de enderezos de host Link-Local.
Isto simplifica o deseño e implementación de protocolos como IPv6 Neighbor Discovery e OSPFv3. Tamén permite que as aplicacións do usuario final nos hosts se comuniquen a través da canle sen necesidade de ningunha outra infraestrutura compatible con IPv6 na canle. A comunicación directa entre hosts IPv6 conectados non require un enrutador IPv6 nin un servidor DHCPv6 na conexión.
Link-Locais enderezos comezan cun prefixo de 10 bits fe80, seguido de 54 cero bits e despois un identificador de interface (IID) de 64 bits. Na primeira resposta anterior 2392:6213:a15b:66ff é un IID de 64 bits.
Multicast en bucle
Por defecto, os paquetes de multidifusión devólvense internamente ao nodo que os enviou. Isto ocorre tanto para o enderezo IPv6 como para o IPv4.
O motivo deste comportamento predeterminado é que cando se envían paquetes de multidifusión, tamén pode haber unha aplicación de multidifusión local que escoita executando no propio host emisor, así como nalgún lugar da rede. Esta aplicación local tamén debe recibir paquetes de multidifusión.
Podemos ver este bucle local multicast na nosa saída de 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!)
...A primeira e máis rápida resposta (0,106 ms fronte a 0,453 ms) provén do enderezo Link-Local configurado na propia interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilidade ping proporciona un xeito de suprimir a retroalimentación de multidifusión local mediante o parámetro -L. Se enviamos un ping multicast de todos os nodos con esta marca, entón as respostas limítanse aos nodos remotos. Non recibimos resposta do enderezo Link-Local da interface de envío.
[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-Enderezos locais
Como podes adiviñar, os enderezos unicast Link-Local por si só non proporcionan información suficiente para indicar que interface usar para chegar a eles. Do mesmo xeito que co ping multicast de todos os nodos, tamén necesitamos especificar a interface como parámetro da liña de comandos ping ou ID de zona con enderezo ao facer ping a enderezos de Link-Local.
Esta vez podemos usar -cpara limitar o número de paquetes e respostas enviadas e recibidas ping, xa que estamos a realizar ping unicast.
[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 (a todos) outros enderezos IPv6?
Neste artigo, vimos como facer ping a todos os nodos IPv6 nunha canle usando un enderezo IPv6 multicast de todos os nodos ff02::1. Tamén vimos como especificar que interface usar cun enderezo IPv6 multicast de todos os nodos, xa que o propio enderezo non pode proporcionar esta información. Usamos a opción da liña de comandos ping, ou especificou a interface usando o sufixo %<zone_id>.
Despois aprendemos sobre os enderezos de enlace local unicast, que son enderezos utilizados para responder ás solicitudes de eco ICMPv6 multidifusión de todos os nodos.
Tamén vimos como os paquetes multicast son devoltos ao nodo de envío por defecto e como desactivalo para a utilidade ping.
Finalmente, fixemos ping a un único enderezo Link-Local usando o sufixo %<zone_id>, xa que os propios enderezos Link-Local tampouco proporcionan información sobre a interface de saída.
Entón, que pasa con facer ping a todos os outros nodos e obter os seus enderezos de unidifusión global (GUA) (é dicir, os seus enderezos públicos en Internet) ou os seus enderezos únicos de difusión local (ULA)? Verémolo na próxima entrada do blog.
Isto é todo.
Podes saber máis sobre o noso curso en.
Fonte: www.habr.com