Intereting Posts
Как установить диск с правой файловой системой? Установка частоты повторения клавиатуры USB автоматически Есть ли веб-браузер для Linux, который реализует движок Trident (Internet Explorer)? вызывать скрипт, если окно zenity минимизировано, изменено или перемещено Какой дистрибутив Linux имеет первоклассный рабочий стол KDE и стабилен и прост? Могу ли я изменить свою установку ChrUbuntu на Arch Linux на Chromebook от Samsung XE500C21? Порядок между опциями и операндами? Можно ли рассматривать проект GNU как дистрибутив Linux? Создание проблемы GPG Как включить горизонтальную полосу прокрутки в GNU Emacs для linux ubuntu? sudoers: NOPASSWD в той же строке, что и PASSWD: ALL? Почему systemd-coredump хранит дамп в самой памяти? Эффективно скопировать вставку (kill / yanking) с emacs, запущенным в tmux на Mac OS X Как я могу переключиться с одного пользователя на другого пользователя внутри сценария? Как заменить «^» на пробел?

Как заставить пакет пройти через определенный физический интерфейс, зная только MAC-адрес назначения?

Я создаю L3-Switch, который изменяет пакеты, перенаправляя некоторые из них в локальное приложение. Моя цель – отправить их дальше на тот же MAC, что и раньше.

Короткое «почему»: устройство с нулевым разрешением для подключения к любой сети Ethernet, переносимое, выполняет проксирование.

Коммутатор организован как сетевой мост (br-lan) между eth0 и eth1. По умолчанию предполагается, что шлюз для клиентов br-lan лежит через eth0.

Вопрос: допустим, что пакет приходит от eth1 на пути к eth0 и перенаправляется в локальное приложение. После того, как у этого приложения есть выход, и IP-адрес назначения исходного пакета изменился. L3 пытается направить пакет в новое место назначения, но у него нет шлюзов по умолчанию (и не должно быть, потому что это коммутатор!). Предполагая, что я знаю MAC-адрес шлюза по умолчанию, как заставить пакет выходить через eth0 на определенный MAC-адрес?

Технически я не пытаюсь сделать что-то «незаконное» с точки зрения сети. Я хочу выкинуть пакет из eth0, и все, что мне «не хватает», это MAC-адрес назначения, но я могу получить его из исходного пакета. Я точно знаю, что IP-адрес назначения не является локальным, поэтому он все равно будет отправлен на шлюз по умолчанию, используя его MAC-адрес. Так что это вопрос реализации.

Я пытался изменить целевой MAC на мосту -t NAT OUTPUT, выполнив это:

ebtables -t nat -A ВЫВОД -p ipv4 –ip-proto tcp –ip-src 192.168.1.251 -j dnat –to-dst 04: 61: e7: d2: e2: 09

Но это не помогло. (Предполагается, что 04: 61: e7: d2: e2: 09 является MAC-адресом шлюза по умолчанию, а 192.168.1.251 – один из клиентов, просто для проверки этой теории)

Фактическая реализация в OpenWRT, поэтому доступные пакеты могут быть ограничены.

Как я дошел до этой проблемы:

Дополнительная информация о локальном приложении: отсюда ss-redir, привязка к 0.0.0.0:port => https://github.com/shadowsocks/shadowsocks-libev

Добавлены варианты использования в [Устройство]:

Ожидание: у нас 3 ПК-клиента, подключенных к обычному коммутатору. После подключения [Device] и его подключения к обычному коммутатору и повторного подключения ПК-клиентов к [Device] ПК-клиенты получают [Result] без настройки устройства.

[Результат]:

1) Снаружи (другие узлы сети, кроме 3 наших и все остальное) должно выглядеть так, как будто каждый пользователь сохраняет свою пару IP / MAC, чтобы администратор был счастлив. DHCP настроен статически в офисе, поэтому пара IP / MAC, вероятно, не изменится, но администратор может изменить все это. И устройство должно обрабатывать любые изменения без перенастройки вручную. В сети не должно появляться новых IP / MAC (не зарегистрированных администратором).

2) «Снаружи» каждый ПК-клиент должен быть доступен для всех протоколов в сети, какими бы они ни были (RDP, NetBIOS для разрешения имен, общего доступа к файлам или любого другого решения, принятого локальным администратором).

3) Они должны иметь доступ к Интернету через шлюз по умолчанию, как всегда, за исключением передачи по TCP через SS для определенного ipset назначения (который всегда через тот же шлюз)

Предполагая, что эти варианты использования требуют, чтобы устройство с самого начала не имело знания IP / MAC о существующей сети (потому что офисные пользователи не будут ничего настраивать самостоятельно), я пытаюсь создать «мост прокси», который работает как коммутатор перехватывает пакеты и отправляет их в eth0 (WAN) после перенаправления локального приложения. Проблема заключается в том, что пакет после перенаправления должен быть отправлен в пути. Я исследую «идею автоматического повторного конфигурирования на лету» с MAC-snat / dnat, но застрял с проблемой, что пакет не перейдет к eth0 после генерации локально, даже если я могу указать MAC-addr шлюза по умолчанию в ebtables в качестве пункта назначения.

