Как переключить трафик https с одного веб-сервера на другой.Выпуск IPTABLES - PullRequest
0 голосов
/ 28 марта 2012

Вот моя конфигурация. У меня есть лак, прослушивающий порт 80 и 2 веб-сервера (tomcat) через порт 8080 и 8081 и https 4430 и 4431.

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

Мне нужно сделать то же самое для HTTP-трафика. Это небольшой объем трафика, и мне не нужно кэширование, поэтому я решил использовать iptables.

Итак, я добавил следующее правило:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 4430

и когда мне нужно переключиться на другого кота, я делаю:

iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 4430 
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 4431 

Казалось, что работает, но через несколько дней у всех машин проблемы с подключением. Лак не подключается к tomcat, не работает поиск DNS и т. Д.

Я нашел в / var / log / messages тысячи:

Mar 27 10:04:15 ip-10-72-254-31 kernel: [2112599.753509] nf_conntrack: table full, dropping packet.

Похоже, что завершение работы iptables помогает устранить проблемы с подключением.

Итак, я могу использовать iptables так, как я его использую? Как я могу предотвратить проблему "таблица заполнена, отбрасывание пакета"? Что еще я могу использовать для перенаправления моего трафика https?

Ответы [ 2 ]

0 голосов
/ 09 марта 2014

Чтобы ответить « Что еще я могу использовать для перенаправления моего трафика https? »: Вы можете использовать rinetd. Как и iptables, его можно использовать для перенаправления TCP-соединений на уровне порта, но его проще настроить.

По сути, вы бы поместили эту строку в /etc/rinetd.conf:

10.72.254.31  443    10.72.254.31  4430

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

10.72.254.31  443    10.72.254.31  4431

и после каждого такого изменения перезапускайте rinetd с:

service rinetd restart

Просто убедитесь, что ничего не прослушивает порт 443 при их включении, так как в противном случае переадресация не удастся, и ваш /var/log/rinetd.log будет заполнен сообщениями типа 22/Mar/2013:19:35:47 0.0.0.0 0 (null) 0 0 0 accept-failed - [ details ].

0 голосов
/ 28 марта 2012

Мы широко используем iptables и никогда не сталкивались с заполнением таблиц NAT; Единственное отличие, которое я вижу, заключается в том, что мы используем немного другие правила, используя цель DNAT (даже для localhost), а не REDIRECT.

/sbin/iptables -I PREROUTING -t nat -i eth0 -p tcp --dport 443 -j DNAT --to :4430

(наши ядра версии 2.6.32 и выше - iptables 1.4.3.1 и выше)

EDIT

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

Первый - сократить время отслеживания соединения до более разумного значения, например, одного дня. Что-то вроде:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400

Вы также можете попытаться увеличить размер таблицы

sysctl -w net.netfilter.nf_conntrack_max=65535

Перезапуска сетевых интерфейсов должно быть достаточно для использования этих новых значений.

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

...