Я разогнал свой ВПН почти до гигабита!

Оптимизация в мелочах!

Уже ближе к стандартному Wireguard!

Я запустил свой протокол в нидерланды. И скорость поражает воображение, аж целых 400 мбит за границу!?
Здорово, я уперся в какой то физический предел.

Рируем красивые графики интернет соединения! Ща добавить надо будет сервер в метрики. Пока сервер будет собирать метрики, будет слать еще шума

🌐 Как я «чинил» 500-мегабитный канал, который работал на 5% мощности

Типичная ситуация: у тебя есть два сервера (один в Москве, другой в Европе). Оба бодро рапортуют о канале в 500 Мбит/с до спидтеста (В нидерланды), но туннель WireGuard между ними едва выдает 30-40 Мбит/с. Пакеты теряются пачками (до 50% потерь на UDP!), а TCP превращается в тыкву.

Рассказываю по порядку, как я лечил этот «хронический кашель» сетевого стека.

😱 Проблема: «Дырявая труба»
При тестах iperf3 я увидел страшное:
TCP: 30-40 Мбит/с и тысячи ретрансмиссий.
UDP: Подаем 500 Мбит - доходит только половина.
CPU: Загрузка всего 50%, но есть нюанс - Steal Time до 15%. Это значит, что гипервизор «подворовывает» ресурсы процессора у нашей виртуалки.

Почему так происходило?

TCP Cubic — слишком «трусливый»: Стандартный алгоритм TCP (Cubic) при любой потере пакета думает, что в сети затор, и в ужасе режет скорость в два раза. На «грязных» каналах с потерями 1-2% он просто не может разогнаться.

UDP Bursts (Взрывы трафика): UDP не умеет тормозить. Он выстреливает пакеты огромными пачками. На виртуалке с 1 ядром и высоким Steal Time ядро просто не успевает «проснуться», чтобы забрать пакеты из очереди. Буфер переполняется - пакеты летят в корзину.

Bad Peering: Маршрут между провайдерами оказался перегружен на одном из стыков.

Решение: Тяжелая артиллерия Linux
Я решил не менять провайдера, а заставить систему работать в агрессивном режиме.

TCP BBR (Bottleneck Bandwidth and RTT):
Я переключил алгоритм контроля заторов на BBR от Google. В отличие от Cubic, BBR не боится потерь пакетов. Он смотрит на реальную запускную способность и задержку.

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

FQ (Fair Queuing) + Pacing:
Для BBR я включил планировщик FQ. Его киллер-фича — Pacing (темпирование). Теперь UDP-пакеты не вылетают безумной толпой, забивая буферы, а идут ровным строем с микропаузами. Это позволило сетевой карте «переваривать» трафик без дропов.

Расширение «зала ожидания» (Buffers):
Я увеличил системные буферы и очереди (net.core.netdev_max_backlog), чтобы у процессора было больше времени на обработку пакетов в моменты, когда его отвлекает гипервизор.

📈 Результаты
После тюнинга цифры в iperf3 заиграли другими красками:
✅ TCP: 40 Мбит/с ➡️ 130 Мбит/с (рост в 3.2 раза!)
✅ UDP: 220 Мбит/с ➡️ 335 Мбит/с
✅ Jitter: Снизился с 1.0 мс до 0.2 мс (стабильность!)

Мораль: Если ваш VPN тормозит — не спешите ругать WireGuard или провайдера (Хотя объективно, провайдер VDSka говно). Возможно, ваша ОС просто слишком вежливая для этого сурового интернета. Включайте BBR + FQ и расширяйте буферы. 🚀

#devops #networking #linux #bbr #wireguard #performance

Мой домен foxhardsoftness.ru был куплен за 150 рублей на год.

Сейчас же, домен вырос в цене аж в 7 раз и мне пришлось отвалить RegRu 1000 рублей (+ 200 рублей за свидетельство регистрации домена, то-есть общая сумма 1200 рублей на год)

Да, стало дороже, но такое повышение цены для меня было сюрпризом, учитывая что я до сих пор не знаю, за что идет такое повышение цены

