Вопрос или проблема
Я пытаюсь диагностировать проблему с перебоями в сетевом соединении между моим хостом macOS и гостевой виртуальной машиной UTM. Соединение внезапно обрывается, и хост больше не может достучаться до виртуальной машины. В настоящее время я подозреваю проблему с таблицей маршрутизации в macOS.
При просмотре вывода route я не нашел объяснения некоторым странным записям Gateway, которые не похожи ни на адреса v4, ни на v6?
$ netstat -rn -f inet
Маршрутизационные таблицы
Интернет:
Назначение Шлюз Флаги Нетф Expire
default 192.168.178.1 UGScg en0
default link#24 UCSIg bridge100 !
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#15 UCS en0 !
169.254.169.254 link#15 UHLSW en0 !
192.168.64 link#24 UC bridge100 !
192.168.64.1 62.3e.5f.73.14.64 UHLWI lo0
192.168.64.2 8a.c3.94.a.86.e2 UHLWIi bridge100 1088
192.168.178 link#15 UCS en0 !
192.168.178.1/32 link#15 UCS en0 !
192.168.178.1 dc:15:c8:ef:b8:1d UHLWIir en0 1197
192.168.178.24 1c:1a:df:76:df:f8 UHLWI en0 !
192.168.178.52/32 link#15 UCS en0 !
224.0.0/4 link#15 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
224.0.0.251 1:0:5e:0:0:fb UHmLWIg bridge100
255.255.255.255/32 link#15 UCS en0 !
Виртуальная машина имеет 192.168.64.2 — обратите внимание на Gateway 8a.c3.94.a.86.e2. Что это такое? Я никогда не видел IP-адрес, отформатированный таким образом, или это какой-то другой тип идентификатора назначения?
Скорее всего, это разрешенные MAC-адреса – macOS использует одну таблицу как для маршрутизации, так и для ARP-кэша.
По сути, цель поля ‘Gateway’ состоит в определении назначения на уровне MAC, а не на сетевом уровне – мы просто обычно делаем это косвенно, указывая IP-адрес шлюза (или интерфейса) и позволяя ОС использовать ARP для разрешения его в фактический MAC-адрес.
-
Например,
Gateway: 192.168.178.1не означает “Отправить на 192.168.178.1”, это означает “Сделай запрос ARP для 192.168.178.1 и отправь на этот MAC-адрес”. -
Аналогично, поле
link#24не означает “Отправить через интерфейс #24” – этого недостаточно для Ethernet – это действительно означает “Сделай запрос ARP для IP-адреса назначения, получи MAC-адрес и отправь на этот MAC через интерфейс #24″.
Результат этого запроса ARP обычно кэшируется в отдельной таблице (ARP-кэш) в других операционных системах, но это означает, что у вас есть две таблицы, которые, по сути, делают одно и то же (отображение IP на какой-то MAC), поэтому, похоже, что macOS (и, полагаю, также FreeBSD) выбрали использовать одну и ту же таблицу для обоих.
Таким образом, если у вас есть 192.168.64.2 в качестве назначения, после того как будет выполнен поиск 192.168.64 -> link#24 и будет сделан запрос ARP, ОС добавляет прямую запись 192.168.64.2 -> 8a.c3.94.a.86.e2, чтобы избежать необходимости повторять запрос ARP для будущих пакетов. (Обратите внимание на флаг L “линк-уровня” и наличие поля Expire для этой записи.)
Что касается того, почему адреса отформатированы по-разному, глядя на netstat FreeBSD, кажется, что интерфейсы “bridge” имеют отличительный тип от “ethernet” (IFT_BRIDGE против IFT_ETHER), и я подозреваю, что macOS netstat просто использовал две разные функции для форматирования адреса в текст…
Ответ или решение
Когда вы смотрите на вывод команды netstat -rn -f inet на вашем macOS, вы, возможно, заметили странные записи в колонке Gateway, которые выглядят как MAC-адреса, а не как IPv4 или IPv6 адреса. Это может вызывать вопросы, особенно когда вы пытаетесь диагностировать проблемы с сетевой связью между вашим хостом и виртуальной машиной UTM.
Во-первых, важно понимать, что в операционной системе macOS (как и в FreeBSD) таблица маршрутизации и кэш ARP (Address Resolution Protocol) объединены. Это означает, что поле Gateway в таблице маршрутизации может содержать не только IP-адреса, но и MAC-адреса. Фактически, цель поля Gateway заключается в том, чтобы определить адрес назначения на уровне канала, а не на уровне сети.
Для примера, когда вы видите Gateway: 192.168.178.1, это не значит, что пакеты отправляются «на 192.168.178.1». Вместо этого это означает: «выполните ARP-запрос для получения MAC-адреса 192.168.178.1 и отправьте пакеты на этот MAC-адрес».
Странные записи, такие как 8a.c3.94.a.86.e2, которые вы заметили в качестве шлюза для 192.168.64.2, являются результатом обработки ARP-запросов. Когда система получает информацию о том, что отправка пакетов на 192.168.64.2 ведет к MAC-адресу 8a.c3.94.a.86.e2, она добавляет эту запись в таблицу, чтобы избежать повторных ARP-запросов для будущих пакетов.
Запись link#24 указывает на то, что пакеты должны быть отправлены через интерфейс, связанный с этой меткой (в данном случае это bridge-интерфейс). Эта структура в macOS, возможно, отличается от других операционных систем, так как здесь используется два разных метода для отображения адресов в текстовом виде в зависимости от типа интерфейса (например, Ethernet vs. Bridge).
Если у вас возникают проблемы с подключением к вашей виртуальной машине, проверьте следующие моменты:
- Убедитесь, что ваша виртуальная машина правильно настроена на получение IP-адреса и что она доступна в сети.
- Проверьте, не блокирует ли брандмауэр пакеты, выходящие с вашего хоста на виртуальную машину или наоборот.
- Убедитесь, что межсетевые маршруты настроены корректно, особенно если ваши машины находятся в разных подсетях.
Если после проверки всех упомянутых моментов проблема не устранена, попробуйте сбросить сетевые настройки на обоих устройствах и перезагрузить их. Это может помочь восстановить нормальную связь.