Здравствуйте! Недавно столкнулся с потерей пакетов от РФ провайдеров Cloud.RU и Yandex Cloud до зарубежного сервера. Запустил MTR в несколько потоков и увидел следующее:
CloudRU:
Yandex Cloud:
Selectel через dataIX без потерь:
Подготовка к Эксперты ожидают в сентябре первые последствия моратория на расширение каналов связи для зарубежного трафика в РФ / Хабр ?
Ух. Надеюсь, что это временные трудности)
По теме последствий моратория: хз что будет на самом деле, но можно предположить судя по туркменистану. В туркменистане уже давно проблемы с нехваткой каналов, из-за чего по вечерам бывает +100мс к пингу и до 25% потерь пакетов, недавно что-то случилось и потери стали еще сильнее, из-за чего почти единственным способом нормально пользоваться инетом оставалась hysteria (имеет очень агрессивный алгоритм для работы в сетях с потерями, а в старых версиях вообще тратила трафик в пустую в некоторых случаях), и прикол в том что чем больше пользователей этого алгоритма (особенно старой версии), тем больше сеть будет перегружена. Короче в худшие моменты я видел потери пакетов до 40% (пользоваться инетом невозможно - загрузки в 10кб/сек с обрывами и это с bbr), подозреваю что это было из-за наплыва пользователей hysteria т.к. все остальные протоколы были тупо бесполезны. Со временем потерь стало меньше, хз из-за чего (многие перешли на старлинк несмотря на нелегальность, может быть это помогло)
Но я считаю что до заметных перегрузок каналов в рф еще далеко
Начал разбираться с поддержкой Yandex Cloud и Cloud.RU, а также получил короткую информацию от PG19, что ведутся какие-то “работы” на PITER-IX.
Тем временем stormwall поменял анонс маршрутов так, что промежуточный хоуп в Польше и Нидерландах с одного хостинг провайдера - стал одинаковым.
Потери наблюдаются только при отправке пакетов из-за границы в Россию
MTR
Netherlands (TCP 443, 100 пакетов):
Poland (TCP 443, 100 пакетов):
Oracle Netherlands (TCP 443, 100 пакетов):
Очень интересный момент, что только пакеты из Нидерландов с 50% loss. Тесты были запущены одновременно.
По UDP ситуация такая-же:
Netherlands (UDP 2409, 100 пакетов):
Poland (UDP 2409, 100 пакетов):
Oracle Netherlands (UDP 2409, 100 пакетов):
ICMP без потерь:
Netherlands (ICMP, 100 пакетов):
Poland (ICMP, 100 пакетов):
Oracle Netherlands (ICMP, 100 пакетов):
I think everyone has seen UDPSpeeder and similar solutions written in Go - I forgot the exact name, but it might be KCPTUN. Of course, both rely on the UDP protocol, which ISPs can easily block. However, take a look at the udp2raw project by the same author as UDPSpeeder. While the idea is interesting, the implementation is unfortunately weak and easily blocked because it has clearly distinguishable signatures.
I believe we need a similar project but without any external signatures. All headers and metadata must be kept inside an encrypted protocol, not outside. It should mimic TCP traffic while remaining tolerant to massive packet loss, which can be achieved by using Forward Error Correction (FEC) codes. Specifically, it should not be based on Reed-Solomon codes, but rather on some sort of fountain codes, such as Luby Transform (LT) codes or Raptor codes. For Raptor codes, we already have an RFC, a reference implementation, and a few GitHub projects implementing the encoders and decoders.
In addition, I believe the protocol must be based on a “fake” TCP that closely mimics real TCP traffic. It should utilize a small pool of 4 to 6 multiple connections. To prevent detection as a VPN based on connection longevity, each connection must have a short lifespan of 2 to 5 minutes, with connections respawning in a round-robin fashion. These connections must be strictly divided into two distinct groups: upstream data and downstream data. For inner TCP streams (the VPN use case, rather than a SOCKS proxy), ACK packets must never be transmitted over the same connection as the payload data. This separation is critical to avoid VPN detection based on typical traffic characteristics, such as a predictable 1:10 ratio of reverse-direction small packets. Also, I think distinct connections might be routed via distinct foreign servers to make VPN detection difficult.
I tried udpspeeder and kcptun some time ago and couldn’t properly set them up - the result was bad, BBR worked much better right away without any tuning and it works fine on up to 20% losses in my experience, on heavier losses brutal (from hysteria) may work better (i mean the kernel module, their userspace quic implementation may be worse than bbr sometimes, it depends on the network conditions). Bbr/brutal are tcp algorithms so they will only work on top of a TCP vpn/proxy and that will add some jitter when lossess occur (not suitable for online gaming).
For udp/real-time data your solution may be better
Same here!
A simple FEC is already implemented in the aivpn project. I also suggested this idea to the qeli developer. Someone else could reach out to the ftpn developer as well. Right now, these IP tunnels that mimic HTTPS-like traffic don’t have raw socket/npcap transport implementations, but I hope one of them will add it, or another solution will emerge.
Для udpspeeder себе подобрал параметры для отправки VoIP с рейтом 100 pps: --mode 1 --fec 2:6 --timeout 1 --interval 8, для bulk не пробовал — не требовалось.
пробуй десяток разных портов, возможно от порта зависит маршрут, либо возможно какие-то порты блокируются вообще (и поэтому без фиксирования порта даёт потери)