Введение
В этой лабораторной работе вы изучите фундаментальное взаимодействие между сетевым уровнем (Layer 3) и канальным уровнем (Layer 2) в среде Linux. Вы будете использовать распространенные утилиты командной строки ping и arp для наблюдения за работой протокола разрешения адресов (ARP). Основная цель — понять, как ваша система разрешает IP-адреса в физические MAC-адреса для устройств в локальной сети и как она обрабатывает связь с удаленными хостами.
Вы начнете с проверки состояния ARP-кэша. Затем вы будете использовать ping для связи с локальным устройством (вашим шлюзом по умолчанию) и удаленным устройством (google.com). Наблюдая за ARP-кэшем до и после этих действий, вы увидите, как ваша система использует MAC-адреса для локальной связи и полагается на шлюз по умолчанию для удаленного трафика.
Просмотр начального ARP-кэша с помощью arp -a
На этом шаге вы проверите начальное состояние кэша протокола разрешения адресов (ARP) вашей системы. ARP-кэш является важнейшим сетевым компонентом, который хранит соответствия между адресами уровня 3 (IP) и соответствующими им адресами уровня 2 (MAC) для устройств в одной локальной сети.
Сначала проверим текущее состояние ARP-кэша с помощью команды arp. Флаг -a указывает команде отобразить все текущие записи.
В вашем терминале, который уже находится в пути ~/project, выполните следующую команду:
arp -a
Скорее всего, вы увидите одну или несколько записей. Обычно шлюз по умолчанию уже присутствует в кэше. Ваш вывод может выглядеть примерно так:
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Важно отметить, что из-за виртуализированной природы среды LabEx не всегда возможно полностью очистить ARP-кэш. Поэтому, скорее всего, вы увидите предварительно заполненный кэш с самого начала. В типичной не виртуализированной установке вы, скорее всего, увидите пустую запись или запись
<incomplete>для шлюза перед первым взаимодействием.
Этот вывод показывает начальное состояние нашего ARP-кэша. Он служит отправной точкой для наших следующих шагов, где мы инициируем сетевую активность и будем наблюдать, как используется эта таблица.
Пингуйте локальное устройство для инициирования ARP-запроса
На этом шаге вы будете использовать команду ping для инициирования связи с другим устройством в вашей локальной сети. Это действие будет использовать соответствие протокола разрешения адресов (ARP), если оно требуется. Когда ваша система пытается отправить пакет на локальный IP-адрес, она сначала проверяет свой ARP-кэш. Если она не находит соответствующий MAC-адрес, она отправляет широковещательный ARP-запрос. Если запись уже существует, она будет использовать MAC-адрес из кэша.
Для выполнения этого действия нам сначала нужно определить IP-адрес устройства в локальной сети. Наиболее надежной целью в этой среде является ваш шлюз по умолчанию (виртуальный маршрутизатор). Вы можете найти его IP-адрес, просмотрев таблицу маршрутизации.
В вашем терминале выполните следующую команду, чтобы отобразить таблицу маршрутизации:
ip route show
Вывод покажет вам маршрут по умолчанию. Найдите строку, начинающуюся с default via. Указанный там IP-адрес является вашим шлюзом.
default via 172.16.50.253 dev eth0 ...
...
Из приведенного выше примера вывода IP-адрес шлюза — 172.16.50.253. Теперь используйте этот IP-адрес для отправки нескольких пакетов ping. Опция -c 4 указывает команде ping отправить ровно 4 пакета и затем остановиться. Замените 172.16.50.253 на фактический IP-адрес шлюза, который вы нашли.
ping -c 4 172.16.50.253
Вы должны увидеть успешный ответ для каждого пакета, подтверждающий, что ваша система смогла связаться со шлюзом.
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
Это простое действие заставило вашу систему выполнить поиск ARP. На следующем шаге мы снова проверим ARP-кэш, чтобы увидеть результат.
Проверка разрешения IP-адреса в MAC-адрес в локальном ARP-кэше
На этом шаге вы повторно изучите ARP-кэш, чтобы увидеть прямой результат выполнения команды ping, которую вы выполнили ранее. Поскольку ваша система успешно связалась с локальным шлюзом, у нее должно было быть действительное соответствие IP-адреса MAC-адресу. Давайте посмотрим, изменилась ли таблица.
Давайте снова проверим ARP-кэш. В вашем терминале выполните ту же команду, что и на первом шаге:
arp -a
На этот раз вывод будет отличаться только в том случае, если запись еще не была завершена. В нашем случае, поскольку запись уже была разрешена на Шаге 1, вывод будет идентичным.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Сравните этот вывод с выводом из Шага 1. Он идентичен. Это связано с тем, что запись ARP для шлюза уже была полной до отправки команды ping. Вашей системе не потребовалось выполнять новый ARP-запрос; она просто использовала информацию, уже имеющуюся в кэше.
Это демонстрирует ключевой принцип: ARP-кэш предотвращает избыточные ARP-запросы. Если бы запись была <incomplete> (неполная) или отсутствовала, эта команда ping заполнила бы ее, и вы бы увидели изменение в выводе.
Пингуйте внешний узел для задействования шлюза по умолчанию
На этом шаге вы перейдете от общения с локальным устройством к общению с хостом в Интернете. Это демонстрирует фундаментальную сетевую концепцию: как ваш компьютер использует свой шлюз по умолчанию для достижения адресов за пределами своей собственной локальной сети.
Когда IP-адрес назначения находится не в той же подсети, что и ваш компьютер, ваша система знает, что не может отправить пакет напрямую. Вместо этого она должна отправить пакет своему назначенному шлюзу по умолчанию. Шлюз (маршрутизатор) отвечает за пересылку пакета к его конечному месту назначения через Интернет.
Чтобы увидеть это в действии, вы отправите ping-запрос известному внешнему хосту google.com.
В вашем терминале выполните следующую команду:
ping -c 4 google.com
Вы увидите, как домен google.com будет разрешен в IP-адрес, а затем вы получите ответы от этого адреса.
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
Несмотря на то, что вы успешно связались с google.com, ваш компьютер не выполнял ARP-запрос для IP-адреса Google. Ему нужен был только MAC-адрес его локального шлюза, который он уже нашел на предыдущих шагах. На следующем шаге вы проанализируете ARP-кэш, чтобы подтвердить это поведение.
Анализ ARP-кэша для удаленной связи
На этом заключительном шаге вы в последний раз проанализируете ARP-кэш, чтобы подтвердить, как ваша система обрабатывает связь с удаленными хостами. Это позволит четко разграничить локальную и удаленную сетевую связь и подчеркнуть роль шлюза по умолчанию.
Теперь, когда вы успешно отправили ping-запрос google.com, давайте снова проверим ARP-кэш. В вашем терминале выполните команду arp -a:
arp -a
Внимательно изучите вывод. Он должен выглядеть идентично состоянию кэша из предыдущих шагов.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Вы заметите, что нет записи для google.com или его IP-адреса (например, 142.250.189.174). Единственная значимая запись, присутствующая здесь, по-прежнему относится к вашему шлюзу по умолчанию.
Это ключевой вывод данного лабораторного занятия. ARP работает на Канальном уровне (Layer 2) и используется только для поиска MAC-адресов в локальном сетевом сегменте. Когда ваш компьютер отправляет пакет на удаленный адрес назначения, он знает, что этот адрес не является локальным, поэтому он отправляет пакет на MAC-адрес следующего узла — вашего шлюза по умолчанию. Затем маршрутизатор берет на себя ответственность за пересылку IP-пакета к его конечному месту назначения. Вашему компьютеру не нужно знать MAC-адрес google.com; ему нужно знать только MAC-адрес устройства, которое может переслать пакет от его имени.
Резюме
В этой лабораторной работе вы исследовали фундаментальное взаимодействие между сетевыми уровнями 3 (IP) и 2 (MAC), используя команды ping и arp в Linux. Вы начали с проверки состояния кэша протокола разрешения адресов (ARP) с помощью команды arp -a, отметив, что он может уже содержать записи для критически важных устройств, таких как шлюз по умолчанию. Отправив ping-запрос локальному шлюзу, вы подтвердили, что система использует эту кэшированную информацию для локальной связи, избегая избыточных запросов адресов.
Кроме того, вы исследовали, чем отличается связь с удаленным хостом. Когда вы отправляли ping-запрос на внешний IP-адрес, вы заметили, что система не выполняет ARP-запрос для конечного адреса назначения. Вместо этого она отправляет пакет на шлюз по умолчанию для маршрутизации за пределы локальной сети. Окончательный анализ ARP-кэша подтвердил эту концепцию, показав, что для удаленного хоста не было добавлено ни одной записи. Единственной релевантной записью осталась запись шлюза по умолчанию, подчеркивающая его решающую роль в качестве посредника для всего трафика, предназначенного для внешних сетей.
