позвольте мне представить сценарий.
AP#1 <-----> (Linux #1) <-----> Промежуточная сеть <-----> (Linux #2) <-----> Беспроводной клиент
Подводя итог, мне нужно, чтобы приложение, работающее в беспроводном клиенте, могло прозрачно взаимодействовать с точкой доступа №1 (АП#1).
Как вы можете видеть выше, у меня есть устройство с именемАП#1, который генерирует точку доступа для данного приложения. Это приложение может быть использовано путем присоединения кАП#1, и я хочу, чтобы беспроводной клиент использовал его удаленно. Поскольку я не могу коснуться конфигурацииАП#1, но я могу настроитьЛинукс №1иЛинукс №2, я попробовал следующее:
- Линукс №1ассоциировать себя сАП#1используя wpa supplicant, оставаясь в той же подсети.
- Линукс №2создает точку доступа для беспроводного клиента в другой подсети.
- Беспроводной клиент обращается к фиксированному IP-адресу в точке доступа №1, а трафик маршрутизируется и преобразуется вЛинукс №1, так что общение сАП#1прозрачен.
Пока все хорошо, беспроводной клиент может пинговать адрес AP#1. Однако беспроводной клиент начинает коммуникацию, отправляя пакет UDP на 255.255.255.255, ожидая, чтоАП#1ответы до того, как приложение фактически начнет работать. Есть ли способ маршрутизировать эти запросы туда и обратно или 255.255.255.255 вообще не маршрутизируется?
Я думал об изменении этой конфигурации с помощью туннеля gretap, но эта топология немного отличается от примеров, которые я видел, так как я не могу настроитьАП#1.
Итак, вот мои вопросы:
- Как вы думаете, можно ли решить эту проблему, создав своего рода туннель L2?
- Если да, то какой вариант будет лучшим?
- В таком случае, возможно ли будет удалить NAT в Linux №1 и сделать связь между точкой доступа №1 и беспроводным клиентом полностью прозрачной?
Заранее спасибо и извините за нубские вопросы.
решение1
Как вы думаете, можно ли решить эту проблему, создав своего рода туннель L2?
Да, и мосты на обоих концах. Но Linux может не упростить мостовое соединение клиентского интерфейса Wi-Fi (см. ниже).
Есть ли способ маршрутизировать эти запросы туда и обратно или 255.255.255.255 вообще не маршрутизируется?
Пересылка широковещательных пакетов не запрещена, например, в Cisco IOS такая возможность есть, хотя маршрутизаторы по умолчанию этого не делают, чтобы избежать петель.
Я не уверен, что Linux может сделать это изначально, хотя это может быть возможно с помощью неясного правила iptables. Будет проще использовать демон пользовательского пространства, bcrelayкоторый может пересылать широковещательные сообщения в одном направлении.
В таком случае, возможно ли будет удалить NAT в Linux №1 и сделать связь между точкой доступа №1 и беспроводным клиентом полностью прозрачной?
Не совсем. Вы можете сделать его полностью прозрачным на уровне IP, но стандартный клиент Wi-Fi может отправлять кадры только со своим собственным MAC-адресом, поэтому вы не сможете просто объединить клиентский интерфейс Wi-Fi — для этого понадобитсяуровень 2 NATкакого-либо типа на устройстве "Linux#1". (Устройство "Linux#2" является точкой доступа, поэтому ономожетбыть полностью прозрачным на уровне 2.)
Я не знаю, как реализовать это в стандартном Linux, хотя я видел ARPNAT в фирменных прошивках (устройства Mikrotik RouterOS и Ubiquiti airOS), когда они установлены в режим станции. Я думаю, что многие потребительские "беспроводные мосты" также реализуют это.
(Linux поддерживает ассоциацию в режиме «4addr», который полностью поддерживает мостовое соединение, но, скорее всего, ваша точка доступа его не поддерживает.)