Quedan pocos días para el inicio de un nuevo flujo al ritmo de OTUS. En este sentido, nos gustaría compartir con usted una traducción de material útil sobre el tema.
Una serie de publicaciones de blog sobre consejos y trucos para solucionar problemas de ping de IPv6 (solicitud de eco ICMPv6/respuesta de eco)
Tenga en cuenta que estoy usando Linux (específicamente Fedora 31), sin embargo, es de esperar que la sintaxis del comando ping para otros sistemas operativos sea muy similar.
Haga ping a todos los nodos IPv6 en un canal
El primer consejo, y el más sencillo, es hacer ping a todos los nodos IPv6 del enlace.
IPv6 utiliza direcciones de multidifusión para todo tipo de comunicaciones de uno a muchos. No hay direcciones IPv6 de difusión (o difusión). Esto distingue IPv6 de IPv4, donde existen varios tipos de direcciones de transmisión, por ejemplo, la dirección de “difusión limitada” 255.255.255.255 [RFC1122].
Sin embargo, existe una dirección IPv6 de “multidifusión para todos los nodos”, por lo que la usaremos para hacer ping a todos los nodos IPv6 en el enlace. (Una dirección de "difusión" es en realidad solo una dirección de multidifusión con un nombre especial, que es un grupo de multidifusión que incluye todos los nodos. Tenga en cuenta que, por ejemplo, el bit de "grupo" o dirección de multidifusión está activado en las direcciones de transmisión de Ethernet en la capa de enlace. ).
Dirección IPv6 de multidifusión de todos los nodos para el canal: ff02::1. ff denota una dirección IPv6 de multidifusión. El siguiente 0 es la parte de la bandera con bits no configurados.
Siguiente 2 define el área de un grupo de multidifusión. A diferencia de las direcciones IPv4 de multidifusión, las direcciones IPv6 de multidifusión tienen un alcance. El valor del alcance indica la parte de la red a través de la cual se permite reenviar un paquete de multidifusión. Una vez que un paquete alcanza el límite del alcance especificado, el paquete debe descartarse, independientemente de si su campo Hop Count es distinto de cero. Por supuesto, si el recuento de saltos llega a cero antes de alcanzar el límite del grupo de multidifusión especificado, también se restablece inmediatamente. Aquí hay una lista completa del alcance de multidifusión de IPv6.
Por último, la ::1 Especifica un grupo de multidifusión de todos los nodos.
Sobre la dirección ff02::1 Cabe señalar que es ambiguo. En un host IPv6 con múltiples interfaces, como un enrutador o un host multitarjeta, la dirección ff02::1 no hay nada donde pueda especificar a qué interfaz enviar solicitudes de eco ICMPv6 o esperar recibir respuestas de eco ICMPv6 cuando lleguen. ff02::1 es válido y se puede utilizar en cualquiera de las interfaces y canales conectados al nodo de interfaz múltiple.
Entonces, cuando hacemos ping a todos los nodos IPv6 en un enlace, también necesitamos decirle de alguna manera a la utilidad ping para IPv6, qué interfaz utilizar.
Definición de interfaces: opción de línea de comando
Como ya hemos visto, la dirección de multidifusión de todos los nodos que queremos usar es: ff02::1 - no proporciona ninguna información sobre qué interfaz enviar y recibir paquetes de solicitud de eco y respuesta de eco ICMPv6.
Entonces, ¿cómo especificamos la interfaz que se utilizará para el espacio de direcciones de multidifusión o el espacio de direcciones de enlace local de unidifusión?
La primera y más obvia forma es proporcionárselo como parámetro a la aplicación que estemos utilizando.
Por utilidad ping lo proporcionamos a través de la 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 ~]$Utilizando este ping de multidifusión de todos los nodos, recibimos respuestas de 6 nodos IPv6. Las respuestas provinieron de direcciones de nodos IPv6 de enlace local, comenzando con el prefijo fe80::/10.
Que ping no continúa enviando solicitudes de eco ICMPv6 indefinidamente hasta que lo interrumpimos, generalmente especificamos la cantidad de paquetes a enviar mediante la opción -c. Sin embargo, esto también evita que ping acepte y muestre más de una respuesta de eco ICMPv6 al enviar una solicitud de eco ICMPv6 de multidifusión. En su lugar, utilizamos la opción -w para especificar que el ping debe completarse después de 1 segundo, sin importar cuántas solicitudes de eco ICMPv6 o respuestas de eco se enviaron o recibieron.
Otra cosa a la que prestar atención es (DUP!) resultado de la segunda respuesta y siguientes. Estos paquetes se identifican como respuestas duplicadas porque tienen el mismo valor de secuencia ICMP que las solicitudes de eco ICMPv6 individuales que se enviaron en primer lugar. Aparecen porque una solicitud de eco de multidifusión ICMPv6 genera múltiples respuestas de unidifusión individuales. El número de duplicados también se indica en el resumen estadístico.
Definición de interfaces: ID de zona
Otra forma de exponer una interfaz para su uso es como parte de un parámetro de dirección IPv6.
Podemos ver un ejemplo de esto en la salida del ping, donde las direcciones de los hosts IPv6 que responden también tienen el sufijo %enp3s2, Por ejemplo:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msEste método de especificar interfaces se describe formalmente en [RFC4007], "Arquitectura de direcciones definidas IPv6". Aunque normalmente se les llama interfaz del sistema operativo, en realidad definen algo más general: una "zona" o "alcance".
La razón para tener zonas más generales o zonas de alcance es que, como se menciona en [RFC4007], un nodo IPv6 puede tener varias interfaces IPv6 diferentes conectadas al mismo canal. Estas interfaces son miembros de la misma zona.
Debería ser posible agrupar múltiples interfaces dentro de una zona bajo el sistema operativo; Actualmente no sé si esto es posible en Linux o cómo hacerlo.
Usando el sufijo %<zone_id>, podemos eliminar la opción de línea de comando -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 ~]$Respuestas de dirección local de enlace
De este ping de multidifusión de todos los nodos recibimos un total de 6 respuestas únicas.
Estas respuestas provinieron de direcciones de host IPv6 de enlace local de unidifusión. Por ejemplo, aquí está la primera respuesta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msSe requieren direcciones IPv6 locales de enlace unidifusión en todas las interfaces habilitadas para IPv6 [RFC4291], “Arquitectura de direccionamiento IP versión 6”. La razón de esto es que un nodo IPv6 siempre tiene automáticamente una dirección IPv6 de unidifusión, que al menos puede usar para comunicarse con otros nodos en sus enlaces conectados directamente. Esto incluye la comunicación con aplicaciones en otros hosts a través de direcciones de host Link-Local.
Esto simplifica el diseño y la implementación de protocolos como IPv6 Neighbor Discovery y OSPFv3. También permite que las aplicaciones de usuario final en los hosts se comuniquen a través del canal sin requerir ninguna otra infraestructura IPv6 compatible en el canal. La comunicación directa entre hosts IPv6 conectados no requiere un enrutador IPv6 o un servidor DHCPv6 en la conexión.
Las direcciones de enlace local comienzan con un prefijo de 10 bits fe80, seguido de 54 bits cero y luego un identificador de interfaz (IID) de 64 bits. En la primera respuesta anterior 2392:6213:a15b:66ff es un IID de 64 bits.
Multidifusión en bucle
De forma predeterminada, los paquetes de multidifusión se devuelven internamente al nodo que los envió. Esto sucede tanto para el direccionamiento IPv6 como para el IPv4.
La razón de este comportamiento predeterminado es que cuando se envían paquetes de multidifusión, también puede haber una aplicación de multidifusión local de escucha ejecutándose en el propio host de envío, así como en algún lugar de la red. Esta aplicación local también debe recibir paquetes de multidifusión.
Podemos ver este bucle local de multidifusión en nuestra salida 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!)
...La primera y más rápida respuesta (0,106 ms frente a 0,453 ms) proviene de la dirección Link-Local configurada en la propia interfaz. enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilidad ping proporciona una forma de suprimir la retroalimentación de multidifusión local utilizando el parámetro -L. Si enviamos un ping de multidifusión a todos los nodos con este indicador, las respuestas se limitan a los nodos remotos. No recibimos respuesta de la dirección Link-Local de la interfaz 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!)
...Enlace de ping-direcciones locales
Como puede imaginar, las direcciones de enlace local de unidifusión por sí solas tampoco proporcionan suficiente información para indicar qué interfaz utilizar para llegar a ellas. Al igual que con el ping de multidifusión de todos los nodos, también debemos especificar la interfaz como parámetro de la línea de comando. ping o ID de zona con dirección al hacer ping a direcciones de enlace local.
Esta vez podemos usar -cpara limitar el número de paquetes y respuestas enviadas y recibidas ping, ya que estamos realizando ping de unidifusión.
[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 ~]$¿Hacer ping a (todas) las demás direcciones IPv6?
En este artículo, vimos cómo hacer ping a todos los nodos IPv6 en un canal usando una dirección IPv6 de multidifusión para todos los nodos. ff02::1. También vimos cómo especificar qué interfaz usar con una dirección IPv6 de multidifusión de todos los nodos, ya que la dirección en sí no puede proporcionar esta información. Usamos la opción de línea de comando ping, o especificó la interfaz usando el sufijo %<zone_id>.
Luego aprendimos sobre las direcciones de enlace local de unidifusión, que son direcciones utilizadas para responder a solicitudes de eco ICMPv6 de multidifusión de todos los nodos.
También vimos cómo los paquetes de multidifusión se devuelven al nodo emisor de forma predeterminada y cómo desactivar esto para la utilidad. ping.
Finalmente, hicimos ping a una única dirección de enlace local usando el sufijo %<zone_id>, ya que las direcciones Link-Local en sí mismas tampoco proporcionan información sobre la interfaz saliente.
Entonces, ¿qué pasa con hacer ping a todos los demás nodos y obtener sus direcciones de unidifusión global (GUA) (es decir, sus direcciones públicas en Internet) o sus direcciones de unidifusión locales únicas (ULA)? Veremos esto en la próxima publicación del blog.
Eso es todo
Puedes conocer más sobre nuestro curso en.
Fuente: habr.com