Параметры ядра Linux и разрыв соединения при передаче больших файлов

Началось все с перемаршрутизации почты. Приоритеты основного и резервного MX поменялись местами, и поток писем бодро полился через сервер в другом филиале. Ну как «бодро» – очень скоро вылезла неприятность: письма размером больше 10 Мб на дружественную организацию, с которой уже давно был поднят вполне стабильный VPN-туннель, застревали в очереди на отправку, в логах такое:

conversation with relay.friend.local[192.168.0.9] timed out while sending message body

Сервер на CentOS 6.8, почта – postfix. С обратной стороны то же самое – письма от друзей висят в очереди (там Ubuntu 15.10+тот же postfix). Как временный workaround, перенаправили почту друг на друга через Интернет, в обход туннеля – почта залетала. Стало быть, postfix работает нормально, проблема где-то в сетевых настройках.

Проблема воспроизвелась при копировании файла через scp. Причем что странно – проблема возникает только при отправке данных, если тянуть их с той стороны – все OK:

[root@relay.we.local ~] scp test.bin relay.friend.local:
FAIL

[root@relay.friend.local ~] scp relay.we.local:test.bin .
SUCCESS

Копаем дальше. У нас много разных серверов на линуксах в нескольких филиалах, где-то ситуация воспроизводится, где-то все работает без проблем. Внутри одного филиала проблема не проявляется, только через VPN-туннели, хотя каналы у нас неплохие – по 50-100 Мбит. Пытаемся найти отличия между проблемными серверами/каналами и теми, где все работает:

Первая версия – вроде как проблема там, где сетевая карта VMXNET3 (у нас все в виртуальной среде). Меняем на E1000 – не помогло (

Внезапно оказывается, что если отключен файрвол (стандартный линуксовый iptables) – то все работает! Однако, на старом почтовике iptables включен, но все хорошо. Понимаем, что соединение рубится файрволом, осталось разобраться почему.

Прослушка трафика с помощью wireshark показала, что при передаче файла идет куча ретрансмиссий, затем в какой-то момент iptables просто перестает пропускать пакеты. Видимо, перестает считать что пакеты принадлежат существующему соединению и соответственно блокирует. Почему оно так себя ведет – остается загадкой.

Ладно, зайдем с другой стороны. На старом почтовике, так же как и на новом, наш любимый CentOS 6.8, вроде бы системы идентичны. Но на старом проблемы нет, а на новом есть. И построчное сравнение конфигов показало наконец заветное отличие! Всего одна строчка в /etc/sysctl.conf:

net.ipv4.tcp_sack = 0

и проблема исчезает.

Казалось бы, опция tcp_sack наоборот должна улучшать производительность  сети на каналах с большим количеством повторных отправок пакетов. Но то ли сами iptables с этим делом плохо работают, то ли сетевое оборудование где-то по пути модифицирует трафик и этим вставляет палки в колеса iptables, но факт остается фактом: если у вас по непонятным причинам рвутся соединения при передаче больших файлов, попробуйте отключить tcp_sack.

Запись опубликована в рубрике Linux. Добавьте в закладки постоянную ссылку.

Комментарии запрещены.