Project X

Повышение безопасности проксирования с помощью Cloudflare Warp ​

В Xray (1.6.5+) добавлен исходящий WireGuard. Хотя это увеличивает размер ядра из-за дополнительных строк кода и зависимостей, мы считаем, что это важная функция по трем причинам:

  1. Из недавних обсуждений и экспериментов мы знаем, что проксирование трафика в Китай небезопасно. Одним из способов решения этой проблемы является перенаправление трафика в Китай в черную дыру. Недостаток этого метода заключается в том, что geosite и geoip обновляются нерегулярно, и новички могут не знать, как правильно настроить разделение трафика на клиенте, в результате чего трафик попадает в черную дыру, что снижает удобство использования. В этом случае мы можем просто перенаправить трафик в Китай через Cloudflare Warp, что обеспечит такую же безопасность без ущерба для удобства использования.
  2. Как известно, большинство VPN-провайдеров ведут журналы посещенных пользователями доменов, а некоторые даже проверяют и блокируют определенный трафик. Один из способов защиты конфиденциальности пользователей — использовать цепочку прокси-серверов на клиенте. Warp использует легкий VPN-протокол WireGuard, который добавляет дополнительный уровень шифрования. Для VPN-провайдера весь трафик пользователя будет направляться на Warp, что обеспечивает максимальную защиту конфиденциальности.
  3. Простота использования. Для настройки разделения трафика, WireGuard-туннеля и цепочки прокси-серверов достаточно одного ядра.

Создание аккаунта Warp ​

Спасибо Cloudflare за содействие свободному интернету! Теперь вы можете бесплатно пользоваться услугами Warp. При подключении автоматически выбирается ближайший сервер. ​

Метод 1: ​

  1. Используйте VPS и загрузите на него wgcf.
  2. Запустите wgcf register, чтобы создать файл wgcf-account.toml.
  3. Запустите wgcf generate, чтобы создать файл wgcf-profile.conf. Скопируйте его содержимое:
ini
[Interface]
PrivateKey = Мой закрытый ключ
Address = 172.16.0.2/32
Address = 2606:4700:110:8949:fed8:2642:a640:c8e1/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = Открытый ключ Warp
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408

Метод 2: ​

  1. Используйте warp-reg.sh. Запустите:
bash -c "$(curl -L warp-reg.vercel.app)"
  • Вывод:
json
{
  "endpoint": {
    "v4": "162.159.192.7",
    "v6": "[2606:4700:d0::a29f:c007]"
  },
  "reserved_dec": [35, 74, 190],
  "reserved_hex": "0x234abe",
  "reserved_str": "I0q+",
  "private_key": "yL0kApRiZW4VFfNkKAQ/nYxnMFT3AH0dfVkj1GAlr1k=",
  "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
  "v4": "172.16.0.2",
  "v6": "2606:4700:110:81f3:2a5b:3cad:9d4:9ea6"
}
  1. Скопируйте вывод.

Метод 3: ​

  1. Используйте wgcf-cli. Запустите следующие команды для установки:
bash -c "$(curl -L wgcf-cli.vercel.app)"
  1. Запустите wgcf-cli register для регистрации. Вывод:
❯ wgcf-cli register
{
    "endpoint": {
        "v4": "162.159.192.7:0",
        "v6": "[2606:4700:d0::a29f:c007]:0"
    },
    "reserved_str": "6nT5",
    "reserved_hex": "0xea74f9",
    "reserved_dec": [
        234,
        116,
        249
    ],
    "private_key": "WIAKvgUlq5fBazhttCvjhEGpu8MmGHcb1H0iHSGlU0Q=",
    "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
    "addresses": {
        "v4": "172.16.0.2",
        "v6": "2606:4700:110:8d9c:3c4e:2190:59d1:2d3c"
    }
}
  • Полный файл будет сохранен в файле wgcf.json в текущем каталоге.
  1. Запустите wgcf-cli generate --xray, чтобы создать исходящий WireGuard. Содержимое будет сохранено в файле wgcf.xray.json.
  • Пример файла:
json
{
  "protocol": "wireguard",
  "settings": {
    "secretKey": "6CRVRLgFwGajnikoVOPTDNZnDhx3EydhPsMgpxHfBCY=",
    "address": [
      "172.16.0.2/32",
      "2606:4700:110:857a:6a95:fe27:1870:2a9d/128"
    ],
    "peers": [
      {
        "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
        "allowedIPs": ["0.0.0.0/0", "::/0"],
        "endpoint": "162.159.192.1:2408"
      }
    ],
    "reserved": [240, 25, 146],
    "mtu": 1280
  },
  "tag": "wireguard"
}

