Современный VPN-протокол.

Shadowsocks + v2ray-plugin.

https не обязательно «недолго живущий».

Долгоживующий будет постоянно рваться, например. И если у VPN при этом длительное восстановление, то будет очень неудобно. А если провайдер ещё портит траффик, то совсем печально.

Второй момент, шейпиться может по соединениям (по портам). И возможность работать с более чем одним соединением, очевидно, выгодна.

Третий момент: данные в рамках одного соединения передаются строго последовательно. Пока принимающая сторона не вЫчитает ранее переданное из всех буферов по цепочке, более поздние, условно более приоритетные данные, не будут обработаны. Если внутри VPN, например, параллельно есть два соединения, например, передача видеофильма и работа в консоли, то очевидно, одно начнёт заметно притормаживать другое. Чего не было бы при работе без VPN, или при работе VPN по UDP-протоколу. Отправляющая сторона может, конечно, не слать без оглядки, а делать какое-то своё управление потоком до упаковки данных в сокет VPN’а (но какие протоколы так делают?)… Если используются множественные соединения то, очевидно, пакеты в одних могут обгонять пакеты посланные в других и при большом числе соединений характеристики канала связи приблизятся к тому, что можно получить работая по UDP. Вообще UDP и следовало бы использовать, но в современное время остаётся только HTTPS…

Чем не устраивает Wireguard?

Если внутри VPN, например, параллельно есть два соединения, например, передача видеофильма и работа в консоли, то очевидно, одно начнёт заметно притормаживать другое. Чего не было бы при работе без VPN, или при работе VPN по UDP-протоколу.

Вот ничего не понял. Чем в данном случае TCP хуже UDP...

вероятно отсылка на то, что TCP гарантирует не только доставку как таковоую, но и порядок доставки пакетов.

И что?

Ставь softether и используй всё

HTTPS

SSTP там тоже есть.

Третий момент: данные в рамках одного соединения передаются строго последовательно

Данные в рамках одного провода тоже. Как страшно жить.

Обычного OpenVPN с tls-crypt-v2 не хватает?

Когда случится потеря, застопорится весь транспортный поток целиком. Если бы VPN не было (или был бы, но с UDP-транспортом), то мы бы просто потеряли один фрейм и продолжили передавать дальше. А в случае с TCP, транспорт пытается быть излишне надёжным, гарантируя сохранение порядка и оттормаживая обработку данных, пока потерянный кусок не будет переотправлен.

А если внутри такого VPN через TCP использовать тоже TCP, то всё будет ещё хуже - алгоритмы предотвращения перегрузок (congestion control) внутри и снаружи начнут мешать работе друг-друга.

Поэтому VPN поверх TCP стоит использовать либо тогда, когда не осталось других вариантов (например для совместимости со странной версией openvpn внутри RouterOS от MikroTik), либо в очень надёжных и быстрых сетях, либо поверх множественных соединений, либо модифицировав TCP-стек с двух сторон (выключив ретрансмиты; то есть фактически использовать другой протокол, маскирующийся под TCP) и надеяться не сломать этим middlebox’ы провайдеров.

то мы бы просто потеряли один фрейм и продолжили передавать дальше.

Дядя вы сейчас о чем? О каких потерях? Вы сейчас потоковую аудио трансляцию ни с чем не перепутали?

softethervpn

мимикрирующий под недолго живущие HTTPS-соединения.

shadowsocks + stunnel или другой обфускатор - как раз это и будет

плюс dnscrypt или подобное

плюс privoxy для разделения трафика - крупные незаблокированные сайты пускать напрямую, а по умолчанию и мелкие - проксировать

https://2ch.hk/s/res/3053359.html

Я использую ssh в качестве впн

О каких потерях?

На практике идеальных сетей не бывает. При передачи сетевые фреймы могут потеряться, задерживаться, перемешиваться и портиться. А ещё пропускная способность конечна (и не всегда известна заранее), и чем ближе к ней мы нагружаем канал, тем чаще будут происходить описанные эффекты. Интернет, как объединение сетей, ещё больше усугубляет эти проблемы. Но в TCP есть механизмы, которые пытаются угадать результирующую пропускную способность соединения и скрыть от пользователя неидеальность сети.

Пусть через VPN работает два TCP-клиента - для определённости один telnet-клиент и wget, качающий большой файл по HTTP, всё это одновременно.

