Здравствуйте!
Предыстория:
Мой парк серверов (эдакий ЦОД) охраняет 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-optionsMay 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. Готов лично профинансировать решение вопроса, при условии пребывания человека у нас в офисе - г.Киев. Если можете кого-то рекомендовать - буду признателен).