Перенаправление трафика в Китай через Warp на сервере ​

Добавьте исходящий WireGuard к существующим исходящим подключениям:

json
{
  "protocol": "wireguard",
  "settings": {
    "secretKey": "Секретный ключ",
    "address": [
      "172.16.0.2/32",
      "2606:4700:110:8949:fed8:2642:a640:c8e1/128"
    ],
    "peers": [
      {
        "publicKey": "Публичный ключ Warp",
        "endpoint": "engage.cloudflareclient.com:2408"
      }
    ],
    "reserved": [0, 0, 0] // Вставьте reserved, если у вас есть.
  },
  "tag": "wireguard-1"
}

Рекомендуется использовать стратегию маршрутизации IPIfNonMatch.

Добавьте следующие правила к существующим правилам маршрутизации:

            {
                "domain": [
                    "geosite:cn"
                ],
                "outboundTag": "wireguard-1"
            },
            {
                "ip": [
                    "geoip:cn"
                ],
                "outboundTag": "wireguard-1"
            }

Использование Warp в качестве прокси-сервера в цепочке на клиенте ​

json
{
  "outbounds": [
    {
      "protocol": "wireguard",
      "settings": {
        "secretKey": "Секретный ключ",
        "peers": [
          {
            "publicKey": "Публичный ключ Warp",
            "endpoint": "engage.cloudflareclient.com:2408"
          }
        ],
        "reserved": [0, 0, 0] // Вставьте reserved, если у вас есть.
      },
      "streamSettings": {
        "sockopt": {
          "dialerProxy": "proxy"
        }
      },
      "tag": "wireguard-1"
    },
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "address": "IP-адрес",
        "port": 12345, // Порт
        "id": "UUID",
        "security": "auto"
      },
      "streamSettings": {
        "method": "tcp"
      }
    }
  ]
}

Подключение к Warp через MASQUE ​

WireGuard работает поверх UDP, использует целый набор портов WARP (далеко не только 2408) и охватывает целые anycast-диапазоны; в сетях, где UDP целиком блокируется или ограничивается по скорости, он может оказаться недоступным. В таком случае для подключения к тому же Warp можно вместо него использовать MASQUE (CONNECT-IP, RFC 9484): он работает внутри TLS поверх HTTP/2 (TCP) или HTTP/3 (QUIC), так же как официальный клиент Warp.

Используйте исходящее подключение MASQUE, а настройки укажите в streamSettings.masqueSettings.warp.

WarpObject ​

json
{
  "warp": {
    "privateKey": "MHcCAQEE...",
    "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...",
    "address": ["172.16.0.2/32", "2606:4700:110:8a36::2/128"]
  }
}

  • privateKey: закрытый ключ P-256 (secp256r1) устройства, в формате PEM или base64; поддерживаются форматы PKCS#8 и SEC 1. На его основе ядро на лету генерирует самоподписанный клиентский сертификат для mTLS; Cloudflare проверяет только то, совпадает ли его открытый ключ с ключом, записанным при регистрации этого устройства, и никакие пароли не передаются.

  • publicKey: открытый ключ P-256 (SubjectPublicKeyInfo) сертификата конечной точки MASQUE, в формате PEM или base64. Сертификат сервера закрепляется (pin) за этим открытым ключом, поэтому serverName можно указать любым; если в tlsSettings задан pinnedPeerCertSha256 или verifyPeerCertByName, publicKey игнорируется и проверка идёт только по ним (см. раздел про SNI ниже). Текущие edge-узлы masque (например, 162.159.198.2) используют фиксированный самоподписанный сертификат, открытый ключ которого можно получить самостоятельно:

    bash
    openssl s_client -connect 162.159.198.2:443 \
  -servername consumer-masque.cloudflareclient.com -alpn h2 -tls1_3 </dev/null \
  | openssl x509 -noout -pubkey | openssl pkey -pubin -outform der | base64 -w 0

  • address: адреса, назначенные устройству при регистрации в Warp (IPv4 /32, IPv6 /128). Warp не выдаёт адреса внутри туннеля, поэтому они явно указываются здесь.

WARNING

В отличие от WireGuard, MASQUE использует ключ устройства P-256 (secp256r1) (privateKey выше). Описанные выше wgcf / warp-reg генерируют ключи WireGuard Curve25519, которые masque использовать не может. Этот закрытый ключ P-256 и его address нужно получить способом регистрации, поддерживающим MASQUE, а в качестве publicKey достаточно указать полученный выше открытый ключ edge-узла. Кроме того, у этого устройства должен быть включён warp_enabled, иначе конечная точка вернёт access denied.