Чисто rand(3000, 100000)

Сегодня сломался мой ВПН протокол FoxWG.

Роскомнадзор? Хаха - нет.

Моя ошибка, глупая ошибка.

У меня ключи роцируются автоматически и стоит проверка на наличие ключа. Но наличие я фиксирую исключительно через первый байт (Если ноль, то значит дальше ничего нет)
И вот в 9 утра получилось так, что новый ключ получил нулевой первый байт! И он ушел в ошибку что ключ не валидный и целых 3 часа отвала моего ВПН протокола.

Мораль, нужно быть внимательнее!

Настроил мониторинг Каждого Пира Wireguard, что бы смотреть нагрузки конкретных клиентов

Ля, выглядит очень круто

Можно ли переводить игру локальными LLM? Я проверил

Рано или поздно в любом проекте — игре, приложении, документации — встаёт вопрос перевода большого объёма текста. Обычный путь: ChatGPT / Claude / Gemini онлайн. Но что если нет доступа, есть требования к приватности, или просто хочется гонять это на своём железе?

Я поднял 6 моделей локально и прогнал их через синтетический бенчмарк: 30 текстов трёх категорий — меню ресторана, монологи персонажей, монологи авторов (философский текст). Железо: RTX 3060 12 GB, Intel Xeon 2.5 GHz, 10 потоков через Docker limits, 20 GB DDR3 RAM.

Медианное время:
qwen2.5:7b — 1.4s ⚡
alma-13b — 1.8s
translategemma — 1.2s (текст) / 5.5s (меню)
qwen2.5:14b — 2.0s
llamax3-8b — 1.3s (текст) / 5.5s (меню)
gemmax2-9b — 1.6s (текст) / 8.7s (меню)

🔍 Кратко по качеству:
🟢 translategemma — лучший на меню и технических текстах. Единственная, которая переводит "rack of lamb" как запечённую баранину, а не "рак из ягнёнка". Стабильна, без мусора.
🟢 gemmax2-9b — лучший на художественных и философских текстах. Живые, естественные фразы. Но дважды съехал в итальянский/португальский язык — критический баг для автоматики.
🟡 qwen2.5:14b — лучшая интонация в диалогах, чувствует разговорный стиль. Но периодически вставляет китайские символы прямо в середину русского текста (модель от Alibaba, обучена на огромном китайском корпусе). Требует retry-логики.
🟡 alma-13b — специализированная переводческая модель, стабильна, никогда не мусорит. Но переводит механически: "scar" → "шрам" она передаёт правильно, а вот "lobster bisque" превращает в "креветки в супе".
🔴 llamax3-8b — галлюцинирует на меню (из лосося делает салат), путает грамматический род говорящего в монологах.
🔴 qwen2.5:7b — самая быстрая, но качество низкое: путает рыб, смешивает языки, иногда выдаёт испанские слова.

Вывод: для продакшн-пайплайна оптимально — translategemma на меню/UI-строках + gemmax2-9b на нарративных текстах, с валидацией языка вывода. Либо Qwen 14b с жёстким промптом и авторетраем при детекции CJK-символов.

Файлик с полными переводами всех 6 моделей — в комментарии, там много интересного👇

А вы знали, что существует Rosenpass?
Я называю его немецким зайцем.

Не влезло в один пост, далее продолжу мысль ниже:

Люди, которые точно так же крутятся в постквантовых цифровых экосистемах, подошли к вопросу устойчивости иначе. Не через маскировку трафика под симметричным ключом и его детерминированную ротацию (как мой FoxWG), а через встроенное решение Wireguard с PreShareKey для каждого пира.

Я давно о нем знал, но не рассказывал.
Решил показать, что моему протоколу есть альтернативы.

В чем суть?
Rosenpass просто ротирует уже существующий PSK хостов через ассиметричные криптографические алгоритмы, устойчивые к потенциальным квантовым атакам. Это позволяет защитить слабое место Wireguard — постоянные PreShare ключи для алгоритма на эллиптических кривых.
Да, я сравниваю его со своим протоколом. Чисто технически Rosenpass лучше для квантовой устойчивости, чем мой. Но у моего есть плюс в другом! Он полностью покрывает узнаваемость Wireguard и не дает точки отсчета, откуда можно начать следить за протоколом.

