Назад | Перейти на главную страницу

Можно ли использовать proxy-arp обратно в тот же интерфейс?

У меня есть точка доступа Wi-Fi, подключенная к маршрутизатору Linux. Маршрутизатор сам подключен к Интернету. По нескольким причинам (в основном для контроля безопасности и качества обслуживания) я хочу заставить весь пользовательский трафик проходить через маршрутизатор Linux, даже трафик между пользователями.

Для этого я отключил связь между станциями в точке доступа (я использую точку доступа D-Link DWL-7200). Вот как я настроил точку доступа:

ssh admin@accesspoint1
D-Link Access Point wlan1 -> set sta2sta disable
D-Link Access Point wlan1 -> reboot

Это прекрасно работает: пользователи беспроводной сети больше не могут общаться друг с другом. По крайней мере, не напрямую. Моя цель - заставить трафик подниматься до роутера и обратно.

Делать который, Я включил proxy-arp в маршрутизаторе Linux:

echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

Вот общая картина.

                  10.0.0.0/8 subnet    
   ____________________|______________________
  /                                           \
  |                                           |

               (sta2sta disabled)
  UserA----------------AP---------------------Router-------------------Internet
10.0.0.55             /                   eth1     eth0
                     /                10.0.0.1     203.0.113.15
                    /        proxy-arp enabled
  UserB____________/
10.0.0.66

Вот что я надеялся произойдет, если UserA пингует UserB:

UserA пытается пинговать 10.0.0.66
поэтому UserA отправляет широковещательную рассылку ARP со словами "У кого 10.0.0.66?"
Точка доступа пропускает запрос к маршрутизатору (но не к UserB, потому что sta2sta отключена)
маршрутизатор получает запрос, и поскольку proxy-arp включен на eth1, он должен ответить «Отправить мне пакеты для 10.0.0.66 (MAC-адрес маршрутизатора)».
точка доступа должна получить ответ и передать его пользователю A.
тогда UserA должен отправить фактический пакет ping на MAC-адрес маршрутизатора.
пакет должен пройти через точку доступа к маршрутизатору
Маршрутизатор должен направить его обратно на eth1, изменив MAC-адрес назначения на MAC-адрес пользователя UserB (при необходимости выполнив ARP-запрос) и изменив исходный MAC-адрес на свой собственный.
Пакет должен достичь точки доступа и быть передан пользователю B.
Пользователь B должен ответить на запрос ping.
ответ должен пройти через точку доступа к маршрутизатору.
ответ должен быть направлен пользователю А.
и он должен пройти через AP и достигнуть UserA.

К сожалению, на шаге 4 вся эта мечта терпит неудачу, потому что маршрутизатор Linux получает запрос ARP, но не может на него ответить. Из того, что я прочитал в Интернете, кажется, что это нормально: proxy-ARP на самом деле не предназначен для использования в такой настройке. Чтобы быть более точным: маршрутизатор не отвечает на запросы ARP для хостов, которые находятся на том же интерфейсе, с которого пришел запрос ARP. В этом случае ARP-запрос исходит от eth1, но он говорит: «У кого IP 10.0.0.66?», А хост 10.0.0.66 находится на интерфейсе eth1.

Я понимаю, почему это хорошее поведение по умолчанию, потому что, если sta2sta не была отключена в AP, UserA получал бы ответ ARP от маршрутизатора и другой ответ ARP от UserB. Но в моем случае я считаю, что было бы разумно отвечать на каждый запрос ARP, даже для хостов с одним и тем же интерфейсом.

Есть ли способ обойти это поведение прокси-arp по умолчанию?

То, что вы хотите, на самом деле возможно, но требует довольно свежего ядра Linux (> = 2.6.34 или резервного порта).

Вам нужен вариант /proc/sys/net/ipv4/conf/*/proxy_arp_pvlan:

proxy_arp_pvlan - BOOLEAN
    Private VLAN proxy arp.
    Basically allow proxy arp replies back to the same interface
    (from which the ARP request/solicitation was received).

    This is done to support (ethernet) switch features, like RFC
    3069, where the individual ports are NOT allowed to
    communicate with each other, but they are allowed to talk to
    the upstream router.  As described in RFC 3069, it is possible
    to allow these hosts to communicate through the upstream
    router by proxy_arp'ing. Don't need to be used together with
    proxy_arp.

    This technology is known by different names:
      In RFC 3069 it is called VLAN Aggregation.
      Cisco and Allied Telesyn call it Private VLAN.
      Hewlett-Packard call it Source-Port filtering or port-isolation.
      Ericsson call it MAC-Forced Forwarding (RFC Draft).

Коммит восходящего потока, добавляющий эту поддержку, 65324144b50bc7022cc9b6ca8f4a536a957019e3.

Я не уверен, что реализацию proxyarp в Linux можно легко настроить для достижения вашей цели. Рассматривали ли вы использование подхода подсетей / маршрутизации?

Идея вот в чем: выделите, скажем, /24 адресное пространство для вашей беспроводной сети. Чтобы соответствовать примеру вашего вопроса, я буду использовать 10.0.0.0/24. Теперь разделите это /24 в 62 /30 подсети: 10.0.0.4/30, 10.0.0.8/30, 10.0.0.12/30, ... 10.0.0.248/30.

Каждый /30 имеет 2 доступных IP-адреса, один из которых назначен беспроводному клиенту, а другой назначен (псевдоним) для eth1 интерфейс вашего маршрутизатора Linux. Чтобы быть конкретным, допустим, мы назначаем адреса беспроводных клиентов из этой серии: 10.0.0.6, 10.0.0.10, 10.0.0.14, ..., 10.0.0.250. И мы назначаем следующую серию IP-адресов псевдонимом eth1 на роутере: 10.0.0.5, 10.0.0.9, 10.0.0.13, ..., 10.0.0.249.

Для завершения настройки каждый беспроводной клиент получает сетевую маску 255.255.255.252 и шлюз по умолчанию 10.0.0.X-1 (где X - последний октет IP-адреса клиента). На роутере ip Команда может использоваться для добавления IP-адресов в eth1 следующим образом:

ip addr add 10.0.0.5/30 broadcast 10.0.0.7 dev eth1
ip addr add 10.0.0.9/30 broadcast 10.0.0.11 dev eth1
ip addr add 10.0.0.13/30 broadcast 10.0.0.15 dev eth1
...
...
ip addr add 10.0.0.249/30 broadcast 10.0.0.251 dev eth1

Плюсы:

Достигает желаемой цели: весь трафик беспроводных клиентов пересылается через маршрутизатор, и клиенты могут связываться друг с другом.
Широковещательные передачи ARP случаются редко, поскольку первым переходом каждого клиента всегда является маршрутизатор.

Минусы:

Конфигурация нестандартная. Статическая настройка (клиенты и маршрутизатор) может быть выполнена довольно легко, но динамическая (DHCP) конфигурация будет очень сложной.