Симптомы: когда виноват не TLS, а MTU
Сценарий типичный: SMTP на 25/587 и IMAP на 143/993 «живут», но периодически ломаются именно на STARTTLS. Клиент получает приветствие, успевает отправить EHLO, сервер отвечает, но после STARTTLS соединение зависает или отваливается по таймауту. В логах появляются TLS timeout, SSL_accept error, lost connection after STARTTLS — и кажется, что виноваты сертификат, ciphers или версия TLS.
На практике за NAT/VPN очень часто ломается не криптография, а транспорт: реальный MTU на пути ниже, чем думает одна из сторон, а PMTUD (Path MTU Discovery) не работает из‑за фильтрации ICMP. В итоге большие TCP-сегменты «не пролезают», фрагментация запрещена, и вы получаете «чёрную дыру»: часть пакетов пропадает, приложение ждёт и упирается в таймаут.
STARTTLS проявляется чаще, чем «простой текст», потому что во время TLS‑рукопожатия летят более объёмные записи: ClientHello/ServerHello, цепочка сертификатов, иногда stapling. Это резко повышает шанс наткнуться на MTU‑потолок.
Как устроена проблема: MTU, PMTUD и blackhole
MTU — максимальный размер кадра на канальном уровне. Для Ethernet обычно 1500, но при туннелях (PPPoE, GRE, IPsec, WireGuard, OpenVPN) MTU часто меньше: 1420, 1412, 1400 и т.д. Если где-то по пути MTU меньше, чем у отправителя, маршрутизатор должен сообщить об этом ICMP‑сообщением Fragmentation Needed (IPv4) или Packet Too Big (IPv6). Это и есть PMTUD.
Если ICMP режется (на фаерволах, у провайдеров, в корпоративных VPN), отправитель продолжает слать пакеты слишком большого размера. Они не доходят, TCP делает ретрансляции, окно сжимается, а протокол верхнего уровня ждёт. Так и появляются «случайные» TLS timeout на SMTP/IMAP.
Главная мысль: STARTTLS может падать даже при идеальном сертификате, если TCP не может доставить крупные сегменты из-за неверного MTU и сломанного PMTUD.
Быстрая диагностика: это действительно MTU/PMTUD?
1) Смотрите логи Postfix и Dovecot, но не «лечите» их настройками
Для Postfix характерны записи вида: SSL_accept error, warning: TLS library problem, lost connection after STARTTLS, timeout after STARTTLS. У Dovecot — SSL_accept() failed и разрывы сессий на фоне нормальных TCP‑подключений.
Важно: такие логи не доказывают, что виноват TLS. Они лишь фиксируют, что рукопожатие не завершилось.
2) Проверка с клиента: STARTTLS руками
С клиентской машины (или из проблемной сети) выполните тесты. Если из одной сети работает, а через VPN/NAT — таймаут, это сильный сигнал в сторону MTU/PMTUD.
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -crlfopenssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.comСмотрите, на каком шаге зависает. Если зависание происходит после отправки ClientHello или на этапе получения сертификата, это типично для MTU‑проблем.
3) tcpdump: видно ли ретрансляции и «дырки»
На сервере снимите трафик на нужном порту и посмотрите ретрансляции. Пример для submission:
tcpdump -ni any port 587Если во время STARTTLS вы видите многократные ретрансляции одних и тех же TCP‑сегментов и отсутствие ответа/ACK — это похоже на PMTUD blackhole.
4) Ping с DF: подбираем рабочий размер
Для IPv4 можно приблизительно оценить проходящий размер с флагом «не фрагментировать». Число в -s — полезная нагрузка ICMP; к ней прибавляются заголовки. Начните с 1472 (это 1500−28) и уменьшайте.
ping -M do -s 1472 mail.example.comping -M do -s 1400 mail.example.comЕсли большой размер не проходит, а меньший проходит — путь имеет меньший MTU или режет ICMP для PMTUD.
Почему NAT/VPN усугубляют STARTTLS на SMTP/IMAP
NAT сам по себе не обязан ломать MTU, но он часто стоит на устройстве со строгим фильтром или неочевидными правилами, а VPN добавляет оверхед и уменьшает эффективный MTU. Получается связка:
- клиент/сервер считают MTU 1500 и отправляют крупные сегменты;
- внутри туннеля реальный MTU, например, 1420;
- маршрутизатор должен отправить ICMP «слишком большой пакет», но его блокируют;
- TCP ретранслирует, а приложение видит TLS timeout.
Особенно часто это проявляется при мобильных операторах, офисных VPN, «умных» роутерах с включёнными профилями фильтрации и при двойном NAT.
Решение №1: MSS clamping (правильно и безопасно)
MSS clamping — практичный способ обойти сломанный PMTUD: мы ограничиваем MSS (Maximum Segment Size) в TCP SYN/SYN-ACK так, чтобы TCP изначально не пытался отправлять слишком большие сегменты. Это не заменяет корректный PMTUD, но часто является самым быстрым и устойчивым фикс‑вариантом за NAT/VPN.
Ключевой принцип: MSS нужно подрезать на границе, где появляется меньший MTU (обычно на VPN‑шлюзе/маршрутизаторе или на сервере, если он сам «в VPN»). Подрезать можно на FORWARD (если это роутер) или на OUTPUT/INPUT (если это конечный хост и проблема в локальном туннеле).
iptables: вариант для роутера с NAT (FORWARD)
Подрезка «по PMTU» удобна: ядро само вычисляет корректный MSS относительно интерфейса/маршрута.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuЕсли PMTUD совсем не работает, иногда приходится задавать фиксированное значение (например, 1360–1420). Делайте это осознанно и после замеров:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360iptables: если сервер сам является клиентом VPN (OUTPUT)
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtunftables: аналог MSS clamping
Ниже пример для таблицы inet. Цепочка должна обрабатывать пакеты на нужном хуке (forward или output) и срабатывать на SYN.
nft add table inet manglenft 'add chain inet mangle forward { type filter hook forward priority mangle; policy accept; }'nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt mtuЕсли нужен фиксированный MSS:
nft add rule inet mangle forward tcp flags syn tcp option maxseg size set 1360Если ваша версия nftables/ядра не поддерживает rt mtu в таком виде, ориентируйтесь на документацию дистрибутива: смысл один и тот же — менять MSS только на SYN, иначе можно повредить уже установленные соединения.
Решение №2: привести MTU в порядок (лучше, но иногда сложнее)
Если вы контролируете VPN, правильнее выставить MTU/MRU на интерфейсах туннеля так, чтобы пакеты не упирались в пределы. Например, для WireGuard часто ставят 1420 (или ниже, если поверх ещё один туннель). Для PPPoE — 1492 на WAN, и дальше учитывать это в LAN/VPN.
Проверяйте фактический MTU:
ip link showИ маршрутные подсказки (полезно для понимания, где «узкое место»):
ip route get 1.1.1.1Если после настройки MTU проблема ушла без MSS clamping — отлично. Но в реальных сетях ICMP может оставаться фильтрованным где-то «вне вашего контроля», и clamping всё равно будет страховкой.
Решение №3: не ломайте ICMP (иначе PMTUD не заработает)
Самый правильный сетевой подход — разрешить служебный ICMP. Для IPv6 это вообще критично: ICMPv6 — часть нормальной работы сети, и его блокировка приводит к странным симптомам (включая проблемы с TLS).
Минимально полезная цель: убедиться, что ICMP «packet too big» и «fragmentation needed» не отбрасываются молча на вашей границе. Конкретная реализация зависит от вашей firewall‑политики, но как минимум стоит включить логирование drop-правил для ICMP и проверить счётчики.
Если выбирать, что чинить в первую очередь: лучше аккуратно разрешить нужный ICMP, чем бесконечно подкручивать таймауты в Postfix/Dovecot.
STARTTLS и таймауты: что можно подкрутить в Postfix/Dovecot (и что не поможет)
Когда транспорт «починен», имеет смысл вернуться к TLS‑настройкам. Но важно понимать границы:
- увеличение TLS‑таймаутов может замаскировать проблему, но не устранит потери пакетов;
- смена набора шифров и версий TLS почти никогда не лечит MTU/PMTUD;
- слишком агрессивные таймауты ухудшают поведение на мобильных сетях и за VPN.
Postfix: где искать таймауты
В Postfix таймауты зависят от роли (SMTP‑клиент или SMTP‑сервер) и конкретного сервиса (smtpd/submission/smtps). Для диагностики полезно временно поднять уровень логирования TLS (не навсегда) и сверить момент обрыва с tcpdump.
Параллельно проверьте общие сетевые таймауты (например, smtpd_timeout) и то, как они сочетаются с вашей политикой TLS (например, smtpd_tls_security_level). Но если MTU сломан, тонкая настройка TLS будет вторичной.
Dovecot: типовые симптомы при PMTUD blackhole
У Dovecot STARTTLS на 143 и TLS на 993 могут вести себя по-разному: на 993 рукопожатие происходит сразу после TCP, и проблемы заметны мгновенно; на 143 STARTTLS включается позже, и кажется, что «IMAP же работал». В логах это выглядит как внезапные разрывы сразу после начала TLS.
Чтобы отделить «TLS сломан» от «канал сломан», сравните поведение:
- IMAPS (993) vs IMAP+STARTTLS (143);
- Submission (587 STARTTLS) vs SMTPS (465).
При MTU‑проблемах оба варианта могут ломаться, но «точка» будет разной — это помогает в диагностике.
Если параллельно занимаетесь усилением защиты почтовых сервисов, посмотрите практическую настройку блокировок по логам в статье Fail2ban для Postfix и Dovecot: jail’ы, фильтры и частые ошибки.
Проверочный чек-лист после фикса
- Повторите
openssl s_clientдля SMTP/IMAP из проблемной сети. - Снимите короткий
tcpdumpи убедитесь, что исчезли повторные ретрансляции на этапе TLS. - Если включали временное debug‑логирование TLS в Postfix/Dovecot — верните обратно.
- Проверьте, что MSS clamping применяется там, где надо: на FORWARD (роутер) или OUTPUT (хост), и только на SYN.
- Если возможно, поправьте ICMP‑политику, чтобы PMTUD работал штатно.
Типовые ошибки, которые делают ситуацию хуже
«Давайте просто отключим STARTTLS»
Это антипаттерн: вы понижаете безопасность SMTP/IMAP, а проблема MTU останется и выстрелит в другом месте (HTTPS, SSH, API, репликации баз).
«Поставим огромные таймауты»
Если пакеты не доходят из-за blackhole, хоть сутки ждите — рукопожатие не завершится. Таймауты полезны, когда сеть просто медленная, но не когда она «режет» крупные сегменты.
«Разрешим всё подряд в firewall»
Не обязательно. Чаще достаточно точечно решить MTU/PMTUD и аккуратно включить MSS clamping, не открывая лишние порты. STARTTLS‑проблема обычно не связана с тем, что порт «закрыт», а с тем, что часть трафика невидимо теряется по пути.
Итог
Если Postfix и Dovecot работают за NAT/VPN нестабильно и вы видите TLS timeout на этапе STARTTLS для SMTP/IMAP, начинайте не с сертификатов, а с сети: проверьте MTU, PMTUD и наличие ICMP‑blackhole. Самый практичный быстрый фикс — MSS clamping в iptables или nftables, а долгосрочная цель — корректный MTU в туннелях и нормальная ICMP‑политика.
Когда транспорт снова надёжен, уже имеет смысл полировать TLS‑часть: цепочки, протоколы, совместимость клиентов. Заодно проверьте актуальность сертификата и цепочки: для продакшена удобно держать в порядке и своевременно обновлять SSL-сертификаты для почтовых доменов.
