Ошибка CF_HAPPY_EYEBALLS_MITM_FAILURE (Cloudflare WARP через zapret-youtube-discord-1.8.1)

Censorship circumvention methods & software Tunneling software
,
1

Всем привет!

Предыстория:

Я давно и успешно пользовался связкой GoodbyeDPI (в данном случае zapret) + Cloudflare WARP. Без обходчика DPI мой провайдер (Telenet) просто не дает WARP подключиться. Мне это нужно было для дополнительного уровня приватности и для того, чтобы не поправлять каждый раз листы доменов и IP.

Все работало как часы до сегодняшнего утра.

Суть проблемы

Сегодня с утра Cloudflare WARP перестал подключаться и выдает ошибку:

CF_HAPPY_EYEBALLS_MITM_FAILURE

Я практически уверен, что это какие-то новые “улучшения” на стороне провайдера или его системы ТСПУ, так как я в своих настройках ничего не менял. Ошибка, судя по названию, указывает на атаку типа “человек посередине” (Man-in-the-Middle), что в данном контексте, скорее всего, означает вмешательство системы глубокого анализа трафика провайдера.

Моя конфигурация (которая работала до сегодня)

  1. Инструмент: GoodbyeDPI (сборка zapret-youtube-discord-1.8.1, батник general (ALT3).bat).

  2. Домены в list-general.txt (добавлены для максимальной совместимости с сервисами Cloudflare):

    one.one.one.one
cloudflareaccess.com
cloudflareportal.com
cloudflareclient.com
cloudflareok.com
zero-trust-client.cloudflareclient.com
cloudflare-dns.com
cloudflarecp.com
www.msftconnecttest.com
captive.apple.com
connectivitycheck.gstatic.com
engage.cloudflareclient.com
connectivity.cloudflareclient.com
time.cloudflare.com

  3. IP-адреса в ip-lists.txt (собраны из разных официальных и неофициальных источников):

    # Список IP-адресов Cloudflare WARP из репозитория moohr
# https://github.com/moohr/cloudflare-warp-ip-ranges/blob/main/main.txt

# Плюс, добавленные вручную IP из официальной документации Cloudflare (https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/deployment/firewall/)

# Cloudflare WARP Ingress
162.159.192.0/24
162.159.193.0/24
162.159.197.0/24

# Cloudflare API
162.159.137.105
162.159.138.105

# Cloudflare DoH
162.159.36.1
162.159.46.1

Вопрос к сообществу:

  1. Кто-нибудь еще столкнулся с подобным сегодня или в последние дни?
  2. Может быть, Cloudflare сменил какие-то IP-адреса, и мои списки устарели? Или это действительно провайдер начал как-то по-новому анализировать и блокировать протокол WireGuard/WARP, даже сквозь GoodbyeDPI?
  3. Есть ли какие-то идеи, как это можно диагностировать или обойти? Возможно, стоит попробовать другие параметры для GoodbyeDPI?

Буду благодарен за любые мысли и помощь.

2

так а какая стратегия используется для ip-lists.txt?
и какой эндпойнт установлен для warp? если никакой, то дефолтный вы можете посмотреть в ProgramData\Cloudflare\conf.json и проверить его на соответствие вашему списку

3

Смею предположить, что Вы сможете подключиться через CF Warp и без такой сложной схемы обхода блокировки. Для начала надо понять, что же все-таки реально не работает через Вашего провайдера. Совершенно точно заблокирована возможность регистрации нового клиента, но Вам неактуально, потому что Вы уже зарегистрировались. Далее обычный CF Warp пытается по умолчанию подключаться к своему Endpoint’у по протоколу MASQUE (с автоматическим переходом с quic на http2 при невозможности подключения по http3). Endpoint по умолчанию engage.cloudflareclient.com:2408
Есть провайдеры, где в ТСПУ заблокирован доступ до этого адреса, есть и такое, что работать начинает, но обрывается после 16 килобайт. Но кажется это не Ваш случай?

Проверьте, что же все-таки у Вас не подключается. В качестве альтернативы попробуйте usque - это консольный клиент, позволяющий на Windows подключаться к CF через http/socks5 по MASQUE. Ну и почитайте ветку форума про Warp

4

Спасибо за наводку!

Отвечаю по пунктам:

  1. Стратегия для IP-адресов в моем батнике:
 --wf-tcp=80,443,%GameFilter% --wf-udp=443,50000-50100,%GameFilter% ^
--filter-udp=443 --hostlist="%~dp0lists\list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%~dp0bin\quic_initial_www_google_com.bin" --new ^
--filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^
--filter-tcp=80 --hostlist="%~dp0lists\list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^
--filter-tcp=443 --hostlist="%~dp0lists\list-general.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 --new ^
--filter-udp=443 --ipset="%~dp0lists\ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%~dp0bin\quic_initial_www_google_com.bin" --new ^
--filter-tcp=80 --ipset="%~dp0lists\ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^
--filter-tcp=443,%GameFilter% --ipset="%~dp0lists\ipset-all.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 --new ^
--filter-udp=%GameFilter% --ipset="%~dp0lists\ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=10 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="%~dp0bin\quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2
  1. Посмотрел conf.json, мой текущий эндпойнт - 162.159.192.9.