Если VPN использует единственное TCP-соединение в качестве (потокового) транспорта, то в этот поток намешаются пакеты каждого внутреннего соединения в некотором фиксированном порядке, после чего попадут в socket buffer отправителя и начнут отправляться по сети. Если в этот момент произойдёт потеря (пусть даже одного байта), то оба внутренних соединения залипнут, пока не будет завершена и подтверждена перепосылка.

Более того, если время такого залипания окажется достаточным для того, чтобы внутренний TCP заметил проблему, то он тоже начнёт перепосылать данные.

Если VPN использует UDP, то потеря одной датаграммы будет обнаружена только тем внутренним TCP-соединением, на котоый она оказала свой эффект. Если веб-сервер от wget не получил ACK, то по истечению соответствующего таймера он выполнит перепосылку, что не затронет telnet-соединение никак; ведь нет ещё одного TCP снаружи, в который бы VPN-сервер сериализовывал трафик виртуального сетевого интерфейса, фиксируя порядок доставки.

http://sites.inka.de/bigred/devel/tcp-tcp.html

Это всё не будет работать.

Это всё будет работать.

Со скоростью 128 кбит/с.

ЗЫ

Active Probing всё это решает.

Со скоростью 128 кбит/с.

shadowsocks+stunnel выжимают доступный максимум для моего дешевого роутера - 30 Mbit/s.

Какая задача решается? Обход блокировок, анонимность или чего?

Это временное явление и очень скоро его исправят.

с чего бы вдруг шейпили ssl?

Извиняюсь за оффтоп, а есть ссылки с историями успеха?

P.S. Это для друга.

Ясно, ви таки не о потерях. А то я уж прям испугался.

Скорее намек не на шейпинг ssl или чего-то другого, а на то что когда дядя провайдер увидит что юзер вася гонит тонны трафика исключительно по одному направлению, он узеру васе кислород-то в этом направлении прикроет.

под недолго живущие HTTPS-соединения.

А такое вообще возможно в случае с туннелем? Это же намекает на постоянные разрывы соединения.

Вот когда ты видосик смотришь, то соединение долго-долго живёт.

Всё ещё хуже.

Я бы копал в сторону shadowsocks + wireguard.

что юзер вася гонит тонны трафика исключительно по одному направлению

Просмотр ютуба к этому относится?

А то. На ютубе же каждый пятый ролик про оппозицию. Посмотрел больше пяти — можно сажать. --sarcasm

Это же намекает на постоянные разрывы соединения.

У некоторых опсосов именно это и происходит по поводу и без. Нормально работают только speedtest.net, вконтакт и ютуб.

Собственно вся тема с VPN в том числе и потому, что благодаря стараниям опсосов (впихивающих рекламу, портящих траффик так что ssh вываливается с ошибками, устраивающих шейпинг в зависимости от адреса) помноженных на старания роскомпозора (когда половина ссылок по сугубо технической тематике, без всякого навального, упирается в страницу блокировки) пользоваться интернетом в РФ стало невозможно. Хорошо работает только вконтакт и т.п.

Ну и хватит тебе вконтакта. Потом и его уберут.

Я бы копал в сторону shadowsocks + wireguard

Почему-то называются конкретные программные продукты, но не раскрываются используемые ими технологии, и непонятно имеют ли они вообще какое-то преимущество.

Я думаю, скорей следует смотреть в сторону комбинации pppd с multipath -> httptunnel (proxytunnel, etc…) -> nginx -> httptunnel -> pppd. Как я понимаю, VPN-протоколы в чистом виде прекрасно детектятся (что собственно делает sslh), а будучи завёрнутыми в https становится более трудно детектируемыми, но нюанс – соединение живущее часами с огромной дисперсией скорости потока – это однозначно не загрузка файла и не видео, значить можно шейпить… Почему серии короткоживущих соединений лучше.

Кроме того, вариант с HTTP внутри можно пропускать через сторонние load balancing services, вроде cloudflare или amazon. Тогда шейпинг или блокировка по IP-адресу для провайдера сильно усложняется. Тогда в pppd нужно включать mppe и/или доворачивать что-то снаружи, например tinc, openvpn, etc…

Можно ли как-то использовать современный Multipath TCP? Будет ли он проходить через провайдерские сети, или будет детектится и блокироваться, портиться и т.п.?

Нагуглилось готовое «многоканальное» решение: https://github.com/VrayoSystems/vtrunkd – но оно, очевидно, тоже детектится провайдерами.

Я же написал «исключительно по одному направлению»

А то. На ютубе же каждый пятый ролик про оппозицию. Посмотрел больше пяти — можно сажать. –sarcasm

Не посмотрел, а прокомментировал положительно. Не сарказм.