Почему тормозит интернет через Linux-шлюз?

Question

[Евгений Ферапонтов]

Суть такова: есть коробка с линуксом (Debian 7), которая терминирует vlan'ы, поднимает pppoe и запускает эти vlan'ы в интернет через pppoe. С помощью iptables настроен файрвол и NAT, поднимающиеся во время загрузки одним скриптом. (pastebin.com/7ShyK22N)
Пустил домашнюю сеть (14 машин) через этот шлюз. Через какое-то время (5-7 дней) начал тормозить интернет: то Chrome загружает страницу по минуте с постоянным "Ожидание..." внизу, то отваливаются торренты. С помощью
/sbin/sysctl net.netfilter.nf_conntrack_count
посмотрел, сколько активных NAT-трансляций, их оказалось очень много. Уменьшил тайм-ауты и увеличил размер таблицы, старался придерживаться RFC5382:

echo 65536 > /sys/module/nf_conntrack/parameters/hashsize
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
echo 120 > /proc/sys/net/netfilter/nf_conntrack_generic_timeout
echo 7440 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

но даже с одним компьютером в сети все равно

net.netfilter.nf_conntrack_count = 294

и тормоза пускай и уменьшились, но все равно сохраняются.
Что я делаю не так? Есть какие-то развернутые инструкции по поднятию интернет-шлюза на Linux'е для абсолютных новичков?
P. S. pastebin.com/VQ6T19Xp -- список NAT-трансляций при условии, что в сети только я и мой телефон.

Comments

[Power]

А у вас в syslog или dmesg есть упоминания чего-то типа "conntrack table full"?
И почему вы незванным пакетам делаете REJECT, а не DROP? Это бы уменьшило нагрузку.

[Евгений Ферапонтов]

@Power: Нет, переполнений таблицы не было.
Потому что это стандартное поведение TCP, разве нет?
"(RFC1122):

3.2.2.1 Destination Unreachable: RFC-792

A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose.

4.2.3.9 ICMP Messages

TCP MUST act on an ICMP error message passed up from the IP
layer, directing it to the connection that created the
error. The necessary demultiplexing information can be
found in the IP header contained within the ICMP message.

o Destination Unreachable -- codes 2-4

These are hard error conditions, so TCP SHOULD abort
the connection.
"

[Power]

@e1ferapontov: Если переполнений таблицы не было, то не нужно и о её размере беспокоиться, значит, дело в чём-то другом.
А выдержка из RFC - она про реакцию на ICMP-пакеты, но не про то, что их обязательно отправлять. Просто TCP RST или ICMP что-то-там - это дефолтная реакция ОС на закрытые порты; а если уж ставят фаерволл, то обычно незваные пакеты дропают (за некоторыми исключениями), т.к. это просто уменьшает расходы.

[Евгений Ферапонтов]

@Power: Именно переполнений не было, но за 5 дней работы там скопилось почти 15 тысяч записей, что не может не беспокоить. Поэтому и полез изменять тайм-ауты и размер таблицы.

Answer 1

[Евгений Ферапонтов]

Виноват оказался PMTU Discovery blackhole. У провайдера где-то перекрыт ICMP трафик, а мое правило iptables для сжимания mtu на внешнем интерфейсе не работало.
Оказывается, TCP MSS правила можно и нужно записывать исключительно в таблицу mangle, чего я как раз и не понял в первый раз ввиду отсутствия документации. После этого все заработало:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300

Answer 2

[Игорь]

A в логи ничего не падает?
В тот же dmesg\syslog\messages?
Поставьте на сервер какой-либо сервер статистики, чтобы потом увидеть на графиках, что происходит с сетью, количество ошибок на интерфейсах, потребление памяти, процессора.

Comments

[Евгений Ферапонтов]

Нет, в логах чисто и пусто, кроме сообщений от iptables о входящем ssh или пинге, которые в скрипте файрвола и настраивались.
Сегодня утром обнаружил вот это: "rsyslogd: [origin software="rsyslogd" swVersion="5.8.11 " x-pid="2190" x-info="www.rsyslog.com"] rsyslogd was HUPed"
>Поставьте на сервер какой-либо сервер статистики
Вот здесь немного подробнее, пожалуйста. Как я уже говорил, я пока очень плохо знаю Linux.
>что происходит
Ничего не происходит. Процессор утилизирован на 2% по данным top, bmon и iftop показывает около мегабита загрузки внешнего сетевого интерфейса в пике, iotop показывает полностью отсутствующую активность диска. Свободной памяти больше 80%.

[Power]

@e1ferapontov: Тогда факты в пользу того, что ваш debian-шлюз не виноват. А ошибки на сетевых интерфейсах есть? И, кстати, что находится между вашим шлюзом и интернетом: какие устройства, есть ли среди них роутеры (имеется в виду, с вашей стороны, а не со стороны провайдера)?

[Евгений Ферапонтов]

@Power: Ошибок на интерфейсах нет. Между мной и провайдером ADSL2+ модем в режиме моста.

[Валентин]

Так если стоит ADSL, оставь на linux только nat из правил для iptables. проверь, может вообще что-то другое глючит

[Power]

@e1ferapontov: Тогда даже не знаю... записывать дамп трафика и искать аномалии.
В качестве безумной идеи: может, ваш провайдер не справляется с вашим потоком соединений, и у него переполняется conntrack (если у него NAT есть); ну или у него стоит слабоватое оборудование для досмотра вашего трафика и оно не успевает. Можете попробовать завернуть всё в шифрованный vpn-туннель и посмотреть эффект.