Linux ответ с того же интерфейса

Ответ на тот же интерфейс, что и входящий?

У меня есть система с двумя интерфейсами. Оба интерфейса подключены к Интернету. Один из них задан как маршрут по умолчанию; побочным эффектом этого является то, что если пакет входит в интерфейс не по умолчанию, ответ отправляется обратно через интерфейс маршрута по умолчанию. Есть ли способ использовать iptables (или что-то еще) для отслеживания соединения и отправки ответа через интерфейс, из которого он пришел?

5 ответов

Вышеупомянутая не требует маркировки пакетов с помощью ipfilter. Он работает, потому что исходящие (ответные) пакеты будут иметь IP-адрес, который изначально использовался для подключения к второму интерфейсу в качестве исходного (исходящего) адреса исходящего пакета.

Следующие команды создают альтернативную таблицу маршрутизации через —- +: = 0 =: + —- для пакетов, у которых есть метка 1 (кроме пакетов на localhost). Команда —- +: = 1 =: + —- находится в iproute2 suite (Ubuntu: iproute Установить iproute http://bit.ly/software-small , iproute-doc Установить iproute-doc http :. //bit.ly/software-small )

Другая половина задания — это распознавание пакетов, которые должны получить отметку 1; затем используйте —- +: = 3 =: + —- для этих пакетов, чтобы они маршрутизировались через таблицу маршрутизации 1. Я думаю, что это должно сделать следующее (замените 1.2.3.4 на адрес интерфейса не по умолчанию-маршрут):

Я не уверен, достаточно ли этого, возможно, потребуется еще одно правило для входящих пакетов, чтобы сообщить модулю conntrack их отслеживание.

У меня были проблемы с локально сгенерированными пакетами с решением, предложенным Питером, я обнаружил, что следующие исправления:

Я предполагаю, что вы используете Linux и, кроме того, используете дистрибутив RedHat /CentOS. Другие Unix и дистрибутивы потребуют подобных действий — но детали будут разными.

Начните с тестирования (обратите внимание, что это очень похоже на ответ @ Peter. Я предполагаю следующее:

• eno0 isp0 и имеет общий шлюз по умолчанию
• eno1 isp1 и имеет IP /диапазон 192.168.1.2/24 со шлюзом 192.168.1.1

Брандмауэр никак не участвует. Ответные пакеты всегда отправлялись с правильного IP-адреса, но ранее отправлялись через неправильный интерфейс. Теперь эти пакеты с правильного IP будут отправлены через правильный интерфейс.

Предполагая, что это было выполнено, вы можете теперь изменить правило и маршрут. Это зависит от того, какую версию Unix вы используете. Как и прежде, я предполагаю дистрибутив Linux на основе RH /CentOS.

Проверьте, что изменение сети является постоянным:

Если это не сработало, в более поздних версиях RH /CentOS вам также нужно выполнить один из двух вариантов:

• Не используйте по умолчанию NetworkManager.service ; Вместо этого используйте network.service . Я не изучил точные шаги, необходимые для этого. Я бы предположил, что он включает стандартные команды chkconfig или systemctl для включения /отключения служб.
• Установить пакет правил NetworkManager-dispatcher-routing-rules

Лично я предпочитаю устанавливать пакет правил, так как это более простой подход:

Источник

Отправка ответа по тому же интерфейсу откуда пришёл запрос

• Debian Linux;
• интерфейс bond0, раздающий интернеты;
• интерфейс eth1, смотрящий в локалку;
• интерфейс tun1 клиента OpenVPN, раздающий доступ к некоторым ресурсам в интернетах с помощью опции -j MASQUERADE iptables;
• параметры маршрутизации с помощью набора опций route в конфиге клиента OpenVPN, описывающего сети с указанием IP и маски этих некоторых ресурсов, доступ к которым должен осуществляться через интерфейс tun1.

Что нужно: в случае поступления запросов через интерфейс bond0 (не через OpenVPN туннель) с маршрутизируемых сетей, указанных в конфиге клиента OpenVPN, отправлять ответы через тот же интерфейс bond0, при этом сохранив возможность доступа к этим ресурсам при помощи туннеля OpenVPN. Каким способом это лучше всего реализовать?

Маркировка соединений (CONNMARK), маркировка пакетов по маркеру соединения, выбор таблицы маршрутизации по маркеру пакета.

Спасибо за ссылку. Прописал таблицы T1 и T2 в /etc/iproute2/rt_tables, наговнокодил на скорую руку скрипт:

Спасибо за наводку, настроил маркировку пакетов как описано по ссылке ибо выпадение раздающего интернеты интерфейса bond0 из общей таблицы маршрутизации после применения предыдущего способа в моём случае было нежелательным.

Автоматические утилиты для настройки multuhoming:

Источник

Linux multihomed — отправка ответов на входящие пакеты по тому же интерфейсу, по какому пришли

Тем, кто сломал мозг в попытках отправить ответный пакет по тому же интерфейсу, откуда пришёл запрос, посвящается.

Думаю, на сегодня достаточно стандартная ситуация, когда на входе в локальную сеть стоит Linux-роутер, к которому подключены несколько внешних линий от разных провайдеров.
Как управляться с такой конфигурацией, писали много, например вот здесь.
Но когда берёшь реальный линукс и начинаешь строить, немедленно наступаешь на грабли.
Повторять все шаги из статьи по ссылке не буду, опишу только участвующие в «граблях».
А именно (далее все примеры в предположении, что основной внешний интерфейс eth0, а запасной — ppp0):
Чтобы ответы на пакеты уходили по тому же интерфейсу, по какому пришёл запрос, везде советуют включать маркировку пакетов

iptables -t mangle -I INPUT -i ppp0 -j CONNMARK —set-mark 0x1
iptables -t mangle -I OUTPUT -j CONNMARK —restore-mark

и далее назначать таблицу маршрутизации (с именем modem в файле /etc/iproute2/rt_tables) согласно меткам:

ip route add default dev ppp0 table modem
ip rule add fwmark 0x1 lookup modem

И вроде бы всё правильно, но — НЕ РАБОТАЕТ! Проверяешь с внешнего хоста пингом на адрес внешнего интерфейса — просто не увеличиваются счётчики на правиле iptables в таблице mangle, цепочке INPUT — то есть пакет туда НЕ ПОПАДАЕТ.
Начинаешь экспериментировать — выясняется, что в цепочку PREROUTING таблицы mangle пакеты попадают, а в цепочку INPUT уже нет. Продолжение экспериментов показывает, что и в цепочку PREROUTING таблицы nat пакеты попадают, а ни в INPUT ни в FORWARD — нет, значит согласно схеме прохождения цепочек пакеты теряются на первом узле «routing decision», где принимается решение куда отправить пакет — в FORWARD или в INPUT.
Так вот, многочасовое разбирательство, включая попытку влезть в исходники iptables и iproute, привели к поразительно простому открытию, которое почему-то почти нигде не упоминается: надо на входящих интерфейсах выключить rp_filter:

Источник

Ответить на тот же интерфейс, что и входящий?

У меня есть система с двумя интерфейсами. Оба интерфейса подключены к Интернету. Один из них установлен как маршрут по умолчанию; побочным эффектом этого является то, что если пакет поступает на интерфейс не-default-route, ответ отправляется обратно через интерфейс маршрута по умолчанию. Есть ли способ использовать iptables (или что-то еще) для отслеживания соединения и отправки ответа обратно через интерфейс, из которого оно получено?

Выше не требуется маркировки пакетов с помощью ipfilter. Это работает, потому что исходящие (ответные) пакеты будут иметь IP-адрес, который первоначально использовался для подключения ко 2-му интерфейсу, в качестве адреса источника (от) в исходящем пакете.

Следующие команды создают альтернативную таблицу маршрутизации через eth1 для пакетов, которые имеют метку 1 (кроме пакетов для localhost). Команда ip из пакета iproute2 (Ubuntu: iproute Установить iproute http://bit.ly/software-small , iproute-doc Установить iproute-doc http://bit.ly/software-small ).

Другая половина задания распознает пакеты, которые должны получить оценку 1; затем используйте iptables -t mangle -A OUTPUT … -j MARK —set-mark 1 эти пакеты для маршрутизации через таблицу маршрутизации 1. Я думаю, что следующее должно сделать это (замените 1.2.3.4 адресом интерфейса не-default-route):

Я не уверен, что этого достаточно, возможно, для входящих пакетов требуется другое правило, чтобы модуль conntrack мог их отслеживать.

У меня были проблемы с локально сгенерированными пакетами с помощью решения, предложенного Питером. Я обнаружил, что следующее исправляет это:

ПРИМЕЧАНИЕ. Вы можете столкнуться с проблемами синтаксиса в 4-й строке выше. В таких случаях синтаксис для 4-й команды может быть следующим:

Я предполагаю, что вы используете Linux и, кроме того, что вы используете дистрибутив RedHat / CentOS. Другие Unix и дистрибутивы потребуют аналогичных шагов — но детали будут другими.

Начните с тестирования (обратите внимание, что это очень похоже на ответ @ Peter. Я предполагаю следующее:

• eno0 isp0 и имеет общий шлюз по умолчанию
• eno1 isp1 и имеет IP / диапазон 192.168.1.2/24 со шлюзом 192.168.1.1

Брандмауэр никак не задействован. Ответные пакеты всегда отправлялись с правильного IP-адреса, но ранее отправлялись через неправильный интерфейс. Теперь эти пакеты с правильного IP будут отправлены через правильный интерфейс.

Предполагая, что вышесказанное сработало, теперь вы можете сделать правило и изменения маршрута постоянными. Это зависит от того, какую версию Unix вы используете. Как и прежде, я предполагаю, что дистрибутив Linux основан на RH / CentOS.

Проверьте, что изменение сети является постоянным:

Если это не сработало, в более поздних версиях RH / CentOS вам также нужно выбрать один из двух вариантов:

• Не используйте по умолчанию NetworkManager.service ; Вместо этого используйте network.service . Я не исследовал точные шаги, необходимые для этого. Я полагаю, что для включения / выключения служб используются стандартные команды chkconfig или systemctl .
• Установите пакет NetworkManager-dispatcher-routing-rules

Лично я предпочитаю устанавливать пакет правил, так как это более простой и поддерживаемый подход:

Источник

Linux. Ответ через другой интерфейс

Автор: tkapluk,
2015-02-25 11:27:38 в Wi-Fi

Рекомендованные сообщения

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Войти

Уже зарегистрированы? Войдите здесь.

Сейчас на странице 0 пользователей

Нет пользователей, просматривающих эту страницу.

Похожие публикации

В крупную хостинг-компанию требуется сотрудник службы технической поддержки.

Обязанности:
Отвечать на вопросы клиентов (работа с панелью управления, настройка POP3, SMTP, FTP, другие технические вопросы) по телефону, эл. почте, решать мелкие проблемы (неверно заполненные данные и настройки в контрольной панели, проблемы с доступом и т. п.), не сложные вопросы касающиеся администрирования, подключение IPKVM, перезагрузка серверов.

Требования:
Умение работать в Интернет с основными клиентами (браузеры: IE и Mozilla, почтовые клиенты: The bat, outlook, FTP-клиенты: IE, Far, Cute FTP; Базовые знания PHP, MySQL; Уметь читать и понимать логи Apache, Nginx, Exim Приветствуется опыт работы в Web-Дизайне, работа с Joomla, WordPress Навыки работы в командной строке UNIX; Желателен опыт работы с VestaCP, ISPmanager Коммуникабельность, терпение, эмоциональная уравновешенность, способность к обучению.
Условия:
Официальное трудоустройство 24 дня отпуска Обеды за счет компании Сменный график. Смена сутки, потом три дня выходных. Оплачиваемый больничный Возможность повышения до дежурного администратора. Работа в дата-центре (в случае локдаунов предусмотрена развозка сотрудников)
Работа в дата-центре это возможность получить опыт работы с различными технологиями (apache, nginx, mysql, zabbix, wordpress, joomla, dns…), а так же опыт работы с железной частью серверов.
Если нету опыта работы с Unix, резюме просьба не присылать.

Резюме присылайте на hr@freehost.com.ua

Обратите внимание на закомменченную порцию с flow offload, с ней при 12G нат трафика неаблюдаются довольно сушественные потери на входе интерфейса:

Если закомментить часть отвечающую за flow offload, то нагрузка на процессот немного вырастает но потери исчезают аж пока трафика не станет 19G при загрузке CPU 85%. Да и то при такой нагрузке потери менее значительные:

Функция flow offload хороша и позволяет сэкономить на нагрузке CPU, но почему оно так сильно влияет на потери трафика или нужно настроить что либо еще?

Имеем коммутатор BDCOM(tm) S5612 Software, Version 2.2.0B Build 37303

пытались подключить по лагу с линукс машиной, на которой настроен бондинг.
До этого машина работала на стенде по двум 10Г портам с коммутатором FORCE10 и дилинк. Было все ок.
Нужно было переключить машину в этот бдком.
Настройки на бдкоме:

enable
config
interface Port-aggregator6
description 20G_LACP
no spanning-tree
switchport trunk vlan-allowed 2,1000-1999
switchport mode trunk
exit
interface tgigaEthernet 1/11
no spanning-tree
aggregator-group 6 mode lacp
switchport trunk vlan-allowed 2,1000-1999
switchport mode trunk
exit
interface tgigaEthernet 1/10
no spanning-tree
aggregator-group 6 mode lacp
switchport trunk vlan-allowed 2,1000-1999
switchport mode trunk
exit

!
aggregator-group load-balance both-ip
!

Переключили физически в порты бдкома — порты поднимаются, а lacp down — не поднимается.
tg1/10 with_eth1 up Trunk(1) full 10000Mb 10Giga-FX
tg1/11 with_eth2 up Trunk(1) full 10000Mb 10Giga-FX
p6 20G_LACP down Trunk(1)

Прошивка была 2.2.0B 37303
обновляли -> 2.2.0C 42666 -> 2.2.0C 50891 -> и на последнюю 2.2.0C 69953

Добавление вилана 1 помогло — заработало:
interface Port-aggregator6
switchport trunk vlan-allowed add 1

Хотя между коммутаторов работает без 1 (дефаулт) влана.
Может кому пригодиться, намучались немного

# cat interfaces
auto lo
iface lo inet loopback
auto eth1
iface eth1 inet manual
bond-master bond0
up ifconfig $IFACE mtu 9000
post-down ifconfig $IFACE down
auto eth2
iface eth2 inet manual
bond-master bond0
up ifconfig $IFACE mtu 9000
post-down ifconfig $IFACE down
auto bond0
iface bond0 inet manual
bond-mode 802.3ad
bond-miimon 100
bond-downdelay 200
bond-updelay 200
bond-lacp-rate 1
bond-xmit-hash-policy 1
bond-slaves eth1 eth2
up ifconfig $IFACE mtu 9000
auto bond0.2
iface bond0.2 inet static
address 192.168.200.200
netmask 255.255.0.0
gateway 192.168.200.120
dns-nameservers 8.8.8.8
vlan_raw_device bond0

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)

Всем привет!
Подскажите плиз: Как очистить содержимое всех файлов в каталоге на системе linux без удаления самих файлов?
Может скрипт какой есть для примера?

Источник