проброс реальных ip через шлюз

nat не?

поподробнее и с примером, для моих параметров можно?

можно nat, можно proxy arp, можно попросить провайдера выделить сеть /30 и на твою шлюз уже пророутить твою /25

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

по нату, примерно так

iptables -I PREROUTING -t nat -i eth0 -d 1.1.1.2 -j DNAT --to-destination 192.168.1.2
iptables -I POSTROUTING -t nat -i eth1 -s 192.168.1.2 -j SNAT --to-source 1.1.1.2
[code/]

где 192.168.1.2 соответственно 1 из твоих серверов, ну и так со всеми

ах да, на lo еще надо повесить 1.1.1.2

ip a a 1.1.1.2 dev lo

а то провайдер никогда и не пошлет пакет с на dst адресом 1.1.1.2 на твой шлюз, ибо не будет знать mac.

или можно его не на lo, а прямо на eth0 повесить, на eth0 должен быть адрес из подсети 1.1.1.0/25, может быть и не 1

предложенное решение (SNAT) не удовлетворяет условию: внутренние сервера ДОЛЖНЫ иметь реальные ip-адреса.

реализовать проброс всего трафика на внутренний интерфейс

bridge-utils

сформулирую еще точнее: внутренние сервера используют в конфигурации своих сетевых интерфейсов реальные ip-адреса

самый кошерный вариант — взять сетку /30 для линка, а эту большую попросить провайдера зароутить через этот линк. так часто делают

ну тогда либо прокси арп, либо просить провайдера пророутить на тебя эту сеть.

по прокси arp, включаешь его на двух интерфейсах

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp

ip a a 1.1.1.2/32 dev lo
ip a a 0.0.0.0/0 dev eth0
ip l set up dev eth0
ip r a 1.1.1.1/32 dev eth0
ip r a default via 1.1.1.1

ip a a 0.0.0.0/32 dev eth1
ip l set up dev eth1
ip r a 1.1.1.3 dev eth1

на сервер вешаешь ip 1.1.1.3/25, шлюз 1.1.1.2

но здесь оно того не стоит, проски арп и ip unnumbered обычно используются чтобы сэкономить адресов когда есть куча интерфейсов, и не хочется бить сеть на /30, теряя на каждой машине 3 адреса впустую.

спасибо за советы! ...читаю мануалы.

А почему бы не сделать через VLAN просто..? Оно разве не для этого придумывалось?

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

Либо, как уже посоветовали, собрать мост, либо упросить провайдера на транзитную сетку (хинт: она не обязательно должна быть на «белых» IP, т.е. 192.168.37.28/30 вполне прокатит). Остальные способы какие-то... в гамаке и стоя...

Эм... Завести все внешние адреса в VLAN (провод воткнуть от провайдера в untaget этого VLAN), и пробросить этот VLAN на нужные сетевые адаптеры внутри компании? - ИМХО то, что вы тут предлагаете полная идиотия...

Ну начнем с того, что в старт посте нет ничего про управляемые свичи. На этом, пожалуй, и закончим=)

А так можно и без вланов вокнуть провайдера и все сервера в 1 свич(даже неуправляемый).

http://xgu.ru/wiki/Linux_Bridge,мне кажется мост или точнее Linux Bridge самое то + можно трафик фильтровать

Что делает мост/коммутатор?
Мост прозрачно пересылает трафик между несколькими сетевыми интерфейсами. На простом языке это означает, что коммутатор соединяет два или более интерфейсов Ethernet между собой, для того чтобы получилась большая Ethernet-сеть.

Так а в чем проблема-то?
Провайдер должен направлять внешний трафик к твоим серверам через его, провайдера, шлюз. То есть УТВР и я не понимаю, чего тебе не хватает.

Изначально склонялся к Linux Bridge - это наиболее простое решение (лично для меня). Что заставляет посмотреть на другие варианты? - накладные расходы на CPU.

swelf, спасибо за наводку о Proxy ARP

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp

После прочтения Proxy ARP на xgu нашел ссылку на решение идентичного вопроса средствами Proxy ARP. Статья, правда, старая, но, думаю, что с тех пор в стеке ничего не изменилось.

ИТОГО: буду пробовать Proxy ARP, а если будут проблемы, то Linux Bridge.

Сообществу большое спасибо за помощь!!!

P.S. Положа руку на сердце, признаюсь, что с VLAN не работал вообще. И оценить красоту предложенного решения не могу. Если вас не затруднит, напишите возможный конфиг для моей задачи. P.S.S. Не могу не процитировать строки из прочитанной статьи (почему-то зацепило) :-)

Первая проблема, с которой я столкнулся, состояла в следующем - программа arp(8), входившая в мой дистрибутив Slackware 3.1, была настолько стара(1994 года выпуска!!!), что вообще не могла работать с кодом arp в ядре

И то верно! Вполне себе можно и без VLAN даже, короче топик стартер страдает хернёй вот чего я думаю. :)

И опять же: если нет свитчей, можно попробовать на программном уровне настроить VLAN на шлюзе... Но это всё изврат.

Тебе необходимо чтобы весь провайдерский трафик проходил через eth0? Если да, то проси у провайдера сеть /30, через которую он тебе промаршрутизирует твою /25, если нет, то воткни провайдерский провод в свич и все. Мосты, прокси арп - это все изврат, разве что из академического интереса в данном случае это можно сделать. С мостом, кстати, проще, чем с прокси арп и ip unnumbered.

прокси арп не грузит систему, так как мост.

Я не пойму - вас провайдер на месте четвертует, если вы у него транзитную сеть попросите? Зачем городить (раньше времени) огород?