Этот форк https://github.com/artem-russkikh/wireproxy-awg?
В конфигах варпа и протона у вас совпадают параметры Awg (I1,H1 и т.д.), PersistentKeepalive, AllowedIPs или отличаются?
Протон запрещает в бесплатной версии, в платной можно. В варпе можно, см. https://ntc.party/t/можно-ли-скачивать-торренты-через-warp/21872/
Да, тот что Вы посоветовали еще в феврале, мне очень понравился.
Да, все абсолютно идентично кроме адресов конечных точек и портов. Вот как выглядят все мои конфиги, этот в частности для WARP:
[Interface]
PrivateKey = secret
Address = ipv4/v6
DNS = ipv4/v6
MTU = 1280
S1 = 0
S2 = 0
Jc = 1
Jmin = 1
Jmax = 2
H1 = 1
H2 = 2
H3 = 3
H4 = 4
I1 = <b 0xSpecial Init from Mini QUIC Generator><r 16>
[Peer]
PublicKey = secret
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = EP:7156
PersistentKeepalive = 90
Конечную точку подбирал с помощью утилиты Warp Speed Test.
Благодарю, извиняюсь за лень поискать самостоятельно на форуме 
UPD: что характерно, у меня нет рабочей гипотезы, в чем может быть причина. Сервера CF ведь внутри РФ находятся, в отличие от Proton. Иными словами, внимание цензоров должно быть сосредоточено на зарубежных адресах, а не внутренних - иначе это странно. Хотя это можно объяснить проще. Сейчас WARP через AWG набирает огромную популярность, в то время как о возможности подключаться к Proton знает не так много людей.
Собрав документацию по AWG в NotebookLM и натравив на нее LLM, получил правдоподобное объяснение:
Сигнатурный пакет (
I1) и мусор (Jc) успешно обманывают фильтр на этапе инициализации соединения — именно поэтому хендшейки в логе всё же проходят (вы видите Received handshake response ). Однако, как мы обсуждали, ваш основной поток данных (Transport Data) идет совершенно без маскировки, так как ванильный сервер не поддерживает параметрS4и динамические заголовки. DPI пропускает начало соединения, но спустя 20–90 секунд накапливает достаточно статистики по вашему незамаскированному трафику, понимает, что это WireGuard, и начинает дропать пакеты. Ваш клиент глохнет и вынужден начинать всё заново.
Но насколько это соответствует действительности, один бог знает.
Очень похоже на этот баг. Но по идее, должно быть исправлено в последней версии v1.0.16
Тоже об этом подумал и обновился, но ретраи именно с EP WARP остались. С Протоном на более старой версии таких проблем не было.
Попробую потестировать другие конечные точки.
Очередной UPD: изучив закрытый Issue, могу утверждать - баг не связан с моим кейсом и с WARP/Proton over AWG в целом по той простой причине, что упоминаемый параметр S4 (data packets padding) не настраивается на клиентской стороне. То есть баг был исключительно у пользователей Self-Hosted решений.
варпу ниче не надо из мусора, он мешает, даже днс можно или сип пакет в i1, протону белый квик, проблем ровно 0, пока не научатся квик разбирать полностью.
Ясно, значит, мимо. А вы не пробовали уменьшить PersistentKeepalive cкажем до 2-5? Помимо смены эндпоинта и порта. Или подключиться по протоколу masque?
Спасибо, буду пробовать различные варианты. Я Junk в целом на минимуме держал только для совместимости с WG Tunnel на Android, без них клиент не заводится.
SNI из белых списокв на оп. сот. связи имеются в виду (vk, mail, etc) или подбор по ASN с помощью SniFinder?
Частоту KA пакетов снижал до 5 для тестов, не помогло. Usque еще не трогал, буду разбираться. На все тесты потребуется какое-то время. Спасибо!
I1 = <b 0xc6000000010843290a47ba8ba2ed000044d0e3efd9326adb60561baa3bc4b52471b2d459ddcc9a508dffddc97e4d40d811d3de7bc98cf06ea85902361ca3ae66b2a99c7de96f0ace4ba4710658aefde6dec6837bc1a48f47bbd63c6e60ff494d3e1bea5f13927922401c40b0f4570d26be6806b506a9ff5f75ca86fae5f8175d4b6bfd418df9b922cdff8e60b06decfe66f2b07da61a47b5c8b32fa999d8feac21c8878b6e15ee03b8388b2afd9ffd3b46753b0284907b10747e526eebf287ff08735929c4c5e4784a5e2ad3dd8ac8200d0e99ad1219e54060ddc72813e8a3e2291ac713c5f3251c5d748fd68782a2e8eb0c021e437a79aafb253efae3ee72e1051b647c45b676d3b9e474d4f60c7bf7d328106cb94f67eaf2c991cd7043371debbf2b4159b8f80f5da0e1b18f4da35fca0a88026b375f1082731d1cbbe9ba3ae2bfefec250ee328ded7f8330d4cda38f74a7fe10b58ace936fc83cfcb3e1ebed520f7559549a8f20568a248e16949611057a3dd9952bae9b7be518c2b5b2568b8582c165c73a6e8f9b042ec9702704a94dd99893421310d43ffc9caf003ff5fc7bcd718f3fa99d663a8bbad6b595ec1d4cf3c0ed1668d0541c4e5b7e5ded40c6628eb64b29f514424d08d8522ddf7b856e9b820441907177a3dbd9b958172173be8c45c8c7b1816fe4d24927f9b12778153fc118194786c6cf49bc5cf09177f73be27917a239592f9acd9a21150abbd1ca93b1e305dc64d9883429a032c3179e0639592c248cbacec00c90bfb5d5eaf8920bf80c47085a490ead8d0af45f6754e8ae5692f86be02c480ca2a1e6156dccf1bcb5c911c05e3c3a946ca23461669c57d287dcfa9dd187fc6a58394f0b2878c07e1d8cb6be41725d49c118e9ddbe1ae6e5d1a04b36ad98a24f0378deea84febb60b22dc81d8377fb3f21069d83e90b9eba2b6b0ea95acf5fd0482a00d064a9b73e0b3732fde45404e22349a514151381fc6095a8204234359c28765e360a57eb222418b11be704651e4da1b52b135d31ba63a7f06a0f7b8b6177f9bd02fb517877a1340e59d8dbe52ea8135bc80b2aa1959539803a31720ac949c7bf0785c2e413e8b83dd4fd40d8a63fbd832ecb727d0c0df04ce10dac6a7d6d75e264aaf856e7485cc2c4e1749f169e5ad4de6f89a2333e362910dd0d962e3bf59a353df5760fd15956fe32e40f863ea020e9709aa9a9ebeffc885e64231dc6fc384bc6a9e7e5c64c0eaf39f9f14a13658883ee8dd94737cb3a8c2f7020bfacb80f0122866635873e248e22b5a5abc84d507e1720d3fb5f827d75c1d39235a361a217eb0587d1639b0b31aef1fe91958220fcf934c2517dea2f1afe51cd63ac31b5f9323a427c36a5442f8a89b7494f1592666f62be0d8cf67fdf5ef38fafc55b7b4f569a105dfa9925f0a41913c6ee13064d4b83f9ee1c3231c402d68a624e2388e357144be99197dcafb92118d9a9ec6fe832771e12448a146fb5b9620a4718070b368aab646b03cce41ec4d5d9a9c880a9cff06aba991cc0845030abbac87c67255f0373eb38444a51d0958e57c7a33042697465c84abe6791cb8f28e484c4cd04f10791ad911b0dcc217f66cb3aa5fcdbb1e2be88139c4ac2652e469122408feba59ad04f66eb8ab8c80aaf10c2ec1f80b5be111d3ccc832df2395a947e335e7908fda5dcdaa14a61f0fa7156c94b1c96e5c191d850e341adc2e22c8f69fcfa5c3e403eadc933f18be3734bc345def4f40ea3e12>
Оказалось, что дело было не в бобине и стратегии были нормальные, но CF то ли подбанил, то ли подфиксил мне бесплатный ZT ключ и теперь он не коннектится ни к одному эндпойнту. Хотя уже установленное с этим ключом соединение работает второй месяц без обрывов, хочу посмотреть сколько протянет максимум. Случайно ткнул коннект с другим ключом и все тут же завелось, повезло что фейк оказался подходящим.
Кроме того, с этими приседаниями вылезло другое наблюдение: когда упражнялся на заведомо рабочих стратегиях с протоном, то на дебиане и армбиане респонс в 92Б прилетает сразу, а на альпине только спустя несколько секунд, возможно после кипэлайв пакета.
Мне может кто-нибудь выдать базу для пробития протона? Раньше работало через генератор https://protonvpn-converter.github.io но только со случайными значениями J и I1, это было нестабильно и непостоянно, но работало. Сейчас даже так не работает. Конфиги рабочие, по крайней мере через релей работают.
Привет. У меня получилось только через Клэш пробить. Делал следующим образом, брал конфиг от варпа. Первое я удалил строку mtu полностью. Второе j min j max значения уменьшил до минимума. А еще нужно угадать параметр i1 у меня работает только значения «стандартный 1»
На ПК такой способ помог, а вот на андроиде не заводится
База очень простая, меняйте домен маскировки или же i1. Значит те что в конверторе по стандарту вам уже не подходят
Приветствую, сообщение ниже сугубо из моих личных наблюдений.
J(unk)c(ount), Jmin/max сейчас бесполезны. Их можно либо убрать вообще (пример: AmneziaWG на Windows), либо выставить на минимальные значения, если клиент без них не заводится (пример: WG Tunnel на Android). ТСПУ на июль 2026 года нельзя обмануть, закидав рандомными байтами (маскировка). Нужно притвориться легальным подключением (мимикрия), для чего и используется параметр I1.
На сайте конвертера всего 5 вариантов этого параметра, которые выбираются случайно из заранее определенного массива, что наводит на мысль о том, что ТСПУ уже пора бы научиться распознавать множество аномально похожих друг на друга коннектов к хороший-домен.рф, которые летят в Нидерланды.
Решение: используйте Mini Quic Gen для подбора I1. Его прелесть в том, что даже введя один и тот же хороший-домен.рф, вы всегда будете получать уникальный результат на выходе, таковы чудеса криптографии. Кстати, огромный респект участнику NTC @SagePtr за реализацию.
Важный момент: иногда с одной и той же маскировкой может работать Нидерланды-9907, но отваливаться Нидерланды-6554. С чем это связано, утверждать не могу. Возможно, РКН потихоньку банит конечные точки Протона по IP/использует active probing, а может быть, просто происходит ротация адресов на стороне самого Протона. Это не Self-Hosted решение, поэтому аналитика сильно ограничена и разводить демагогию смысла нет.
Из личной статистики, уже умерло 3 сервера в одной локации.
Что хочу этим сказать - собирайте как можно больше доступных конфигов для нужной локации, чтобы было из чего выбирать и перебирать.
ну кстати awg 2.0 у меня работает вообще без I1, там судя по всему, все пакеты притворяются, что они не wg
но там нужен отдельный сервер для всего этого. (в варп/протон это не засунешь)
Если Вы не используете Custom Protocol Signature (I1-5), то по сути тут скорее речь о маскировке, чем о мимикрии.
Но действительно, во второй версии протокола AWG внесены изменения, которые кардинально затрудняют работу как сигнатурных фильтров (теперь заголовки всех пакетов, начиная с хендшейков, cookie reply и, собственно, пакетов с данными генерятся динамически), так и статистического анализа за счет паддинга (динамическое изменение размера за счет рандомных байтов) абсолютно всех типов пакетов, а не только хендшейков, как это было в версии 1.0-1.5.
Как выглядит Ваше подключение со стороны ТСПУ? Наверное, как какой-то хаотичный UDP поток, который невозможно однозначно идентифицировать. Почему фильтр его пропускает - вопрос хороший, но я рад, что у Вас пока все работает.
Имхо, на win самый удобный способ подбора через wiresock т.к. там в конфиге прописывается домен, а не i1. Таким образом можно сразу множество доменов перебрать. Ну и сам конфиг протона лучше скачать свежий, убедившись, что срок действия не закончился и сам сервер не перегружен
В общем подох таки у меня ZT коннект, отработав на одном хендшейке с середины мая без нескольких дней два месяца. Куда уж стабильней. После реконнекта завелось и на остальных устройствах, по видимому просто глюк на стороне CF был.
у меня нет доступа к тспу, чтобы понять как оно там идентифицируется. я просто потыкал платную амнезию и там заполняются s1,s2,s3,s4,h1,h2,h3,h4,jc,jcmin,jcmax вместо I1-5
но это немного оффтоп для этой темы)