Позвольте мне угадать какое-то «оригинальное задание X». Они, вероятно, не будут соответствовать вашей первоначальной задаче X, но они могут дать вам представление о том, какая информация нужна.

1) Устройство представляет собой обычный готовый домашний маршрутизатор с четырьмя портами LAN за внешним коммутатором в eth0 и одним портом WAN в eth1 . Порт WAN подключен к шлюзу вашей локальной сети. Все хосты, которые должны использовать прозрачный прокси, подключены к портам локальной сети, возможно, с дополнительными коммутаторами. Нет других хостов или подключен к портам локальной сети. Другая конечная точка socks находится на стороне WAN.

В этом случае забудьте об уровне 2, используйте правила iptables как описано в man ss-redir , адаптированные только для NAT на eth0 . Маршрутизация отправит проксированный SOCKS-запрос из eth1 . NAT позаботится о том, чтобы любые ответы отправлялись обратно на eth0 на устройство с правильным IP. ARP удостоверится, что MAC для этого IP используется.

2) Вариация вышеупомянутого: некоторые хосты, подключенные к портам локальной сети, должны использовать прокси, а некоторые – нет. В этом случае присмотритесь к аппаратному обеспечению, у него, вероятно, есть микросхема коммутатора, которую можно настроить с помощью sw-conf . Переконфигурируйте его так, чтобы два порта LAN были подключены к eth0 , а два других – к eth2 . Затем действуйте, как указано выше. Подключите хосты к нужным портам локальной сети соответственно.

3) Устройство используется в качестве простого моста в более сложной конфигурации сети, где другая конечная точка SOCKS находится в том же внутреннем сегменте локальной сети, что и хосты, которые должны использовать прокси. В таком случае мне нужно описание сети.

И т.д., стр.

редактировать

Если я правильно прочитал ваш вариант использования, ваша основная проблема заключается в том, что вы должны соединить порт WAN (eth0) с портами LAN (eth1), потому что DHCP-сервер находится за портом WAN, и он должен управлять статическим назначением IP-адресов. через DHCP правильно.

В этом случае я бы настроил мост как «броузер» : все соединяется мостом, кроме пакетов, поступающих в LAN (eth1), которые должны быть проксированы (TCP и в желаемом диапазоне IP-адресов назначения). Эти пакеты будут выходить из внутреннего порта моста br-lan . Там обработка уровня 3 может обрабатывать их, как описано выше. В частности, трекер подключений может отслеживать их по IP-адресу и порту и может отправлять ответы с прокси-сервера socks обратно на правильное устройство.

Не требуется MAC NAT, не требуется отслеживание соединения на основе MAC, которое взаимодействует с L5 и т. Д.

Мне бы хотелось попробовать это с несколькими сетевыми пространствами имен, чтобы я мог дать полный рецепт, но, к сожалению, у меня не будет времени на это сегодня или в ближайшие дни.

Я нашел грязное решение.

Если мы забудем контекст X и углубимся в проблему Y, мы обнаружим следующее.

Идея состоит в том, что, прежде чем перенаправить пакет в локальное приложение, я могу зарегистрировать его и затем проанализировать. Процесс прохождения пакета от eth1 до eth0 к шлюзу по умолчанию выглядит следующим образом:

(CLIENT1_SRC_IP, CLIENT1_SRC_MAC, DEST_IP_ADDR_TO_PROXY, DF_GW_MAC)

Но после прохождения локального приложения оно попадает в это состояние:

((!) CLIENT1_SRC_IP, (!) CLIENT1_SRC_MAC, SS_SERVER) и DF_GW_MAC вот-вот будут ARPed (и потерпят неудачу, поскольку нет соседа SS_SERVER, а также самого шлюза по умолчанию, поэтому пакет не идет никуда).

Поэтому я решил воспользоваться тем, что SS_SERVER является постоянным IP-адресом. DF_GW_MAC из журнала может быть проанализирован и затем использован для добавления статического маршрута arp для IP SS_SERVER.

Несколько деталей для пользователей OpenWRT:

Чтобы получить IP-ржать работает:

opkg update

opkg установить ip-полный

А потом:

IP SIDE добавить 123.123.123.123 dev eth0 lladdr 11: 22: 33: 44: 55: 66

ip route добавить по умолчанию dev eth0

Таким образом, проблема Y решена здесь. X не решен полностью, потому что выше, где я указал (!), Это не так, потому что локальное приложение делает MASQUARADE для вас, используя интерфейс IP, поэтому вы должны вернуть его обратно к исходному IP-адресу, который также грязный. Я не вижу другого варианта на данный момент.