Вопрос по форвардингу IP

Коллеги, что то я совсем затупил.
Итак, дано:
1. Сервер с двумя сетевыми платами. Одна (192.168.43.6) смотрит в пользовательскую LAN, вторая 192.168.41.6 - служебная, внешняя.
2. Есть нужда добираться до служебной платы сервера из пользовательсткой сети "напрямую", не задействуя дополнительный маршрутизатор (с ним работает).
Решение:
1. На пользовательском компьютере явно добавляю маршрут на этот служебный интерфейс:
[console]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.41.6 192.168.43.6 255.255.255.255 UGH 0 0 0 br0
....
default 192.168.43.1 0.0.0.0 UG 0 0 0 br0
[/console]

2. На сервере включаю форвардинг пакетов:
[console]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
[/console]

3. В iptables тоже прописываем форвардинг.

$IPT -A FORWARD  -d 192.168.41.6 -j ACCEPT
# Включаем NAT 
$IPT -t nat -A POSTROUTING -o $EXT_IF -j MASQUERADE

В результате - соединения с "хостом" 192.168.41.6 нет. Не пингуется даже. На входном интерфейсе сервера (tcpdump) есть только ICMP Echo request'ы c пингующей нужный интерфейс, replay'ев нет. На "служебном" интерфейсе - вообще нет активности при этом.
Если отключить у юзера прямую маршрутизацию - то все (почти) начинает работать. Но мне не нужно гнать трафик через дефолтный 192.168.43.1, мне нужно чтобы сам хост двухплатный пакеты перекинул на свой второй, внешний, интерфейс.
Кстати, если отключить "прямую" маршрутизацию, то "служебные" интерфейсы серверов откликаются. Но трафик на них идет через шлюз. При этом "служебный", внешний интерфейс шлюза так же не пингуется, как и не пинговались интерфейсы серверов при прямой на них маршрутизации.

Подскажите, что я недоделал? Где собака зарылась?

"Cruiser78" написал:

мне нужно чтобы сам хост двухплатный пакеты перекинул на свой второй, внешний, интерфейс.

Абсолютно весь трафик? Если нет, то nat prerouting надо юзать, имхо.

Хотя.. юэер из сети 192.168.43.0 должен напрямую образаться к узлу 192.168.41.6?

Macumazan написал:

Хотя.. юэер из сети 192.168.43.0 должен напрямую образаться к узлу 192.168.41.6?

Да, именно так.
Если схематично нарисовать, то что-то похожее должно быть:

[user < - >] 192/168.43.0/24 < ----- > 192.168.43.6 [ < - > server < - > ] 192.168.41.6

Сейчас стоит в сети 43.0 отдельный шлюз (дефолтный) он и прокидывает трафик на 41-ю сеть. И сервер становится доступен по интерфейсу 41.6. Но, при этом сам шлюз тоже не хочет показывать свой внешний интерфейс во внутренюю сеть... То есть - форвардит все кроме своего локального интерфейса. Причем, даже если включить в iptables логгирование форвардинга - так пусто там. Нету форвардинга на внешний локальный интерфейс, ничего в эту цепочку не попадает...
Понять где пакеты теряются - не могу...

Cruiser78 написал:

Коллеги, что то я совсем затупил.
Итак, дано:
1. Сервер с двумя сетевыми платами. Одна (192.168.43.6) смотрит в пользовательскую LAN, вторая 192.168.41.6 - служебная, внешняя.
2. Есть нужда добираться до служебной платы сервера из пользовательсткой сети "напрямую", не задействуя дополнительный маршрутизатор (с ним работает).
Решение:
1. На пользовательском компьютере явно добавляю маршрут на этот служебный интерфейс:
[console]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.41.6 192.168.43.6 255.255.255.255 UGH 0 0 0 br0
....
default 192.168.43.1 0.0.0.0 UG 0 0 0 br0
[/console]

2. На сервере включаю форвардинг пакетов:
[console]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
[/console]

3. В iptables тоже прописываем форвардинг.

text

$IPT -A FORWARD  -d 192.168.41.6 -j ACCEPT
# Включаем NAT 
$IPT -t nat -A POSTROUTING -o $EXT_IF -j MASQUERADE

В результате - соединения с "хостом" 192.168.41.6 нет. Не пингуется даже. На входном интерфейсе сервера (tcpdump) есть только ICMP Echo request'ы c пингующей нужный интерфейс, replay'ев нет. На "служебном" интерфейсе - вообще нет активности при этом.
Если отключить у юзера прямую маршрутизацию - то все (почти) начинает работать. Но мне не нужно гнать трафик через дефолтный 192.168.43.1, мне нужно чтобы сам хост двухплатный пакеты перекинул на свой второй, внешний, интерфейс.
Кстати, если отключить "прямую" маршрутизацию, то "служебные" интерфейсы серверов откликаются. Но трафик на них идет через шлюз. При этом "служебный", внешний интерфейс шлюза так же не пингуется, как и не пинговались интерфейсы серверов при прямой на них маршрутизации.

Подскажите, что я недоделал? Где собака зарылась?

FORWARD в обе стороны прописывать надо.
А вот маскардить в эту сеть не надо.

CyberDaemon написал:

FORWARD в обе стороны прописывать надо.
А вот маскардить в эту сеть не надо.

