Починил скорость на VPS для IPv6

Перейдя на другой VPS провайдер для IPv6 Интернета, с самого начала у
меня с ним только одна проблема: низкая скорость ко мне, всего десятки
килобайт в секунду, или пару сотен если несколько потоков параллельно.
Отдача трафика на мегабайтах в секунду, проблем нет.

Время от времени пытался выяснять в чём проблема, почти всё время про
себя ругаясь на ТСПУ, который мне наверное всё и урезает, чтобы VPN не
использовал.

Я пробовал WireGuard. Пробовал просто IP-in-IP туннель. Пробовал всё это
пропускать уже поверх IPv6 через вторую VPS-ку. Все автономные системы
российские, все адреса тоже, сети тоже, никаких зарубежных. fetch ISO
образа с mirror.yandex.ru на VPS-ке идёт быстро, а через неё медленно.
iperf3 показывает, что скорость внутри VPN-а между мной и самой VPS-кой
хорошая. Но как только "выхожу" куда-то наружу, то на вход проседает.

Думал, что это DPI так shape-ит трафик. Не нашёл ни одного готового
решения чтобы UDP трафик пускать через TCP-прокси. Ну или плохо искал
или что-то сложное попадалось. Хотел завернуть UDP пакеты WireGuard-а в
него. Написал на Go свой, на пару экранов кода. Просто перед содержимым
UDP пакета 16-бит длины добавляется. Не помогло. Решил шифровать первые
8-байт Blowfish (он реально вполне быстрый), а в начале делать простой
challenge-response authentication на основе хэша. Ну чтобы скрыть явные
инкапсулированные длины UDP пакетов проксируемых. Не помогло. Решил
ChaCha20 шифровать полностью весь пакет, так что TCP трафик полностью
становится неотличимым от шума. Не помогло. Решил дополнять каждый пакет
до большого фиксированного размера, чтобы было меньше корреляций с
размерами проксируемых пакетов. Не помогло. Стал генерировать
константный по кол-ву пакетов трафик: или у меня срабатывает таймер и
отправляется пустой (но фиксированный по размеру всё равно) пакет, либо
у меня есть UDP для отправки. Вижу что 1.5MBps трафик в обе стороны
идёт, iperf3 показывает симметричную скорость ограниченную туннелем. Ну
вот уж полностью стала отсутствовать корреляция между этим трафиком и
входящими пакетами, которые через туннель выйдут наружу. Тоже не помогло.
Благо, что каждая подобная правка это вопрос получаса работы at most,
ибо на Go, который даже в top не особо будет заметен.

Подумал что может быть hop count в IP пакетах как-то влияет? Поменял в
разные стороны на VPS -- не помогло, на её скорость (fetch .iso на ней)
никак не отражается.

Ну не может DPI как-то находить корреляции между входящим plaintext
трафиком и константным шумом. Кто ещё может как-то "вредить"? Начал
грешить на саму VPS-ку. Пошёл даже ядро пересобирать, подумав, что может
быть они какие-то патчи наложили мешающие делать VPN? До установки
нового ядра не успел дойти.

Вот где можно/нужно вставить sleep, чтобы VPN тормозит? По сути просто
навсего в forwarding plane. Никаких проблем если IP пакеты не
затрагиваются forwarding-ом. Уже почти сдавшись, решил поискать банально
"freebsd slow forwarding" и среди первых ссылок есть задача с темой тип
"медленный forwarding в xen". У меня, правда, KVM. И там рекомендуют
отключить аппаратную проверку контрольных сумм на виртуальном сетевом
адаптере. Я всю жизнь сплошь и рядом видел обсуждения и порицания
аппаратных ускорений. TSO и LRO обязательно надо отключать для
маршрутизатора -- это у меня с самого начала было. А вот из своих
рекомендаций я убрал отключение проверки контрольных сумм, ибо давно не
находил на них ругательств, вроде бы они не проблема. Поэтому забыл.

ifconfig vtnet0 -rxcsum -txcsum и скорость скачивания через VPN более
чем в сотню раз повышается, проблема решена. И стыдно, что забыл про
такую банальную штуку, но зато сколько софта понаписал, плюс очередной
неотличимый от шума протокол, даже квантовоустойчивый (ибо PSK :-)). Но
ни на одной VPS у меня не было такой проблемы. Какой-то не такой KVM у них.