Этот вопрос изначально был размещен на сайте Network Engineering SE, но закрыт из-за того, что он не по теме.
Я наткнулся на странное поведение хостов Windows в нашей сети.
Наши клиенты в основном работают в беспроводном сегменте нашей сети. Точки доступа Ubiquiti, которые мы используем, блокируют многоадресный и широковещательный трафик из проводного сегмента в беспроводной из соображений производительности.
Когда хост (клиент) на стороне WiFi связывается с хостом (сервер) в проводной сети под управлением Linux все работает нормально. В клиент отправляет запрос ARP, который транслируется в проводной сегмент, сервер отвечает, используя одноадресный ответ ARP, и изучает клиентMAC-адрес пользователя в процессе. Тогда IP-пакеты можно будет обмениваться обычным образом.
С Windows серверОднако все выглядит иначе. Если я пингую сервер в 10.10.10.4 с клиент на 10.10.244.14 я вижу следующие пакеты на серверинтерфейс:
15:11:50.892975 4c:32:75:95:b9:7b > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 tell 10.10.244.14, length 46
15:11:50.893725 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:11:50.898967 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 39008, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 0, length 64
15:11:50.899285 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.711006 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.895016 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 9988, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 1, length 64
[...]
Кажется, что винда сервер не обновляет свою таблицу ARP из полученного запроса ARP, но отправляет свой собственный запрос, чтобы получить клиентMAC-адрес (как показано в четвертом пакете выше). Эти запросы транслируются и поэтому никогда не достигают клиент. Как следствие, на эхо-запросы нельзя ответить, потому что сервер не знает куда их послать.
Вот что интересно. Если я продолжу пинговать сервер, примерно через две минуты запись ARP для сервер на клиент кажется несвежим, одноадресная передача Запрос ARP отправляется на сервер чтобы проверить кешированный MAC-адрес, и с этого момента на пинги будут отвечать:
15:13:57.289539 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 (52:75:9a:65:57:e4) tell 10.10.244.14, length 46
15:13:57.289945 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31608, offset 0, flags [none], proto ICMP (1), length 84)
10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 126, length 64
15:13:57.290001 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:13:58.292013 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 60751, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 127, length 64
15:13:58.292336 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31609, offset 0, flags [none], proto ICMP (1), length 84)
10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 127, length 64
Для меня это выглядит так, как будто Windows сервер обновляет свой собственный кеш ARP только при получении запроса ARP для своего адреса, когда это одноадресный запрос.
Если я понимаю RFC правильно, это не кажется правильным поведением. Я понимаю, что получатель ARP-запроса всегда должен Обновить собственная таблица ARP, если уже есть запись для отправляющего хоста, или вставить а новый запись для хоста-отправителя, если запрос ARP предназначен для его собственного адреса.
Я неправильно читаю спецификацию или Windows делает что-то другое? Если последнее, можно ли настроить такое поведение?
Спасибо за любые указатели.
Точки доступа Ubiquiti, которые мы используем, блокируют многоадресную рассылку и широковещательный трафик из проводного сегмента в беспроводной сегмент из соображений производительности.
Это нарушает любую связь между проводным и беспроводным сегментами. Для работы ARP необходимы трансляции.
Вы можете фильтровать / блокировать определенные типы нежелательных трансляций, но не все из них. Для чистого подхода вы должны использовать выделенную беспроводную подсеть (или несколько) и маршрут между ней и остальными.