Пинг всех узлов IPv6 на канале
Серия статей в блоге, посвященных советам и рекомендациям по устранению неполадок, связанных с пингом 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 .
С помощью этого 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 , например:
Этот способ задания интерфейсов формально описан в [RFC4007], «Архитектура с заданными адресами IPv6». Хотя обычно они называются интерфейсом операционной системы, они на самом деле определяют нечто более общее — «зона» или «область действия».
Причина наличия более общих зон или scope зон состоит в том, что, как упоминается в [RFC4007], узел IPv6 может иметь несколько различных интерфейсов IPv6, подключенных к одному и тому же каналу. Эти интерфейсы являются членами одной зоны.
Должно быть возможно сгруппировать несколько интерфейсов в пределах зоны под операционной системой; В настоящее время я не знаю, возможно ли это под Linux и как это сделать.
Используя суффикс %<zone_id> , мы можем удалить параметр командной строки -I ping .
Ответы Link-Local адресов
От этого all-nodes multicast пинга мы получили в общей сложности 6 уникальных ответов.
Эти ответы поступили от юникаст Link-Local адресов узлов IPv6. Например, вот первый ответ:
Юникаст 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 выводе:
Первый и самый быстрый ответ (0,106 мс по сравнению с 0,453 мс) происходит от Link-Local адреса, настроенного на самом интерфейсе enp3s2 .
Утилита ping предоставляет способ подавления локальной обратной связи мультикастовой рассылки с помощью параметра -L . Если мы отправляем пинг all-nodes multicast с этим флагом, то ответы ограничиваются удаленными узлами. Мы не получаем ответ от Link-Local адреса интерфейса отправителя.
Пинг Link-Local Адреса
Как вы можете догадаться, юникастовые Link-Local адреса сами по себе также не предоставляют достаточно информации, чтобы указать, какой интерфейс использовать для их достижения. Как и в случае all-nodes multicast пинга, нам также необходимо указать интерфейс в качестве параметра командной строки ping или zone ID с адресом при пинге Link-Local адресов.
На этот раз мы можем использовать -c , чтобы ограничить количество пакетов и ответов, отправляемых и получаемых ping , поскольку мы выполняем юникастный пинг.
Пинговать (все) другие 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)? Мы рассмотрим это в следующей статье блога.
pinging broadcast address [closed]
NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta.
Closed 6 months ago .
Iam using linux.I read somewhere in the internet that pinging the 255.255.255.255 will ping everyone in the network segment. And it will return every ip addresses in that subnet. but when i tried
I am only getting the reply from only one ip. how to get every ip, I know how to get every ip with nmap but what I read in the internet is totally opposite in my senario why?
Send a ping to each IP on a subnet
Not all machines have nmap available, but it’s a wonderful tool for any network discovery, and certainly better than iterating through independent ping commands.
I would suggest the use of fping with the mask option, since you are not restricting yourself in ping.
The response will be easy to parse in a script:
Note: Using the argument -a will restrict the output to reachable ip addresses, you may want to use it otherwise fping will also print unreachable addresses:
fping differs from ping in that you can specify any number of targets on the command line, or specify a file containing the lists of targets to ping. Instead of sending to one target until it times out or replies, fping will send out a ping packet and move on to the next target in a round-robin fashion.
Broadcast ICMP in Linux and How to Initiate and Protect
How can I discover all hosts on my network? How can a hacker discover all hosts on your network ? Two very different questions from the view point of appropriate network use but the same tools can be used. In this blog we look at ICMP Broadcast and how we can initiate this with the Linux ping command. We will see that Linux is protected on the outset against this type of discovery but other hosts may not. Learning techniques will help on the way to certification with the LPI and LPIC-3 exam 303 and Linux Security.
Each objective is available to view online. However if you prefer to have all the content in one place and study from an eBook then the objective ‘LPIC 3 Linux Security 326.1 Host Hardening’ is now available to download for just £0.99.
Managing ICMP Broadcast with Ping
One easy was to discover hosts that are ‘alive’ on a network is to ping the broadcast address for the network. In Linux this is an easy task.
Do take care though that this is a network that you manage as some switches may disable ports where this type of activity is taking place.
For this demonstration I am using a CentOS 6 system connected to my network. The network is 192.168.0.0/24 so the corresponding broadcast for this network will be 192.168.0.255 . If I ping to the broadcast address each host can respond. We have already seen that Linux by default protect against this type of discovery with the procfs key net.ipv4.icmp_echo_ignore_broadcasts to to 1. Ignoring any ICMP broadcast.
We can see that we are getting replies from 192.168.0.1 , 192.168.0.11 , 192.168.0.13 and 192.168.0.20 . The CentOS 6 host has an IP Address of 192.168.0.57 and we see that it does not respond.
If we use Linux security as being like an onion, with many layers, the more protection that we can offer to our servers the better. Although we do not prevent discovery or determinisation of services by this capability we do add steps and tim. For a quick an easy look at this network I would concentrate on these servers that respond to the ICMP broadcast.
To show how we become more visible by inverting this setting so we do respond to ICMP broadcasts we will enable this on my system:
When we now ping again to the broadcast address the CentOS 6 host 192.168.0.57 responds: