Добрый день.Есть NAT-сервер на базе IPTABLES.
Нагрузка около 150 mbit/s, 70000-80000 пакетов в секунду.Все работает отлично, кроме пропуска через NAT фрагментированных IP-пакетов, т.е. пакет размером 1501 байт, до сервера разбитый на 2 IP-пакета, попадает на сервер и собственно все.
Точнее сразу после начала передачи трафика через сервера несколько подобных пакетов проходят, потом - нет.
Где порыться?
> Добрый день.
> Есть NAT-сервер на базе IPTABLES.
> Нагрузка около 150 mbit/s, 70000-80000 пакетов в секунду.
> Все работает отлично, кроме пропуска через NAT фрагментированных IP-пакетов, т.е. пакет
> размером 1501 байт, до сервера разбитый на 2 IP-пакета, попадает на
> сервер и собственно все.
> Точнее сразу после начала передачи трафика через сервера несколько подобных пакетов проходят,
> потом - нет.
> Где порыться?man iptables / mss
> man iptables / mssmss думаю не причем, проверяю путем отправки ICMP-пакетов.
Возможно, дело в нагрузке на сервер, несколько пакетов все-же проходят в самом начале форвардинга трафика - потом глухо, смущает именно проблема с ip-пакетами, фрагментированными до сервера, не фрагментированные пакеты бегают нормально.
>> man iptables / mss
> mss думаю не причем, проверяю путем отправки ICMP-пакетов.
> Возможно, дело в нагрузке на сервер, несколько пакетов все-же проходят в самом
> начале форвардинга трафика - потом глухо, смущает именно проблема с ip-пакетами,
> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.1. MSS и ICMP вещи абсолютно несовместимые. Почитайте ман от iptables (как предложили выше) - там есть механизм тюнинга MSS.
2. При помощи ICMP проверяют MTU, при этом выставив DF-бит и задав нужный размер пакета (с учетом заголовка самого ICMP и IP).
3. Можно еще попробовать снимать на входе и выходе DF-бит на пакетах. Правда как это сделать на линуксе не знаю. Небыло необходимости.http://www.opennet.me/base/cisco/df_packet_fragment.txt.html
>[оверквотинг удален]
>> Возможно, дело в нагрузке на сервер, несколько пакетов все-же проходят в самом
>> начале форвардинга трафика - потом глухо, смущает именно проблема с ip-пакетами,
>> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.
> 1. MSS и ICMP вещи абсолютно несовместимые. Почитайте ман от iptables (как
> предложили выше) - там есть механизм тюнинга MSS.
> 2. При помощи ICMP проверяют MTU, при этом выставив DF-бит и задав
> нужный размер пакета (с учетом заголовка самого ICMP и IP).
> 3. Можно еще попробовать снимать на входе и выходе DF-бит на пакетах.
> Правда как это сделать на линуксе не знаю. Небыло необходимости.
> http://www.opennet.me/base/cisco/df_packet_fragment.txt.htmlПакет уже фрагментированный, до сервера с NAT.
>> man iptables / mss
> mss думаю не причем, проверяю путем отправки ICMP-пакетов.
> Возможно, дело в нагрузке на сервер, несколько пакетов все-же проходят в самом
> начале форвардинга трафика - потом глухо, смущает именно проблема с ip-пакетами,
> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.Iptables-save
>>> man iptables / mss
>> mss думаю не причем, проверяю путем отправки ICMP-пакетов.
>> Возможно, дело в нагрузке на сервер, несколько пакетов все-же проходят в самом
>> начале форвардинга трафика - потом глухо, смущает именно проблема с ip-пакетами,
>> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.
> Iptables-saveДаже так не работает
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P FORWARD ACCEPT-t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
При этом, если забить на всех абонентов и делать NAT только для тестового - то начинает работать (т.е. нормально делать NAT для фрагментированных пакетов), видимо все-же проблема в нагрузке.
>[оверквотинг удален]
>>> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.
>> Iptables-save
> Даже так не работает
> -P INPUT ACCEPT
> -P OUTPUT ACCEPT
> -P FORWARD ACCEPT
> -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
> При этом, если забить на всех абонентов и делать NAT только для
> тестового - то начинает работать (т.е. нормально делать NAT для
> фрагментированных пакетов), видимо все-же проблема в нагрузке.А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl -a | grep forward
>[оверквотинг удален]
>> -P INPUT ACCEPT
>> -P OUTPUT ACCEPT
>> -P FORWARD ACCEPT
>> -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
>> При этом, если забить на всех абонентов и делать NAT только для
>> тестового - то начинает работать (т.е. нормально делать NAT для
>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
> -a | grep forwardна текущий момент сессий в conntrack около 150000.
>[оверквотинг удален]
>>> -P OUTPUT ACCEPT
>>> -P FORWARD ACCEPT
>>> -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
>>> При этом, если забить на всех абонентов и делать NAT только для
>>> тестового - то начинает работать (т.е. нормально делать NAT для
>>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
>> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
>> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
>> -a | grep forward
> на текущий момент сессий в conntrack около 150000.Это ниочём тормрза на 'олее-менее современной машине должны начинаться от 3 милионов.
>[оверквотинг удален]
>>>> -P FORWARD ACCEPT
>>>> -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
>>>> При этом, если забить на всех абонентов и делать NAT только для
>>>> тестового - то начинает работать (т.е. нормально делать NAT для
>>>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
>>> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
>>> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
>>> -a | grep forward
>> на текущий момент сессий в conntrack около 150000.
> Это ниочём тормрза на 'олее-менее современной машине должны начинаться от 3 милионов.Тоже так думаю, проблемы именно с пакетами, пришедшими из вне уже фрагментированными.
Читал, что перед тем, как попасть в NAT, фрагменты должны собраться в пакет, может быть здесь проблема?
С остальным трафиком проблем нет, все натится нормально.
>[оверквотинг удален]
>>>>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
>>>> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
>>>> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
>>>> -a | grep forward
>>> на текущий момент сессий в conntrack около 150000.
>> Это ниочём тормрза на 'олее-менее современной машине должны начинаться от 3 милионов.
> Тоже так думаю, проблемы именно с пакетами, пришедшими из вне уже фрагментированными.
> Читал, что перед тем, как попасть в NAT, фрагменты должны собраться в
> пакет, может быть здесь проблема?
> С остальным трафиком проблем нет, все натится нормально.Если вы продолжете не отвечать на вопросы с предоставлением доп.инфо. , боюсь я вам ничем помочь не смогу.
>[оверквотинг удален]
>>>>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
>>>> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
>>>> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
>>>> -a | grep forward
>>> на текущий момент сессий в conntrack около 150000.
>> Это ниочём тормрза на 'олее-менее современной машине должны начинаться от 3 милионов.
> Тоже так думаю, проблемы именно с пакетами, пришедшими из вне уже фрагментированными.
> Читал, что перед тем, как попасть в NAT, фрагменты должны собраться в
> пакет, может быть здесь проблема?
> С остальным трафиком проблем нет, все натится нормально.По поводу трансляции фрагментированного трафика был не в курсе. Действительно, фрагменты же пересылаются уже без указания номеров портов источника/назначения, а значит пакет должен быть собран полностью до помещения его в conntrack. Памяти достаточно?
Посмотрите тут
https://nikitushkin.wordpress.com/2011/02/12/%D0%B.../Обратите внимание на net.ipv4.ipfrag_low_thresh. Возможно тут собака порылась
>[оверквотинг удален]
>>>>> фрагментированных пакетов), видимо все-же проблема в нагрузке.
>>>> А про какую нагрузку вы говорите? сколько одновременных сессий в conntrack'е?
>>>> Сделайте максимально простой мсэ, замените вывод первых октетов iptables-save, ip ro, sysctl
>>>> -a | grep forward
>>> на текущий момент сессий в conntrack около 150000.
>> Это ниочём тормрза на 'олее-менее современной машине должны начинаться от 3 милионов.
> Тоже так думаю, проблемы именно с пакетами, пришедшими из вне уже фрагментированными.
> Читал, что перед тем, как попасть в NAT, фрагменты должны собраться в
> пакет, может быть здесь проблема?
> С остальным трафиком проблем нет, все натится нормально.....удалено
>[оверквотинг удален]
>>> фрагментированными до сервера, не фрагментированные пакеты бегают нормально.
>> Iptables-save
> Даже так не работает
> -P INPUT ACCEPT
> -P OUTPUT ACCEPT
> -P FORWARD ACCEPT
> -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to-source x.x.x.x
> При этом, если забить на всех абонентов и делать NAT только для
> тестового - то начинает работать (т.е. нормально делать NAT для
> фрагментированных пакетов), видимо все-же проблема в нагрузке.В момент предполагаемой высокой нагрузки пришлите вывод утилиты top