Важный нюанс: ключ обфускатора в FoxWG — по сути тоже PSK. Но он заточен под покрытие протокола: шифрует весь handshake и все заголовки wireguard, не нарушая внутреннюю работу, помимо открытого ключа.

Будущая дорожная карта:
Можно совместить мое решение и Rosenpass (ротация ключа обфускатора FoxWG + постквантовая криптография для обмена новыми ключами).

Я обновил свой протокол, пофиксил в нем баги, а так же обновил BASH скрипт уставки моего протокола на сервере.

Так как это модуль ядра, приходится исходный код билдить под конкретное ядро линукса каждый раз по новой, по этому я пошел по пути, который делали в Wireguard до апдейта 5.6 (Когда оно стало частью ядра)

В целом протокол потерял немного скорости, но не критично, а то он прибавил в стабильности, все равно показатель в ПОЧТИ гигабит, остается.

Тест был проведен уже не между двумя виртуалками, а уже в настоящей локальной сети через 2 неуправляемых коммутатора разного качества.

Я уже могу выпускать его в свободное плавание!

📊 FoxWG — benchmark vs чистый WireGuard

Стенд: локальная гигабитная сеть, Клиент -> хост
Инструмент: iperf3, 5 прогонов по 10 сек
Реализация: kernel-space модуль (форк WireGuard)

━━━━━━━━━━━━━━━━━━━━━━
Результаты (TCP, среднее)

🔹 Нативная LAN: ~940 Mbits/sec
🔹 FoxWG (обфускация OFF): 881.8 Mbits/sec (−6.2%)
🔹 FoxWG Ultra (обфускация ON): 850.6 Mbits/sec (−9.5%)

Overhead самой обфускации: ~3.3% (31 Mbits/sec)

━━━━━━━━━━━━━━━━━━━━━━
Для сравнения (публичные бенчмарки):

| Протокол | Overhead |
| FoxWG Ultra | ~9.5% |
| WireGuard upstream | ~8–10% |
| OpenVPN + DCO (2024) | ~9–10% |
| OpenVPN legacy | ~30–50% |
| ShadowSocks chacha20 | ~30%+ |

FoxWG с полной обфускацией = overhead уровня чистого WireGuard.

━━━━━━━━━━━━━━━━━━━━━━
Известное ограничение:
UDP при высоком PPS (~58k пакетов/сек) даёт ~600 Mbits/sec из-за отсутствия GRO. При крупных датаграммах (5000 байт) — 847 Mbits/sec. Это общая проблема всех обфусцирующих туннелей, не специфика FoxWG.

Следующий этап: кастомный GRO хук для batch-шифрования.

Я не нашел нормальной реализации "Кузнечика" на просторах интернета.

Все что я нашел самое максимальное быстрое, это C# Nuget пакет Kuznyechik от автора: Integer (Черняков Антон)

Может кто знает где найти оптимизированную библиотеку?
Пусть на Си или Си++ или Раст, не важно =)

Было бы неплохо найти просто нормальную реализацию

UPD: Уже нашел очень мощную реализацию на Си, имбаланс какой то. Чуть похже протестирую на своем железе для понимания на пользовательских процессорах

Результат не впечатляющий, если честно, продолжаю поиски.
Если вы знаете нормальную реализацию, то рад был бы увидеть

Кому интересно, использовал это:
https://github.com/kuzcrypt

ВАУ ВАУ ВАУ, какая крутая штука!

Вот такая теперь штука есть у моих игроков, кто зарегистрирован на сервере, пользуйтесь на здоровье =)

Ссылка на приблуду:
https://map.foxhardsoftness.ru

Примечания:
Без авторизации зайди на карту нельзя. Вас выбросит на 401 страницу.

Посетить страницу могут только зарегистрированные игроки майнкрафт сервера.

Если ошибетесь 5 раз при заходе с паролем, сервер для вас будет заблокирован на 15 минут.