Да по разному я делал. И в обе, и в одну. И с маскарадингом и без.
Еще раз уточню. Не идет трафик только на локальный "внешний" интерфейс сервера. Настолько не идет, что в правила FORWARD'а в iptables ничего не попадает (проверено включением логгирования этой цепочки, там полное молчание). Если я настрою роутинг на клиенте не на конкретный хост (этот внешний интерфейс), а на всю ту 41-ю сетку, то мне (из локальной, 43-й, сети) будут доступны почти все адреса той 41-й сети (и весь форвардинг зафиксируется в логе). Все работает за исключением этого локального адреса сервера. Который мне и нужен.
То есть полное ощущение, что пакеты, нацеленные на "внешний" интерфейс сервера, попав на его внутренний интерфейс, там и помирают. Сразу после PREROUTING'а в iptables. Они не попадают ни в FORWARD, ни в INPUT.

Кажется, надо копать сюда. Ключевая фраза "Основным применением является возможность имитации присутствия узла из одного сегмента сети в другом".

Macumazan написал:

Кажется, надо копать сюда. Ключевая фраза "Основным применением является возможность имитации присутствия узла из одного сегмента сети в другом".

Нет, это не то совершенно. Я знаю про ARP-proxy и умею его применять. Он нужен для иных целей. ( хороший пример: http://xgu.ru/wiki/Proxy_ARP). Или для проброса пакетов с виртуального tap-интерфейса на физический если нужно иметь одну IP-сеть и на физическом и за виртуальным интерфейсом (я это делал...).
А здесь - у меня на обоих интерфейсах сидят 24-е сетки, непересекающиеся друг с другом. Причем доступ из одной сети в другую есть по правилам маршрутизации и форвардинга. В отказе стоит только один интерфейс. А если я нарисую на него маршрут через иной "шлюз" - он сразу откликнется.

Cruiser78 написал:

Подскажите, что я недоделал? Где собака зарылась?

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

write2net написал:

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

Не попадает. У меня простое правило - писать опции протоколирования самыми первыми правилами. А потом - всё остальное.
Так вот - я пытаюсь достучаться до интерфейса сервера с _администратвной_ машины. И по дефолту для такой машины сервер принимает весь трафик без какого либо дропанья. То есть:
Первая группа правил - настройка лога
Вторая - начинается с разрешений админской машине.
То есть - примерно так:

Так что, никакого дропа на админскую машину нету. Но пакеты я смог зафиксировать только на прероутинге. А потом - они пропадают... В цепочку INPUT они не попадают. Как и в цепочку FORWARD.

write2net написал:

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

Не попадает. У меня простое правило - писать опции протоколирования самыми первыми правилами. А потом - всё остальное.
Так вот - я пытаюсь достучаться до интерфейса сервера с _администратвной_ машины. И по дефолту для такой машины сервер принимает весь трафик без какого либо дропанья. То есть:
Первая группа правил - настройка лога
Вторая - начинается с разрешений админской машине.
То есть - примерно так:

Так что, никакого дропа на админскую машину нету. Но пакеты я смог зафиксировать только на прероутинге. А потом - они пропадают... В цепочку INPUT они не попадают. Как и в цепочку FORWARD.

Попробовал так

[user < - >] 192.168.43.5/24 < ----- > 192.168.43.6 [ < - > server  < - > ] 192.168.41.6

На юзере

# ip r a 192.168.41.6 via 192.168.43.6

На сервере

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

user~# ping -c2 192.168.41.6
PING 192.168.41.6 (192.168.41.6) 56(84) bytes of data.
64 bytes from 192.168.41.6: icmp_req=1 ttl=64 time=0.320 ms
64 bytes from 192.168.41.6: icmp_req=2 ttl=64 time=0.317 ms

Наверное, itpables где-то что-то фильтрует.

Macumazan написал:

На сервере

text

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

а у меня даже без форвардинга работает.

Cruiser78 написал:

Так что, никакого дропа на админскую машину нету. Но пакеты я смог зафиксировать только на прероутинге. А потом - они пропадают... В цепочку INPUT они не попадают. Как и в цепочку FORWARD.

посмотрите, пожалуйста, что будет, если отключить форвардинг

write2net написал:

посмотрите, пожалуйста, что будет, если отключить форвардинг

Это только в понедельник уже (админская машина выключена физически). Из дому я только могу сказать следующее про сервер:

[console]# sysctl -p | grep ipv4
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 7
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.tcp_rmem = 8192 87830 16777216
net.ipv4.tcp_orphan_retries = 1
[/console]

А вот параметр net.ipv4.conf.all.rp_filter = 1 у меня не определен. Точнее - дефолтный какой-то.
=====================
И вообще - спинным мозгом чую, что rp_filter в моем случае должен быть сброшен. Ибо "The rp_filter can reject incoming packets if their source address doesn't match the network interface that they're arriving on, which helps to prevent IP spoofing". Если я пробрасываю пакеты в 41-ю сеть через третий шлюз, то там включается NAT и пакеты на целевой хост приходят уже отнатченные. А здесь - нат (как и форвардинг) не нужен, ибо интерфейс локален. Вот rp_filter и срабатывает, режет такие пакеты.
В понедельник проверю догадку.