Есть сервер, на котором помимо postfix'а крутятся dovecot и httpd. Проблема в следующем: судя по выводу tcpdump, внешние серверы пытаются подключиться по 25 порту, т. е. шлют syn пакет, далее сервер несколько раз пытается ответить syn/ack, но соединение не устанавливается. При этом как исключение приходят письма с яндексовского почтового сервера. С другими сервисами проблем никаких.
Проблема смутно напоминает поведение при неправильном mtu, однако и в этом направлении решения пока не нашёл. Прошу помочь...
> Есть сервер, на котором помимо postfix'а крутятся dovecot и httpd. Проблема в
> следующем: судя по выводу tcpdump, внешние серверы пытаются подключиться по 25
> порту, т. е. шлют syn пакет, далее сервер несколько раз пытается
> ответить syn/ack, но соединение не устанавливается. При этом как исключение приходят
> письма с яндексовского почтового сервера.tcpdump в руки, снять успешную сессию с яндексом, снять сессию и безуспешными ack, смотреть на дампы до просветления (нет, я не буду смотреть).
У меня один "оригинальный" клиент (и да, совпадение, тоже на smtp) не умеет tcp window scaling, _заткнул net.ipv4.tcp_window_scaling=0 на своей стороне. То ли SCO, то ли SUN Unix, то ди ещё какая гадость. Просветление пришло после недели разглядывания дампов.
>[оверквотинг удален]
>> следующем: судя по выводу tcpdump, внешние серверы пытаются подключиться по 25
>> порту, т. е. шлют syn пакет, далее сервер несколько раз пытается
>> ответить syn/ack, но соединение не устанавливается. При этом как исключение приходят
>> письма с яндексовского почтового сервера.
> tcpdump в руки, снять успешную сессию с яндексом, снять сессию и безуспешными
> ack, смотреть на дампы до просветления (нет, я не буду смотреть).
> У меня один "оригинальный" клиент (и да, совпадение, тоже на smtp) не
> умеет tcp window scaling, _заткнул net.ipv4.tcp_window_scaling=0 на своей стороне. То
> ли SCO, то ли SUN Unix, то ди ещё какая гадость.
> Просветление пришло после недели разглядывания дампов.Спасибо за ответ. Пробую...
А руками проверить соединение к 25 порту (через телнет) СНАРУЖИ - не судьба? Ну и первое, что приходит в голову (если все так, как Вы описали) - файрволл, этому баяну уже лет 100. МТУ же проверяется утилитой ping.
> А руками проверить соединение к 25 порту (через телнет) СНАРУЖИ - не
> судьба? Ну и первое, что приходит в голову (если все так,
> как Вы описали) - файрволл, этому баяну уже лет 100. МТУ
> же проверяется утилитой ping.Собственно, я не упомянул... Разумеется, проверял:) Самое интересное, что, допустим, с 3G модема соединение устанавливается нормально, а с офиса в другом городе - нет... Насчёт файрволла - проверил вдоль и поперёк, хотя, логически, вы же видите, что как клиенты все внешние серверы равноправны, плюс правила iptables точно такие же для других сервисов, которые работают как положено...
> Собственно, я не упомянул... Разумеется, проверял:) Самое интересное, что, допустим, с
> 3G модема соединение устанавливается нормально, а с офиса в другом городе
> - нет... Насчёт файрволла - проверил вдоль и поперёк, хотя, логически,
> вы же видите, что как клиенты все внешние серверы равноправны, плюс
> правила iptables точно такие же для других сервисов, которые работают как
> положено...1. Отключите файрволл вообще! На уровне правил ACCEPT во ВСЕХ цепочках. Чисто для проверки. ;)
2. Про МТУ - ну попробуйте пулять в сервер с разными МТУ и выставленным флагом DF. ping -s 1500 -M do IP. Или вот так - hping -y IP -K 0 -d 1500
>[оверквотинг удален]
>> 3G модема соединение устанавливается нормально, а с офиса в другом городе
>> - нет... Насчёт файрволла - проверил вдоль и поперёк, хотя, логически,
>> вы же видите, что как клиенты все внешние серверы равноправны, плюс
>> правила iptables точно такие же для других сервисов, которые работают как
>> положено...
> 1. Отключите файрволл вообще! На уровне правил ACCEPT во ВСЕХ цепочках. Чисто
> для проверки. ;)
> 2. Про МТУ - ну попробуйте пулять в сервер с разными МТУ
> и выставленным флагом DF. ping -s 1500 -M do IP. Или
> вот так - hping -y IP -K 0 -d 15001. Да отключал, не то:)
2. Хорошо, спасибо, буду пробовать...
>> А руками проверить соединение к 25 порту (через телнет) СНАРУЖИ - не
>> судьба? Ну и первое, что приходит в голову (если все так,
>> как Вы описали) - файрволл, этому баяну уже лет 100. МТУ
>> же проверяется утилитой ping.
> Собственно, я не упомянул... Разумеется, проверял:) Самое интересное, что, допустим, с
> 3G модема соединение устанавливается нормально, а с офиса в другом городе
> - нет... Насчёт файрволла - проверил вдоль и поперёк, хотя, логически,
> вы же видите, что как клиенты все внешние серверы равноправны, плюс
> правила iptables точно такие же для других сервисов, которые работают как
> положено...Не забудьте что некоторые провайдеры блокируют 25 порт полностью
Нам пришлось для одного офиса поменять почтовик на порт 2525, и перенастроить всех клиентов
> А руками проверить соединение к 25 порту (через телнет) СНАРУЖИ - не
> судьба? Ну и первое, что приходит в голову (если все так,
> как Вы описали) - файрволл, этому баяну уже лет 100. МТУ
> же проверяется утилитой ping.Чтобы быть подробней, внешний интерфейс один, его слушают нужные сервисы.
>> А руками проверить соединение к 25 порту (через телнет) СНАРУЖИ - не
>> судьба? Ну и первое, что приходит в голову (если все так,
>> как Вы описали) - файрволл, этому баяну уже лет 100. МТУ
>> же проверяется утилитой ping.
> Чтобы быть подробней, внешний интерфейс один, его слушают нужные сервисы.Проверяете telnet из удаленного офиса по IP или хостнейму? traceroute пробовали?
> Есть сервер, на котором помимо postfix'а крутятся dovecot и httpd. Проблема в
> следующем: судя по выводу tcpdump, внешние серверы пытаются подключиться по 25
> порту, т. е. шлют syn пакет, далее сервер несколько раз пытается
> ответить syn/ack, но соединение не устанавливается. При этом как исключение приходят
> письма с яндексовского почтового сервера. С другими сервисами проблем никаких.
> Проблема смутно напоминает поведение при неправильном mtu, однако и в этом направлении
> решения пока не нашёл. Прошу помочь...1)
посмотрите роуты на Вашем сервере, на тему куда ACK шлется. вполне вероятная причина для отруба других SMTP при работе с Вами что ответы улетают ч/з другой интерфейс, чем приходящий SYN (и следовательно ч/з другой IP).2)
при возможности доступа к другим почтовым сервакам, которые так гадят, попробуйте телнетом с них до своего сервера цепануться.3)
mtu Вы только для исходящих пакетов контролировать можете, так что попробуйте поиграться с размером пакета в ping (опции: указать размер пакета, запретить дефрагментацию пакета) до проблемного почтовика, чтобы выяснить в этом ли дело