Началось все с перемаршрутизации почты. Приоритеты основного и резервного 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.
