Что бы не повторятся, тема развернута здесь:
http://www.linux.org.ru/forum/admin/9310662

Необходимо описание и готовые скрипты для моего примера.
Интересующихся, прошу писать inixteam@gmail.com

Здравствуйте, уважаемое сообщество!
Начну с главного: Нужен пример гарантированно работающий на CENTOS 6.X

Описание:
Моему шлюзу достались в «наследство» несколько реальных адресов (от разных провайдеров). После заведения «наследства», конфигурация стала выглядеть так:

eth0 - 192.168.1.1/24 (существующий - LAN)
eth1 - 1.1.1.1/24 GW:1.1.1.250 (существующий - default GW)
eth2 - 2.2.2.2/24 GW:2.2.2.250
eth3 - 3.3.3.3/24 GW:3.3.3.250
eth4 - 4.4.4.4/24 GW:4.4.4.250

Прошу поделиться работающим решением/скриптами для CENTOS.
Готов отблагодарить помогающего, по своим скромным возможностям)))

P.S. Просьба не пинать ссылками. Большая часть - просмотрена.

Здравствуйте!

Предыстория:
Мой парк серверов (эдакий ЦОД) охраняет Linux Firewall:
CPU: model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz
RAM: MemTotal: 3922144 kB
Установлена ОС CENTOS 6.X (с последними обновлениями).
ЦОД обслуживает терминальное оборудование. Для лучшего понимания, в качестве аналога «терминального оборудования» приведу банковские терминалы.
Сеть терминалов насчитывает около 300штук. ЦОД рассчитан на нагрузку во много раз большую (10 000 терминалов).
Трафик от терминалов небольшой - транзакционный (до 2кб на транзакцию). Каждый терминал выходит на связь, в среднем, 1 раз в две минуты.
Транспорт - TCP/IP.
Задача шлюза - NAT трафика во внутреннюю сеть.
Часть конфигурации iptables:

-A PREROUTING -d 212.X.Y.Z/32 -p tcp -m tcp --dport 8087 -j DNAT --to-destination 192.168.2.21:8077[br]
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT[br]
-A FORWARD -d 192.168.2.21/32 -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 8077 -j ACCEPT

Ситуация:
Появилась компания расставившая наши терминалы у себя в сети магазинов. Терминалов - около 150шт. Все магазины (и терминалы) работают во внутренней сети партнера организованной на базе VPN. Выход на наш сервер осуществляется централизовано с серверной площадки,используя NAT. Вся коммуникационная часть партнера построена на оборудовании CISCO.
Для трафика от партнера мы организовали отдельный порт (TCP).
По любым вопросам к партнеру, получаем ответ - «у нас CISCO, ищите проблему у себя((((».

Проблема:
С терминалов, установленных у партнера, 20-25% запросов оканчивается неудачно - «Connect timed out».
Исследование показало, что часть пакетов трафика определяются, как INVALID:

-A INPUT -p tcp -m state --state INVALID -s IP_сервера_партнера -j LOG --log-prefix "iptables INVALID-in: " --log-ip-options --log-tcp-options

May 21 17:42:05 gateway kernel: iptables INVALID-in: IN=eth0 OUT= MAC=00:1e:8c:0e:92:4b:00:21:a0:39:99:00:08:00 SRC=IP_сервера_партнера DST=212.X.Y.Z LEN=48 TOS=0x00 PREC=0x00 TTL=121 ID=2659 DF PROTO=TCP SPT=1034 DPT=8077 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020404EC01010402)

Message from syslogd@gateway at May 20 15:57:19 ...
 kernel:nf_ct_tcp: SEQ is under the lower bound (already ACKed data retransmitted) IN= OUT= SRC=IP_сервера_партнера DST=212.X.Y.Z LEN=48 TOS=0x00 PREC=0x00 TTL=121 ID=59687 DF PROTO=TCP SPT=1090 DPT=8077 SEQ=104560592 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020404B001010402)

# sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Прошу помочь советом, где искать источник проблемы?
Если у партнера, то как это ему аргументировать?
(P.S. Готов лично профинансировать решение вопроса, при условии пребывания человека у нас в офисе - г.Киев. Если можете кого-то рекомендовать - буду признателен).

Есть подсеть из реальных ip-адресов, необходимо «пробросить» трафик через шлюз на сервера, которые используют (эти) реальные ip-адреса.

Например:

1. От провайдера к нам заходит кабель (Ethernet) с подсетью 1.1.1.1/25 (доступны адреса 1.1.1.1-1.1.1.126).

- ip-адрес шлюза провайдера: 1.1.1.1

2. Имеем сервер (CENTOS linux) с двумя сетевыми: - eth0 - смотрит на провайдера; - eth1 - смотрит на защищаемую сеть;

3. Имеем 100 серверов в защищаемой сети, каждый из которых ДОЛЖЕН получить реальный ip-адрес.

Как лучше это реализовать?

В голове крутятся такие варианты:

1. Разбить на подсети: на внешний интерфейс минимальная подсеть (с ip-провайдера и ip-моего шлюза), на внутренний подсети для серверов; Плюсы: простая реализация, Минусы: бьется адресное пространство - количество полезных ip-адресов уменьшается;

2. Внешний интерфейс оставляем без ip-адреса, Как-то нужно реализовать проброс всего трафика на внутренний интерфейс (КАК?), на котором поднять вышеописанную сеть и придумать, «что делать с ip-адресом провайдера?» (он-то остался снаружи).

А как поступили бы Вы? Что посоветуете?

Заранее Спасибо!