LINUX.ORG.RU
ФорумAdmin

iptables перенаправить пакет, дубль 2


0

1

В предыдущей серии:

в инете есть машина с ip1 и есть машина с ip2. нужно tcp пакеты приходящие на ip1:9000 перенаправлять на ip2:9001.

на машине с ip1 сделано:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -P FORWARD ACCEPT

iptables -A PREROUTING -t nat -j DNAT -p tcp -d ip1 --dport 9000 --to-destination ip2:9001

iptables -A POSTROUTING -t nat -j SNAT --to-source ip1 -d ip2 -p tcp --dport 9001

и это работает... но на множестве соединений безбожно тормозит...
я спал сегодня три часа и туплю, но может можно как то сделать более просто перенаправление без DNAT и SNAT ?

если нельзя то что можно потюнить для минимизации тормозов?

на ip1 и ip2 идентичные сетевые настройки (sysctl), количество максимальное соединений в настройках резко увелечино. тормоза при работе проявляются так: ping до ip1 резко возрастает, рулить ей по ssh становится практически невозможно, при этом процессор не загружен, ping до ip2 нормальный, процессор не загружен...

★★★★
Ответ на: комментарий от Pellaeon

Есть же маскарадинг. По крайней мере я пользую и не жалуюсь, а нагрузки огого какие бывают иногда)

Хотя маскарадинг по идее должен работать медленнее, чем SNAT.

Но если он уже включён, то SNAT не нужен))

Pellaeon
()
Ответ на: комментарий от Pellaeon

SNAT и MASQUERADE по сути одно и то-же.

машина ip1 должна прозрачно проксировать все запросы на свой порт на другую машину ip2. не понимаю откуда тормоза...

quest ★★★★
() автор топика
Ответ на: комментарий от quest

Множество соединений это сколько? Покажите:

sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_buckets

ventilator ★★★
()

У него, судя по всему, ip1 не является роутером для ip2, поэтому потребовалось двойное преобразование.

А множество соединений, это сколько? А то может быть Вам на tcp-proxy посмотреть? (udp Вам вроде уже не нужен)

ansky ★★★★★
()
Ответ на: комментарий от ansky

у машины ip1 есть сетевуха eth1 с публичным ip на которую приходят пакеты и через которую она выбрасывает пакеты на ip2 с публичным ip

quest ★★★★
() автор топика
Ответ на: комментарий от ansky

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

quest ★★★★
() автор топика
Ответ на: комментарий от quest

sysctl net.ipv4.netfilter.ip_conntrack_count
как я понял это количество текущих соединений... только что наблюдал как оно плясало в районе 60000 и при видимо 65555 машина становится недоступна, потом количество спадает и она опять слегка доступна...

упирается в сетевой канал?
может какие таймауты вниз подкрутить?
выставил sysctl net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=3

quest ★★★★
() автор топика
Ответ на: комментарий от quest

Уберите SNAT, разве для машины ip2 обязательно нужно чтобы трафик приходил src ip=ip1? Возможно достаточно написать дефолт роут в строну ip1 и не делать SNAT. Я не совсем понял, у вас в одном выводе net.ipv4.netfilter.ip_conntrack_count = 8 а потом вы говорите что 60000. Общее правило таково:

net.ipv4.netfilter.ip_conntrack_max=N*2
net.ipv4.netfilter.ip_conntrack_buckets=N

N - максимально наблюдаемое количество активных потоков(net.ipv4.netfilter.ip_conntrack_count)
tcp_timeout_time_wait=3 не нужно ставить.

В любом случае настройки хештаблиц для вас ситуацию вкорне не изменят, потому что упирается не в них.

ventilator ★★★
()
Ответ на: комментарий от ventilator

>Я не совсем понял, у вас в одном выводе net.ipv4.netfilter.ip_conntrack_count = 8 а потом вы говорите что 60000.

8 было при не запущенном тесте, я думал это статическая настройка

quest ★★★★
() автор топика
Ответ на: комментарий от ventilator

>Возможно достаточно написать дефолт роут в строну ip1 и не делать SNAT.

если бы ip1 был гейтом в локальную сеть ip2 то да, но в тут это машины с публичными адресами в разных городах

quest ★★★★
() автор топика
Ответ на: комментарий от ventilator

>В любом случае настройки хештаблиц для вас ситуацию вкорне не изменят, потому что упирается не в них.

ip_conntrack_max, ip_conntrack_buckets это настройки хештаблиц в которые складывается проначеный пакет чтобы возвращенный пакет то-же пронатить? а во что тогда упирается? как я понимаю либо в канал либо в настройки tcp стека, либо в настройки (реализацию) сетевого драйвера либо в общую производительность сетевой подсистемы (cpu почти не загружен)

quest ★★★★
() автор топика
Ответ на: комментарий от quest

ip_conntrack_max - максимальное количество записей в таблице conntrack, после переполнения начинаются потери пакетов. ip_conntrack_buckets - размер хеша, наибольшая производительность достигается когда он близок к активному количеству записей.

ventilator ★★★
()
Ответ на: комментарий от quest

«достаточный» - это как то слабо описывает нагрузку ). 8 ядер прожуют гига 4 ната, однако сессий как то маловато по вашим счетчикам выходит.

ventilator ★★★
()
Ответ на: комментарий от ventilator

от этой идеи и ната и прокси отказались зарулили трафик dns на другой сервер. сессий дофига висит, тысяч 300, думаю нужно пытаться уменьшать таймауты

quest ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.