Конечные точки и порты не фиксированы ​

Warp — это обширная anycast-сеть; не привязывайтесь жёстко к одному IP-адресу или одному порту:

  • WireGuard: использует целый набор UDP-портов WARP (2408, 500, 1701, 4500, 2371, 4233, 8854 и другие — несколько десятков), распределённых по anycast-диапазонам 162.159.192.0/24, 162.159.193.0/24, 162.159.195.0/24, 188.114.96.0/22 и другим.
  • MASQUE (H2/TCP): бэкенд размещён на нескольких хостах диапазона 162.159.198.0/24 (например, .2, .10); проверка показала, что на портах 443 500 1701 4443 4500 8443 8095 и других рукопожатие успешно завершается и возвращается один и тот же сертификат masque.

Для разных типов аккаунтов конечные точки masque различаются, при этом publicKey у всех трёх одинаковый (проверка по IPv4 показала, что возвращается один и тот же сертификат):

Тип аккаунтаIPv4IPv6
WARP162.159.198.22606:4700:103::2
WARP+162.159.199.22606:4700:104::2
Zero Trust162.159.197.22606:4700:102::2

Если конкретный IP-адрес или порт попал под прицел, достаточно заменить address / port в settings исходящего подключения, параметры в warp менять не нужно. При смене IP-адреса убедитесь, что открытый ключ сертификата, который возвращает удалённая сторона, совпадает с publicKey, иначе сертификат будет отклонён проверкой pin; например, 162.159.198.1 возвращает другой сертификат.

SNI и FinalMask ​

Проверка pin сверяет только открытый ключ, но не доменное имя, а edge-узлы masque выбирают бэкенд по IP-адресу, а не по SNI (проверка показала, что 162.159.198.2 возвращает один и тот же сертификат для разных SNI), поэтому serverName можно заполнить двумя способами:

  • consumer-masque.cloudflareclient.com: имя, которое отправляет официальный клиент Warp; именно оно используется в примере ниже. Само имя выдаёт masque; при блокировке по SNI используйте его вместе с fragment / noise.
  • www.cloudflare.com и подобные обычные домены: имя masque в рукопожатии не появляется. Некоторые edge-узлы для SNI сайтов на Cloudflare (например, www.cloudflare.com) возвращают CDN-сертификат этого сайта, и тогда проверка pin по publicKey не проходит; в этом случае задайте в tlsSettings pinnedPeerCertSha256 (xray tls ping выводит SHA256 сертификата) или verifyPeerCertByName, и publicKey будет игнорироваться. Это domain fronting для WARP.

Ни один из этих вариантов не меняет IP-адрес: masque использует отдельный диапазон IP-адресов, и именно это — его настоящий отличительный признак.

FinalMask позволяет добавить ещё один слой маскировки: для H2 (TCP) — фрагментация Client Hello с помощью fragment в finalmask.tcp, для H3 (QUIC) — маскировка QUIC Initial с помощью noise в finalmask.udp.

WARNING

Edge-узлы masque не поддерживают ECH и сразу его отклоняют (проверка показала: в H2 после ECH_REJECTED не проходит проверка сертификата, а QUIC-соединение H3 закрывается с CRYPTO_ERROR 0x179 / ech_required); чтобы скрыть имя, достаточно сменить serverName. ECH полезен только для обращений к WARP API (edge-узлы общего назначения поддерживают ECH).

Полный пример исходящего подключения (H2 + fragment, наиболее стабильный вариант при ограничениях UDP):

json
{
  "protocol": "masque",
  "settings": {
    "address": "162.159.198.2",
    "port": 443
  },
  "streamSettings": {
    "method": "masque",
    "masqueSettings": {
      "warp": {
        "privateKey": "MHcCAQEE...",
        "publicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...",
        "address": ["172.16.0.2/32", "2606:4700:110:8a36::2/128"]
      }
    },
    "security": "tls",
    "tlsSettings": {
      "serverName": "consumer-masque.cloudflareclient.com",
      "alpn": ["h2"]
    },
    "finalmask": {
      "tcp": [
        {
          "type": "fragment",
          "settings": {
            "packets": "tlshello",
            "lengths": ["10-20"],
            "delays": ["10-20"]
          }
        }
      ]
    }
  },
  "tag": "warp-masque"
}

Для HTTP/3 замените alpn на ["h3"], а маскировку задайте через noise в finalmask.udp. Остальные сценарии — разделение трафика и цепочка прокси-серверов — настраиваются так же, как для WireGuard выше.

Участники (8)

Лицензия CC-BY-SA 4.0

Авторские права 2020-настоящее время Сообщество Project X