443 открыт. TLS отвечает. Данные стоят. Типовой постмортем WireGuard через WSS/wstunnel: проверка соединения зелёная, короткий обмен проходит, передача объёма зависает. Поверхностный диагноз — «тормозит приложение». Рабочая гипотеза — PMTU black hole: промежуточный участок не пропускает крупные внешние IP-пакеты, а ICMP Fragmentation Needed или IPv6 Packet Too Big не возвращается отправителю. Сначала смотрим внешний TCP: ss -tinp 'dport = :443' — pmtu, mss, retrans и rto. Затем nstat -az TcpRetransSegs TcpExtTCPTimeouts: важен прирост за время зависшей передачи, абсолютные значения относятся ко всему хосту. Дамп tcpdump -ni eth0 'tcp port 443 or icmp or icmp6' снимаем на реальном внешнем интерфейсе. Повторные передачи одних диапазонов TCP при успешном коротком обмене поддерживают гипотезу; сами по себе ретрансляции её не доказывают. Граница принципиальна: wstunnel переносит датаграммы через поток TCP. Размер WireGuard-пакета не задаёт размер внешнего TCP-сегмента, поэтому вычитать из 1500 «весь overhead WSS» — неверная модель. Проверяем MTU маршрута и доставку ICMP. На Linux-отправителе внешнего TCP sysctl -w net.ipv4.tcpmtuprobing=1 включает обнаружение MTU при black hole; проверяем результат под нагрузкой. MSS clamping внутреннего TCP не чинит автоматически внешний TCP/443 и не помогает внутреннему UDP. При потере внешнего TCP-сегмента последующие данные ждут его восстановления: WSS добавляет зависимость всего потока от одной потери. Уменьшение MTU wg0 может помочь внутреннему пути, но не заменяет диагностику внешнего. Ещё один ingress в K3s эту физику не отменяет. Проверка канала обязана передавать данные разных размеров в обе стороны, а не просто открывать сокет. https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=port-443-otkryt-a-kanal-lezhit-wireg
