Свежий handshake — слабое алиби для туннеля. Типовой отказ WireGuard/AmneziaWG mesh: маленький healthcheck проходит, крупный ответ зависает, мониторинг рисует таймаут приложения. Добавлять реплики K3s здесь бессмысленно: если причина в размере пакета, новые поды унаследуют тот же отказ. Сначала отделяем доступность узла от способности пути переносить данные нужного размера. Снимаем ss -ti dst и nstat -az TcpRetransSegs TcpExtTCPTimeouts IpFragFails IpReasmFails до и после воспроизведения. Рост retrans и таймаутов — улика, но ещё не диагноз. Проверяем tracepath -n и ping -4 -M do -s , меняя N: это размер ICMP payload, к нему добавляются 28 байт IPv4/ICMP. Нулевые счётчики ошибок фрагментации на узле не оправдывают путь: пакет мог исчезнуть на промежуточном маршрутизаторе. Механика отказа: внутренний пакет после инкапсуляции превышает PMTU внешнего пути. Для IPv4 возможна фрагментация, если она разрешена; потеря одного фрагмента губит всю дейтаграмму. Маршрутизаторы IPv6 пакеты не фрагментируют. Когда нужный ICMP Fragmentation Needed или ICMPv6 Packet Too Big фильтруют, отправитель может продолжать слать неподходящий размер. MTU рассчитывают для фактического пути и вложенных туннелей; параметры конкретной реализации AmneziaWG тоже проверяют, а не копируют чужое число. MSS clamp правит объявляемый MSS в TCP SYN, включая SYN-ACK: правило должно охватывать нужные направления и цепочки. FORWARD не охватит локально созданное соединение, а существующую сессию изменение правила не перенастроит. Clamp по маршрутному MTU бесполезен против меньшего PMTU, о котором ядро не знает; UDP и QUIC он не лечит вовсе. Исправляем MTU и прохождение служебного ICMP, затем проверяем крупную передачу в обе стороны. Эксплуатация без гадания: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=tcp-mss-clamping-i-skrytye-lovushki