Comments 118
Отличный проект и интересная идея! Было бы здорово увидеть демонстрацию его работы в действии. Небольшой пример или скринкаст помогли бы читателям наглядно оценить функционал и убедиться в эффективности решения.
IP-адрес лучше всё-таки замазать.
Есть ли решим локального прокси? Чтоб я сам мог решать какой трафик маскировать путем направления на 127.0.0.1:port
Как у ByeDPI, например
Братское сердце, благодарю тебя за такую крутую фичу, блин реально решил и избавил от головной боли, с удовольствием отправил тебя донат во благо развития.
Всем привет. У меня очень похожая идея - great minds think alike ;) - но существенно проще. Суть ее в protocol-less коммуникации (обфусцированной, ясен пень), плюс случайный балласт чтобы нельзя было обнаружить паттерн. И тоже US патент ... Работает на всех платформах + CLI и часто обходит блокировки. beta.p4pn.net. Ищу единомышленников. Пишите michael@pastushkov.com - тестирование в РФ нужно как водух!!
Звучит очень круто) надеюсь у вас все получится )
Большинство кто из России только одно интересует. Гуляет ли через белые списки и работает ли вообще. А свистоперделки они так и будут свистоперделками, если не работает.
Проблема белых списков решается не навороченным впн, а наличием сервера, который в эти БС входит. Без этого, можно как угодно маскировать и шифровать - не поможет.
Ну а если такой сервер есть, то и существующих протоколов хватит. По крайней мере пока
Я не шарю , но правильно ли я понял , что если белые списки введут , то обойти у всех уже не получится? Под всеми я имею ввиду , что даже домохозяйки ставят vpn и заходят в телегу.
Да. Смысл белых списков это сходу не пускать никуда кроме как туда куда это явно разрешено. Там в общем случае до этапа когда мы начинаем мимикрировать под что-то даже не дойдёт. В принципе тут тоже есть свои хитрости но они уже посложнее будут.
Да. И это пока только на мобильном. Если врубят БС для проводного - всё, туши свет. Это будет чистейший чебурнет, даже Китай будет нервно курить в сторонке.
Вроде даже сейчас у коммерческих VPN все работает с БС. (Поправьте, если я не прав, просто мне самому БС сложно проверить).
Насколько я понимаю, там есть непреодолимая сложность. Было бы очень просто сделать тупо белые списки по IPv4 адресам. Это бы быстро работало, жрало бы мало ресурсов, и было бы принципиально непреодолимо. Но есть запердыка - их не составишь. Нельзя описать живой организм. Какой-нибудь Сбер или Озон может постоянно запрашивать у хостера новые серваки пачками, а они же не в БС - значит, они не будут работать. Как решение - в БС вносятся не конкретный длинный и точный список IPшников, а сразу все огромные подсети хостера.
То есть, если (от балды говорю детали) Озон хостится на VK Cloud, и поэтому весь этот VK Cloud разрешен для Озона. VPN который обходит это - тоже покупает хостинг на VK Cloud и притворяется Сбером.
Ну и БС сейчас работает на мобилах не по чьей-то гуманности и доброте, а потому что с мобильниками просто люди ходят. Если человек не может вызвать такси - ничего страшного, перебьется. А вот проводный Интернет - это уже, в том числе, бизнес. Если малый бизнес сможет заходить только на разрешенный властями Озон, то как вам этот малый бизнес добудет китайские трусы и носки, смартфоны и чехольчики чтобы выложить их на этот Озон? Чтобы их добыть, надо иметь свободный интернет, читать много разных сайтиков, общаться с зарубежными поставщиками (и не в Максе, их ведь в Макс специально не пускают). Так что, введение БС для проводного интернета выглядит гораздо более болезненным.
если детектят что к серверу из БС идёт впн-трафик, то применяют санкции. Так что протоколы тут нужны не детектируемые
Из белосписочной виртуалки в облаке яндекса/вк можно трафик перегонять на российский VPS который вне БС, а уж с него перекидывать дальше зарубеж. Наверно, палева будет меньше. Но мне кажется, что эти облака вскоре тотально пофиксят, а удачливым людям IP заменят на другие, вне диапазонов БС.
Я вот жду когда уже сделают КВН мимикрирующий под Макс, передавая через их сервера данные в виде аудио/видеозвонка. Конечно, придется иметь целых два аккаунта, с которого звонишь (для клиента на телефоне), и кому звонишь (серверная часть). Да и сходу видится возможность детектирования таких звонков по длительности, необычному содержимому, от чего аккаунты вмиг забанят. Но как мысленный эксперимент забавно.
Мне другое интересно. В Максе скопировали телеграмную фишку с безлимитным серверным хранилищем?
Вот введение рутуба имело и положительный эффект - можно было перелить все свои видео на рутуб. (А то вдруг на ютубе что-то случится, удалят отдельное видео или весь канал, аккаунт). Бесплатная резервная копия - это всегда хорошо!
Подходит ли Макс чтобы хранить там что-то? У меня например личный криптоконтейнер в 100 гигов - его туда можно положить? (он шифрованный, так что пусть читают, я не против)
Уже есть туннели через звонки. Недавно видел статью, где через ВБ конференции прокидывали туннель, а ещё раньше через ВК звонки и Яндекс телемост
Ну, в таком случае правильно было бы на уровне клиента (если таковой есть) использовать сторонние vpn решения по открытым сервакам (их главная, пока что, проблема - постоянная ротация списков). Тогда и vpn будет исполнять и доступ, и защиту одновременно
Очень было интересно прочитать, будем следить за прогрессом.
Идеи выглядят новаторскими, а относительная зрелость продукта (не просто реализация протокола, но и клиенты есть!) подкупает. Метод работы понятен, про архитектуру хотелось бы узнать больше. У вас ядро, модуль, библиотека? Оно может и как сервер, и как клиент работать, или реализации у них разные? Формат конфигурации?
Не хватает также сравнений (желательно по архитектуре и методологии) со связками XRay/VLESS/XTLS-Reality/xHTTP или Sing-Box/NaiveProxy. Рассматриваете ли возможность часть своего функционала распилить на подобные связки или, наоборот, взять что-либо из наработок оттуда к себе.
Также интересуюсь, есть ли возможность интеграции в вышеобозначенные ядра в виде outbound и inbound в их конфигурациях.
Хотелось бы чтоб было как в Nekobox встроенный режим прокси, и ты в программах, которые хочешь чтоб работали через ВПН указывал бы этот прокси....
А что по скорости? Накладные расходы выглядят солидно - есть какие-то тесты скорости в спокойных условиях и в условиях постоянного переключения масок? Как часто в теории могут переключаться маски? Есть ли мультиплексирование и, наоборот, объединение всех соединений в одно?
мимикрировать под dns over udp звучит весьма странно, разве не вызовет подозрение мегабитные потоки типа dns-трафика между домашним подключением и одним сервером?
Думаю, это легко обнаружить, но.... все равно стоит сделать! Потому что детектор для нее все равно будет требовать ресурсы и жрать их на каждый DNS запрос. Просто написав код, который однажды, скажем в июне 2026 года будет работать, а уже к июлю 2026 на всех DPI включат его блокировку - на следующие 500 лет стоимость ТСПУ будет чуть выше. Программист реализует технологию один раз, а РКН оплачивает ее блокировку каждый день, вечно.
Ее не РКН оплачивает, к сожалению.
Тспу оплачивают провайдеры услуг связи, а деньги они берут из карманов пользователей через удельное удорожание тарифов.
ТСПУ оплачивает ГРКЦ к счастью, а живет оно на налоги. А вот СОРМ и Яровая - это да за счет пользователей.
А монтажные и ремонтные работы? А переделку системы коммуникаций для интеграции в неё этих хреновин? А эксплуатационные расходы (электроэнегрия, аренда помещений)? Тоже гркц? Очень сомнительно.
Ну этот комплекс ставится в разрыв (это про систему коммуникаций) - и тут затраты стремятся к нулю, максимум замена модулей.
Для про провайдера это черный ящик с входами и выходами - так что весь ремонт и мониторинг силами ГРКЦ
Монтаж заключается в предоставлении ГРКЦ стойкоместа.
Эксплутационные расходы - касательно аренды - это стойко места и для разного рода правительственных хотелок уже заложены отдельные стойки.
Единственное это электричество - но это на столько малая часть в стоимость интернета, что оно обычно входит в плановое ежегодное повышение тарифов
По-моему, сейчас если твой трафик палится, то под подозрение сразу падает айпи, на который этот трафик идёт. В особенности, если на один и тот же адрес много такого подозрительного трафика. Соответственно, поможет ли смена масок, если душат уже скомпроментированный айпи. В таком случае стоит добавить балансировку и комбинировать смену масок и айпи адресов.
На практике вроде нет, мой IP должен уже давно светиться как новогодняя елка, но тем не менее продолжает работать у нас в зависимости от протокола. Более того адрес попался неудачный, с высоким фродрейтингом и забанен во многих местах снаружи как раз по адресу. Пришлось еще дополнительную ВПСку брать на блокировку оттуда в непопулярной локации. Даже возникает теория заговора, может в РКН кто-то хостингами владеет...
Я вот тут тоже немного удивился. У меня есть машина, там xray на xhttp спрятан за nginx и статикой, редирект /secret/ на инбаунд , на клиентах раздельная маршрутизация. Эту машину спалили, и подслушивают уже неделю, вплоть до невозможности установить SSH. Она прожила 3 месяца.
А есть вторая машина, там xray на /, там нет даже сертификатов, нет домена, инбаунды на случайных портах. Ссылки выглядят vless://IP:port/....., каждый инбаунд - свой порт. И эта машина уже 2 года пашет, единственный раз sni пришлось поменять в том году.
каким образом спалили машину на xhttp и спрятанным за nginx xray ?
У меня такая же конфигурация пашет и я думал это самое надежное на данный момент решение
Прошу прощения, я не всю правду сказал. Помимо вышеописанного, там ещё работал telemt. Так как пути телеграм не поддерживает, бюдля него был свой поддомен, и sni-модуль nginx отправлял запросы для этого домена на порт telemt, остальное отправлял в nginx, где уже разруливались пути.
Так вот, единственное моё предположение, что спалил машину не xhttp, а полсотни пользователей телеграм, которые 1 апреля в едином порыве стучались на домен с палевными ClientHello. Полагаю, что цензор заметил это, чекнул IP и сделал вывод, что тут работает нежелательное ПО и добавил мой IP в список проклятых.
По таймингу совпадает
Мои конфигурации через мосты на xhttp + self sni, рутингом и extra работают нестабильно. Периодически таймауты. Минут 7 пашет, а потом выбивает. Уже и не знаю, как фиксить, разные варианты перепробовал.
На одном конфиге помог переход на tcp (raw) + vision
Из удивительного пока все ковыряют эти xray, крутят вертят прячут, у меня коробочная поставка openvpn живёт около 7-8 месяцев до бана, после которого на ней даже веб морда не открывается, потом в той же локации берется новый сервер и поехали заново
Ставлю на шейпинг подсети
Предлагаю Вам ещё более лучшую © идею для маскировки
Подавдяющее большинство современных протоколов ориентированы на статическую сигнатуру (например: «если первый байт — 0×50, а второй — 0×4B, то делаем то‑то, а иначе не делаем»). В то же время ничто не запрещает использовать динамическую сигнатуру (утрированный пример: «если взять первый байт пакета, к нему приплюсовать 15-й байт пакета, и сделать XOR с 118-м байтом пакета, вычесть байт секретного ключа сервера — и в результате получился байт, у которого первая цифа равна текущему часу, а вторая — текущему дню недели, то это попытка установления VPN‑соединения по нашему секретному протоколу, и на неё надо ответить похожим хитрозакрученным образом, а иначе не надо»). Желаю ТПСУ удачи понять, что это сигнатура.
Более того, такой «хендшейк» элементарно прятать, скажем, в совершенно нормально выглядящем JS, HTML, GIF...
Вот тоже думаю все изобретают сложности с https и сертификатами, а почему нельзя просто по 80 порту и протоколу http гнать странички типа <script>let js="skadjhfuiyrewihkdsc...";</script> где в js шифровать все что хочешь.
Вы видимо не представляете какой "приятной" скоростью будет обладать данное решение. Не говоря уже о накладных расходах
Есть например логины в софте, где скорость не важна. Опять же месенджеры. Как второй железобетонный канал по идее жизнеспособно в специфичных случаях.
Ну давайте еще перейдем на старые методы доставки как у малвари, через TXT записи DNS. Проходить будет вообще все
Вы это с сарказмом написали, а мне это кажется хорошей идеей. Медленно? Да. И пусть. Пусть будет быстрый КВН (будем им пользоваться) и вот этот вот медленный (про запас).
Медленный но надежный нужен хотя бы для bootstrapping, ибо "чтобы скачать КВН, тебе нужно иметь КВН!". Как подключать новое устройство, если все ПО и конфиги - в телеге, а телега не пашет? Хоть DNS тоннель, хоть через пинги, пусть хоть час выкачивает 10 мегов, но чтоб хоть как-то был рабочий способ.
Да, как ниже написали, для актуализации конфигов очень неплохой вариант.
И кстати в августе это было единственным рабочим вариантом выйти в глобальный интернет, тогда даже белых списков не придумали. Я даже Ютуб смотрел, хоть и на 480p, но зато при нулевом балансе, когда открывается только сайт оператора
Возможно это ждет нас впереди.
Идея на самом деле здравая. И для мессенджеров её хватит с лихвой. Если не использовать web движки js и т.п., а просто использовать html документы и передаваемые "картинки", как криптоконтейнеры. Т.е. сервер будет заточен на генерацию примитивных html документов с минимальными накладными расходами. Приложение на стороне клиента будет получать такой документ, детектировать в нём криптоконтейнер и расшифровывать. Вопрос в том, что ТСПУ тоже будут постепенно учиться детектировать всё разнообразие таких криптоконтейнеров. И хватит ли им мощности и способности различать такие контейнеры от легального http трафика, завёрнутого в https?
С другой стороны, уже хватает протоколов, которые мимикрируют под https, но между тем, ТСПУ большую часть этих протоколов научился распознавать?
Так в том‑то и хохма этой идеи, что не нужно облегчать ТСПУ задачу: «взять N первых байт пакета и сравнить их с известными значаениями» — это для любой железяки плёвое дело; а вот «смотреть на 100500 пакетов, зная, что какие‑то из них КВН‑овские, но при этом все они выглядят как совершенно обычные HTML/JS/GIF» и пытаться понять тот самый вышеописанный секретный танец — это уже задача уровня «Бог».
Кто-нибудь пробовал уже делать обратный впн, когда ваш виртуальный сервер за границей, возможно даже без белого ip4 адреса, сам подключается на впн сервер в рф? Дальше всё работает как обычно потому что клиентам внутри туннеля всё равно кто сервер а кто клиент у транспортного туннеля.
У друзей моего знакомого вроде такое работает. Обычный OpenVPN причём
У меня так обычный WG работает. Если назначаю сервером точку в России - работает. Если назначаю сервером точку вне России - не работает. Будет ли работать при БС - не знаю, у нас их пока нет
Я свой Unifiexpress так подключал, работает, но он не умеет натить в данном сценарии трафик обратно, а так оттуда все пингуется, что здесь стоит
и сразу копию в РКН отправляйте чтобы им удобней было, не нужно хабр читать в поисках новых способов обхода
Этот "впн" и не поможет от РКН. Цель статьи - собрать денег
Смотрел с точки зрения открытого кода как если я бы был блокираторатором и у меня был доступ к исходным кодам + написал жесткий эмулятор DPI и тестировал на нем, публичное размещение это хорошо, будет много форков, поменяют маски, чуть приложат свои идеи и будет новые протоколы со своими особенностями, даже если будут белые списки уверен что найдутся способы работы через них.
Форкнул, покопаюсь, потестирую под нагрузкой. Если будут мысли о полезных коммитах - дам знать. Автор - красавчик, спасибо!
1. Нет открытого идентификатора сессии
Каждый пакет несет короткий криптографический тег, а не постоянный открытый идентификатор. Это уменьшает заметность протокола и позволяет серверу быстро находить нужную сессию без лишнего служебного шума.
Но идентификатор сессии все же есть и он не уменьшает заметность протокола. Про "быстро" мы поговорим ниже...
2. Малозаметный старт соединения
Я сознательно уходил от тяжелого и очень заметного рукопожатия. Клиент может начать обмен сразу, а сервер уже по первому пакету пытается восстановить сессию и проверить ее корректность.
Смысл не в том, чтобы «вообще убрать рукопожатие», а в том, чтобы не оставлять снаружи простой и стабильный шаблон, который удобно определять DPI-системам.
Тяжелое и заметное рукопожатие как раз и нужно, причем рукопожатие которое соответствует HTTPS(вы же используете 443 порт), для того чтобы DPI не пометила пакеты и соединение как подозрительное для дальнейшего анализа.
3. Маскировка под реальные типы трафика
В AIVPN есть маски трафика. Маска задает не только внешний заголовок, но и поведение потока:
какие размеры пакетов встречаются чаще;
какие интервалы между пакетами выглядят правдоподобно;
как меняется поведение трафика во времени.
Сейчас в проекте есть профили, ориентированные на трафик вроде:
QUIC;
WebRTC/STUN;
DNS over UDP.
То есть задача не в том, чтобы просто зашифровать UDP, а в том, чтобы сделать его менее похожим на типичный VPN-трафик.
Скорость у такого решения будет еще хуже чем у OpenVPN... Про профили конечно повеселило - это же явный признак для DPI чтобы пометить весь такой трафик. WebRTC/STUN - так WebRTC или STUN? Если WebRTC - то сигнатура чего - сигналинга, RTP-потока? WebRTC/STUN и DNS over UDP - это 2 сигнатуры, которые палятся на раз ввиду того, что в виде постоянного соединения не используются(кроме RTP-потока)
4. Нейронный резонанс
Самая необычная часть проекта —
Нейронный резонанс, если по простому я нашел способ определение типа задач быстро без сложного инференса, что практически мгновенно определяет что это за задача и реакцию на неё.
Товарищи "новаторы" отстаньте вы уже от резонанса и хватит его пихать куда ни попадя...
Но здесь нет никакой огромной LLM, которая живет на VPS и съедает память.
Но которая будет неистово жрать проц)))
5. Автоматическая смена маски
Если сервер замечает, что текущая маска стала подозрительной или сеть начала ее явно душить, профиль помечается как скомпрометированный, а сессия переключается на резервную маску.
Это одна из главных фишек проекта. Обычный VPN часто живет по схеме «пока работает — работает, а когда спалили — все умерло». В AIVPN идея другая: если один профиль начали ломать, туннель должен попытаться перелинять, а не просто упасть.
DPI не просто сначала чуть хуже делает соединение, она просто берет и рубит его и IP сервака заносит в ЧС. Причем перед этим собрав всю информацию о пакетах. Так что потом смена сервера не поможет
6. Нормальная криптография без экзотики
Я не пытался изобрести собственную криптографию. В основе используются понятные примитивы:
X25519;
ChaCha20-Poly1305;
BLAKE3.
Плюс есть ротация сессионных ключей, чтобы не держать слишком большой объем данных под одним и тем же ключом.
Которая палится по высокой энтропии трафика...
Было бы интересно ещё интегрировать это в панели типа Remnawave или 3X-UI, конечно
Интегрировал в свою web панель https://github.com/infosave2007/amneziavpnphp
Идея хорошая, даже отличная, но говорят, что под "подозрение" попадёт скоро весь иностранный трафик¹, тогда даже эта идея уже не поможет, не считая самого чебурнета, который в этом случае будет уже не нужен если "дорогу" народу просто закроют.
¹ кажется где-то на этом ресурсе я такое вычитал, что касается чебурнета, "необходимость" в нём пропадёт если следить за каждым битом информации, что физически невозможно реализовать ни кому, а обрубать физически ни кто не станет, тогда и импорта ни какого не будет, ну если только "наши торовые партнёры" не согласятся перейти или подключить наши интернет протоколы, которые бы были бы прозрачны "для кого надо", как это произошло с системой карты Мир.
Извиняюсь за тупой вопрос, но где брать connection key? Я тупенький и новичок в теме
Посмотрите инструкцию https://github.com/infosave2007/aivpn/blob/master/README_RU.md
Из вашей же инструкции
Провайдеры и GFW (китайский файрвол) палят WireGuard и OpenVPN за доли секунды по размерам пакетов, интервалам и хэндшейкам. Можете шифровать трафик хоть тройным AES — DPI-системам плевать на содержимое, они блокируют саму форму соединения.
Лично пользуюсь одним VPN-провайдером у которого работают и Wireguard(AmneziaWG) и OpenVPN с кастомным шифрованием))
Подскажите как обойти бс, мегафон не пускает, другие операторы пускают, взял впс с белым айпи
Написать в РКН чтобы они подобрели и добавили твоего провайдера в белые списки. Не забудь сказать что нужно для обхода блокировок
Идею как-то уже подкидывал. Для реализации, к сожалению, не хватает компетенции. Если кто-то сможет реализовать, буду весьма признателен. Яндекс-телемост работает через БС. Цель - сделать аналог удаленного рабочего стола через Яндекс-телемост. Где-то (на сервере или на домашнем компе) подключаемся к телемосту, и с мобильного интернета подключаемся к этой же конференции. Демонстрировать звук и рабочий стол телемост умеет из коробки, осталось передать в обратную сторону команды клавиатуры и мыши. И делать это надо либо через звук, либо создавать еще одну конференцию и передавать через видео. Только безо всякой стеганографии - иначе вопрос блокировки - дело времени.
Хотелось бы знать требования к железу для сервера.
VPS 1G 1vCPU 10GB подойдет, скорость соединения будет примерно -30%
Вы же покажите видео замеров скорости при включенном вашем ВПН на такой VPS?
И с выводом top на сервере
А без NAT можно? Большинство работают без него.
Чет мне кажется всё это по сути бесполезно, когда у нас заблокирована большая часть международного интернета приходится пускать большую часть трафика через КВН и как раз это очень хорошо видно, как это не масикируй...Тут только распределенная сеть на подобии TOR в теории может помочь, но с маскировкой трафика защитой от DPI...
Я так понимаю, что это все-таки прокси протокол, а не “классический” VPN
Основная суть в том, что VPN/прокси по своей концепции, это не средство обхода блокировок(весь концепт VPN/прокси не про это изначально). Его использование это для этой цели - это по принципу “взяли уже имеющиеся хорошие плоскогубцы и забиваем ими гвозди, пока это получаеться”.
VPN/прокси как средство обхода блокировок это говоря образно некий “Неуловимый Джо”(который неуловим, лишь постольку поскольку, поскольку, и пока никто в серьез этим не занят, хотя как его ловить понятно). По части детекта факта применения VPN/прокси имеет концептуальный патерн - специфичный маршрут трафика.
Так, например, цензуре нет нужды проверять насколько реалистично Ваш, к примеру, “VLESS + Realiti” в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
Тоже самое про другие VPN/прокси применяемые как средство обхода блокировок - прячем "мух"(специфику пакетов), а "слон"(крайне специфичный маршрут трафика) виден всем желающим. Его то в 2026 году в РФ и начали "рубить" и технически(падеж стелс-VPN/прокси по мере апгрейда ТСПУ), так и экономически - решением о заградительных тарифах на трансграничных трафик конечного пользователя.
Гораздо больший потенциал как показывают и теория и практика имеют “неоднокликовые” решения вроде Zapret(которым серверная часть не нужна и как следствие отсуствует слив трафика в специфичный маршрут). Причем трансграничный пиринг инфраструктурных гигантов тарифицируеться не как у пользователя, и если вы обратились фактически например к российским GGC, то ваш трафик для вашего провайдера внутрироссийский.
Всё круто ... Но как же Android/Windows саппорт ? Ждём реализации проекта и в этом направлении!
Интересная идея, но у меня есть два предложения.
1. Мне кажется, архитектурно можно сделать лучше. Не надо заменять уже имеющиеся технологии, надо дополнить их. Как пример - сделать просто свой TCP тоннель, сокет тут, сокет там, все как делает telnet/netcat, но он должен быть статистически хитрый. Подстраивать размер пакетов, интенсивность. Иногда подтормаживать трафик (да, это неудобно, но если это поможет обойти ТСПУ - пусть). Иногда - добавлять в него мусор (и вырезать мусор на той стороне). В общем - давать просто транспорт, а вот основное щифрование и укладку пакетов в этот транспорт пусть делают другие приложения. Чтобы разделить функции. Может быть сделать это как-то на уровне netfilter или даже qdisc (но qdisc вроде не может менять пакеты, только задерживать их).
2. Как выше уже заметили - подстраивать стратегии надо на клиенте, а не на сервере, потому что ТСПУ стоит у клиента. Он один раз находит для себя рабочую схему тоннеля и дальше пусть ее использует с любым поддерживаемым VPN сервером, хоть в Нидерландах хоть в Финляндии.
сделал как написано, но где искать ключ? Для программы на андроид?
Нужно свой сервер поднять и на него установить серверную часть и сгенерить ключи или установить мою панель для управлением VPN серверами и установить через нее https://github.com/infosave2007/amneziavpnphp
Сделал всё по инструкции.
Подтянул проект для андроид-клиента, сбилдил, запустил.
Пофиксил у себя локально проблему с парсингом (точнее, с формированием самого ключа), без фикса которой ничего не работало (и не работает на виндовом клиенте).
Всё завелось, однако интернет не работает(
В логах ошибки/реконнекты вида:
"Tunnel error: Session error: TX without RX: 16446 bytes sent in 45.406373889s since last RX — reconnecting (Fix with AI) java.lang.RuntimeException: Session error: TX without RX: 16446 bytes sent in 45.406373889s since last RX — reconnecting"
к сожалению говорящие сами за себя.
AI я так понимаю не справился?
Это максимально правильное направление, не думал что что-то подобное уже так скоро может появиться. Максимально грамотное и верное направление. Успехов вам с вашим проектом, оно гораздо больше значит как идея, чем очередной VPN для многих.
Планируется ли реализация клиента для роутера? Хотябы OpenWRT?
переехал как уже 4 месяца на hysteria 2
полет шикарнейший инет летает допандемийный 2018 года с маскировкой саламандер ))) про панель 3x- ui и влесс забыл про этв каку которую постоянно нужно ковырять обновлять и следить за этим 🤮🤮🤮🤮
Вчера поборол свою лень и сделал себе бокс на малинке с OpenWRT и V2RayA и списочками получаемыми по крону с runetfreedom. На сервер поставил Marzban. Использую обычный TCP Reality с доменом у которого адрес в подсети с моим сервером. Полет шикарный. Причем настроил антицензор с обоих сторон - наконец-то обновил "по воздуху" свой "зоопарк" из стойки Ubiquity
На гите не нашел в тегах релизов. Он ещё в разработке? Или можно собрать под андроид?
https://github.com/infosave2007/aivpn/blob/master/README_RU.md здесь только смог найти как скачать приложение)
AIVPN: VPN-протокол с мимикрией трафика и автоматической сменой профиля