iptables - Быть нацеленными направлять пакет к определенному интерфейсу?
В первую очередь, я узнал, что Телекоммуникационное оборудование (более точно FlexPlex Bosch Marconi) также воздействует на 48 В. Я также получаю подсказку от дружественной компании, что Eltek-Valere производит 48-вольтовый выпрямитель в разнообразной версии.
В конечном счете я заставлю 48-вольтовый 3,2 кВт MiniPack от Eltek-Valere заменять обеспеченный PSU от Dt. Telekom.
Ссылка на продукт: http://www.eltek-valere.de/en/products/systems/embedded-power/
за ваше здоровье Lairsdragon
Я решил это. Проблема заключалась в правилах маршрутизации в таблице 11. Таблица 11 была поражена , но правила маршрутизации сделали ее неработоспособной. Этот сценарий - то, что я сейчас использую, и, похоже, он работает хорошо (хотя, очевидно, он специфичен для моей установки). Кроме того, я создал новую таблицу 21, посвященную основному каналу связи (eth1).
# Add relevant iptables entries.
iptables -t mangle -A OUTPUT -m owner --uid-owner 1002 -j MARK --set-mark 11
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
# Flush ALL THE THINGS.
ip route flush table main
ip route flush table 11
ip route flush table 21
ip rule flush
# Restore the basic rules and add our own.
ip rule add lookup default priority 32767
ip rule add lookup main priority 32766
ip rule add fwmark 11 priority 1000 table 11
# This next rule basically sends all other traffic down eth1.
ip rule add priority 2000 table 21
# Restore the main table. I flushed it because OpenVPN does weird things to it.
ip route add 127.0.0.0/8 via 127.0.0.1 dev lo
ip route add 192.168.1.0/24 dev eth1 src 192.168.1.73
ip route add default via 192.168.1.254
# Set up table 21. This sends all traffic to eth1.
ip route add 192.168.1.0/24 dev eth1 table 21
ip route add default via 192.168.1.254 dev eth1 table 21
# Set up table 11. I honestly don't know why 'default' won't work, or
# why the second line here is needed. But it works this way.
ip route add 10.32.0.49/32 dev tun0 table 11
ip route add 10.32.0.1 via 10.32.0.50 dev tun0 table 11
ip route add 0.0.0.0/1 via 10.32.0.50 dev tun0 table 11
ip route flush cache
## MeanderingCode edit (потому что я пока не могу комментировать)
Спасибо за этот ответ! Похоже, это может стать беспорядочным, так как вам придется поддерживать здесь информацию о маршруте (возможно, дублирование или нарушение других вещей, которые могут потребовать установки маршрутов.
Вы можете столкнуться с "странными вещами" в вашей таблице маршрутизации из OpenVPN поскольку сервер настроен на «проталкивание» маршрутов, что позволяет маршрутизировать весь трафик через сетевой интерфейс VPN, а не через «голый» Интернет. Или ваша конфигурация OpenVPN или любой другой сценарий / приложение, которое ее настраивает, устанавливает маршруты.
В первом случае вы можете отредактировать конфигурацию OpenVPN и вставить строку, содержащую "route-nopull"
В последнем случае проверьте конфигурацию OpenVPN или любой оболочки (network-manager-openvpn, например, во многих текущих настольных дистрибутивах Linux)
В любом случае устранение конфигурации маршрутизации, в которой она устанавливается, чище и безопаснее, чем очистка таблицы, в зависимости от того, когда вы запускаете этот сценарий и что еще делает ваша система.Ура!
Я думаю, вы хотите:
/sbin/ip route add default via 10.32.0.49 dev tun0 table 11
/sbin/ip rule add priority 10000 fwmark 11 table 11
http: // lartc .org / howto / lartc.netfilter.html
Но я не проверял вышеизложенное.
Недавно я столкнулся с похожей проблемой, хотя и немного другой. Я хотел направить только TCP-порт 25 (SMTP) через интерфейс Tap0 OpenVPN, а весь остальной трафик (даже для того же хоста) маршрутизировать через интерфейс по умолчанию.
Для этого мне пришлось маркировать пакеты и устанавливать правила для их обработки. Сначала добавьте правило, которое делает пакеты маршрутизации ядра помеченными с 2 через таблицу 3 (объяснено позже):
ip rule add fwmark 2 table 3
Вы могли бы добавить символическое имя в / etc / iproute2 / rt_tables , но я не стал это делать. Число 2 и 3 выбираются случайным образом. Фактически, они могут быть такими же, но для ясности я не делал этого в этом примере (хотя я делаю это в своей собственной настройке).
Добавьте маршрут для перенаправления трафика через другой интерфейс, предполагая, что используется шлюз 10.0.0.1 :
ip route add default via 10.0.0.1 table 3
Очень важно! Очистите кеш маршрутизации, иначе вы не получите ответ и несколько часов просидите, затаив руки в волосы:
ip route flush cache
Теперь установите правило брандмауэра для маркировки назначенных пакетов:
iptables -t mangle -A OUTPUT -p tcp --dport 465 -j MARK --set-mark 2
Вышеупомянутое правило применяется, только если пакеты приходят с локальной машины. См. http://inai.de/images/nf-packet-flow.png . Отрегулируйте его по своим требованиям. Например, если вы хотите направлять исходящий HTTP-трафик только через интерфейс tap0 , измените 465 на 80.
Чтобы пакеты не отправлялись через tap0 , получая ваш адрес LAN в качестве источника IP, используйте следующее правило, чтобы изменить его на адрес вашего интерфейса (предполагая 10.0.0.2 в качестве IP-адреса для интерфейса tap0 ):
iptables -t nat -A POSTROUTING -o tap0 -j SNAT --to-source 10.0.0.2
Наконец, ослабить проверку источника обратного пути. Некоторые предлагают вам установить его на 0 , но 2 кажется лучшим выбором согласно https://www.kernel.org/doc/Documentation/networking/ip- sysctl.txt . Если вы пропустите это, вы получите пакеты (это можно подтвердить с помощью tcpdump -i tap0 -n ), но пакеты не будут приняты. Команда для изменения настройки, чтобы пакеты принимались:
sysctl -w net.ipv4.conf.tap0.rp_filter=2
Это можно сделать без команды iptables. Выполнить простую команду ip
Для uid 1002:
ip rule add uidrange 1002-1002 table 502
Добавить маршрут по умолчанию для таблицы 502 через интерфейс, который вы хотите сказать
eth0 ip rule add default via a.b.c.d dev eth0