"endpoints":[
    {"v4":"162.159.192.9:2408", "v6":"[2606:4700:d0::a29f:c009]:2408"},
    {"v4":"162.159.192.9:500", "v6":"[2606:4700:d0::a29f:c009]:500"},
    {"v4":"162.159.192.9:1701", "v6":"[2606:4700:d0::a29f:c009]:1701"},
    {"v4":"162.159.192.9:4500", "v6":"[2606:4700:d0::a29f:c009]:4500"}
]

Этот IP входит в мой список и как 162.159.192.0/23, так и 162.159.192.0/24, так что правила GoodbyeDPI должны к нему применяться.

Хотя. на этапе просмотра, я так подумал: а может это из-за того, что я не указал в конфиге (параметр --filter-tcp=…) специфичные порты для WARP?

5

от этих стратегий хочется плакать горючими слезами…
тем более, что указанного тобой ip-lists.txt тут нет.

и да, почему warp у тебя работает в режиме WG? это не стандартный вариант (я у себя обновил до последней версии клиент и не смог воспроизвести), верни обратно на quic, как написано тут

т.е по пути Program Files\Cloudflare\Cloudflare WARP нужно открыть в проводнике CMD и написать
warp-cli tunnel protocol set MASQUE
проверь после этого подключение

для WG у тебя в конфиге ничего нет кроме последней строки, но и то она кривая по всем параметрам.

6

А что если попробовать вообще без zapret’a?

vpn-клиент Karing + конфиг отсюда. Суть в том, что там и так фейк-пакеты отсылаются, может этого и хватит.

7

Сбросил настройки, вписал команду warp-cli tunnel protocol set MASQUE открыв cmd там, где вы сказали, и всё заработало. Благодарю за помощь!

8

О, вот WARP конфиг для Nekobox я бы подтянул. Благодарю за ссылочки!

9

Nekobox не умеет в обфускацию. Тогда уж Throne(то же самое почти, только с обновлениями).

10

пожалуйста. а перед возникновением проблемы было обновление варпа? или оно само по себе перестало работать?

11

Нет, не обновлял. Не было проблем. Я обычно увожу РМ в спящий режим. Вот перестало работать после очередного увода в спящий режим.
Когда перестало работать, я сделал следующее:

  1. Закрыл, открыл с правами администратора. (не помогло)
  2. Перезагрузил РМ дважды.
  3. Обновил (не помогло)
  4. В GUI сбросил ключи шифрования (вкладка “Подключение”. (не помогло)
  5. Попробовал различные предустановленные стратегии обхода из zapret (не помогло)
  6. Попробовал выполнить перезапись учётки командой warp-cli register.
  7. Затем я по совету с r/cloudflare попробовал “Сбросить все настройки” в GUI и только после этого оно заработало.
  8. Ну и вот после этого я ещё попробовал ввести вашу команду warp-cli tunnel protocol set MASQUE, после чего всё заработало без zapret.

Правда до сих пор почему-то отваливается API.

image
image332×172 6.05 KB

12

del ошибся)

13

опять же это зависит от конкретной ситуации. У меня МГТС для организаций, сеть такая, что и quic не работает никакой, и 1.1.1.1 на уровне DNS заблокирован, и все известные DoH-сервера заблокированы. Но достаточно только обойти блокировку первоначальной регистрации нового клиента (можно и не через zapret, а просто подключившись через какой-нибудь vpn, хотя через zapret лучше), и как только появляется рычажок Подключить, подключение происходит, в первый раз долго, потом уже довольно быстро. Все пункты в разделе Подключение зеленые, DME. Ясно, что работает через MASQUE с переходом на http/2, так как http/3 не работает. Дальше все штатно, немного напрягает только то, что на медленном компьютере при неактивности пользователя довольно долго переподключается при возврате к работе. Это не сон, это просто неактивность пользователя. Что довольно странно.

14

ему, видимо, сейчас достаточно доступа к апи внутри туннеля. например, если исключить api.cloudflareclient.com из обработки warp, то доступ пропадает, а впн подключается.

Спойлер

изображение
изображение343×158 6.05 KB

я бы тогда автору посоветовал убедиться, что у него zapret/gdpi не работает в системе (например, на уровне службы)
или попробовать обновить клиент до последней версии
других идей у меня нет и разбираться с корпоративными сетями тоже нет желания)

15

В данном случае я настраивал чисто непривязанный к личной жизни VPN на работе (так то я для себя использую v2raytun, ByeByeDPI и Nekobox на соответственных устройствах), 1.1.1.1 тут тоже заблокирован, но при этом quic работает (иначе бы я не сидел и не писал это вчера на ntc.party).

16

Эта же ошибка - cf_happy_eyeballs_mitm_failure

Но как-то странно. Напрямую работает без проблем, но как только включаю режим прокси-сервера - варп не пашет и вылазит вот эта ошибка. Отключаю режим прокси - варп работает штатно.

Тестирую на виртуалке, добавлял в исключения, фаервол и антивирь отключал и на виртуалке, и на домашней машине. Совсем недавно прокси-режим работал нормально, несколько дней не запускал виртуалку, запустил и вот такое…
Парни, ткните носом где копать!

варп
варп813×523 63.4 KB