У нас есть мост, настроенный на Ubuntu, чтобы связать нашу локальную сеть с нашим шлюзом, который находится в той же подсети. Нам это нужно, чтобы иметь возможность контролировать трафик, и в настоящее время мы не в состоянии изменить подсети, поэтому мы не можем просто маршрутизировать его вместо этого.
Шлюз управляется нашим интернет-провайдером, который предоставляет MPLS для различных других подсетей /24 в пределах 192.168.0.0/16.
Текущая конфигурация выглядит следующим образом:
192.168.10.1 (gw) <-> eth0 <-> br0 (192.168.10.3) <-> eth1 <-> локальная сеть (192.168.10.0/24)
br0 Link encap:Ethernet HWaddr ..
inet addr:192.168.10.3 Bcast:192.168.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...
eth0 Link encap:Ethernet HWaddr ..
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr ..
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Это работает хорошо и не вызывает никаких проблем.
У нас также есть Tinc VPN для инфраструктуры нашего центра обработки данных на том же сервере (192.168.10.3), который не является частью моста, т. е.:
tincvpn Link encap:Ethernet HWaddr ..
inet addr:192.168.10.3 Bcast:192.168.255.255 Mask:255.255.0.0
...
Мы хотели бы переопределить маршрутизацию пакетов, проходящих через мост из локальной сети для определенных пунктов назначения (например, 192.168.5.0/24), чтобы они проходили через tinc. Например: 192.168.10.x в локальной сети к 192.168.5.x должны проходить через tinc, а не на шлюз.
Мы хотели бы, чтобы это работало на всех машинах в локальной сети без необходимости какой-либо настройки, но на данный момент нашли обходной путь, который заключается в добавлении следующего статического маршрута к каждому ПК/серверу в локальной сети:
route add -net 192.168.5.0/24 via 192.168.10.3 dev eth0
Для работы статического маршрута нам также пришлось включить proxy_arp для всех интерфейсов на 192.168.10.3.
Мы попробовали следующую конфигурацию, но она не сработала:
ip rule add fwmark 20 lookup 20
ip route add 192.168.0.0/16 dev tincvpn table 20
ebtables -t broute -I BROUTING -i eth1 -p ipv4 --ip-dst 192.168.5.0/24 -j REDIRECT --redirect-target DROP
iptables -t mangle -I PREROUTING -i eth1 -d 192.168.5.0/24 -j MARK --set-mark 20
При такой настройке пакеты приходили к правилу mangle и маркировались, но не направлялись на интерфейс tincvpn.
Мы понимали, что нам нужно выбросить пакеты из моста с помощью ebtables, а затем использовать маршрутизацию на основе политик, чтобы пакеты проходили через tinc. Правильно ли я понимаю?
Если у кого-то есть идеи, почему это не сработало, будем признательны.
Большое спасибо,
Том