![Что вызывает потерю пакетов ответа ARP в беспроводной сети?](https://rvso.com/image/1452882/%D0%A7%D1%82%D0%BE%20%D0%B2%D1%8B%D0%B7%D1%8B%D0%B2%D0%B0%D0%B5%D1%82%20%D0%BF%D0%BE%D1%82%D0%B5%D1%80%D1%8E%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2%20%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D0%B0%20ARP%20%D0%B2%20%D0%B1%D0%B5%D1%81%D0%BF%D1%80%D0%BE%D0%B2%D0%BE%D0%B4%D0%BD%D0%BE%D0%B9%20%D1%81%D0%B5%D1%82%D0%B8%3F.png)
В моей локальной сети (LAN) имеется сеть беспроводных точек доступа (AP).
Некоторые ПК в сети могут получать ответы на ping от некоторых других ПК/устройств в сети, но не от некоторых других. Я не нашел надежной закономерности, но вкратце это может быть что-то вроде этого:
Допустим, у нас есть компьютер Алиса, точка доступа Wi-Fi Боб и еще одна точка доступа/устройство Wi-Fi Чарли.
Алиса может отправить ping-запрос Бобу, Боб может отправить ping-запрос Чарли, но Алиса не может отправить ping-запрос Чарли. («ping» означает возможность получать ответы на ping-запросы). Я уже отключил все брандмауэры и разрешил все ответы ICMP.
С помощью Wireshark и tcpdump я пришел к выводу, что пакет запроса ARP (код операции 1) от Алисы смог достичь предполагаемого пункта назначения Чарли, а Чарли отправил обратно пакет ответа ARP (код операции 2), который не дошел до Алисы.
Какие технические недостатки могли привести к такой ошибке?
Как мне исправить эту ситуацию?
Если предположить, что у меня есть некий программный контроль, поскольку я использую OpenWRT, как я могу решить эту проблему?
Самое смешное, что когда я изменил имя своего ПК с Windows 8, эта проблема была исправлена. Не уверен, является ли это случаем post hoc ergo propter hoc.
Обновление: Точки доступа/устройства/ПК находятся в одной подсети и соединены в режиме моста.
решение1
Хотя я не очень хорошо знаком с расширенной настройкой OpenWRT (это в моем списке дел для проектов гиков), мой первый совет — убедиться, что вы не используете NAT на «Бобе». Если бы Алиса была на стороне LAN WAP, а Чарли — на стороне WAN, то Алиса могла бы пинговать Чарли, но не наоборот. Это встроенный брандмауэр, который обеспечивает NAT.
Чтобы этого не произошло, все ваши точки доступа должны работать в каком-то режиме «моста» или «точки доступа». Это означает, что устройство действует как более или менее пересылающий пакеты — оно не выполняет никакой собственной маршрутизации или проверки пакетов. Самый простой способ добиться этого на более дешевых маршрутизаторах — отключить DHCP-сервер в маршрутизаторе, а затем подключить один из портов LAN к вашей сети (а также убедиться, что LAN IP маршрутизатора не будет конфликтовать с вашим реальным шлюзом). Вы бы оставили порт WAN висящим. Если маршрутизатор жалуется (большинство не жалуется, но некоторые жалуются), установите подключение к Интернету на статический IP и используйте что-то вроде 223.255.255.254 с маской подсети 255.255.255.252 для адреса и 223.255.255.253 для шлюза. (Интересный факт: это последняя подсеть класса C наименьшего возможного размера.)
Другой возможностью может быть несоответствие маски подсети. Каждый компьютер в одной сети должен иметь одну и ту же настроенную маску подсети (конечно, при этом находясь в одной и той же фактической сети). Компьютер использует маску подсети не только для определения широковещательного IP-адреса, но и для определения того, должны ли полученные широковещательные пакеты обрабатываться сетевым стеком (т. е. если широковещательные пакеты для IP-адресов, которые не попадают в адрес и маску подсети, настроенные на устройстве, многие устройства будут игнорировать пакет).
Надеюсь, это хоть как-то поможет.
решение2
Что вызывает потерю пакетов ответа ARP в беспроводной сети?
Ничего. Если бы мы наблюдали правильное отбрасывание пакетов, не было бы причин для их предпочтительного отбрасывания. При наличии неисправной линии связи пакеты ARP ничем не отличаются от UDP, TCP и т. д. Но, поскольку вы не утверждаете, что линия медленная, нет никаких реальных причин подозревать истинное отбрасывание пакетов.
Причина, по которой пакеты не достигают своей предполагаемой цели, заключается в том, что они неправильно маршрутизируются. Однако вы указали, что пакеты, которые магическим образом исчезают, являются пакетами ARP, которым не нужна правильная маршрутизация, поскольку они спонтанно заполняют всю подсеть, к которой они принадлежат.
Следовательно, ПК (скорее всего) являются членами двух разных подсетей. Пакеты ARP не пересекают шлюзы, и одна из причин, по которой они должны бытьупавшийзаключается в том, что они заполняют свою собственную подсеть, не находят респондента, а затем исчезают, не пересекая шлюз, разделяющий две разные подсети.
Принадлежность к двум отдельным подсетям будет замаскирована, так сказать, если бы вы использовали имена вместо IP-адресов. Если бы вместо этого вы использовали IP-адреса, вы бы сразу поняли, что два компьютера находятся в разных подсетях. Отсюда мой вопрос выше.
Можно ли обойти эту проблему? Конечно, можно. Вам придется определить шлюз подсети, до которой невозможно добраться (назовем его G2), разрешить соединения из более крупной локальной сети, а затем указать шлюзу всей вашей локальной сети (G1, тот, что сразу за модемом, или маршрутизатором ADSL, в зависимости от того, что вам нужно), что маршрут к этой подсети не через нее саму, G1, а через G2.