Разработка децентрализованного VPN-сервиса

Разработка децентрализованного VPN-сервиса

Централизованный VPN решает одну проблему доверия, создавая другую: вместо ISP вы доверяете VPN-провайдеру. NordVPN, ExpressVPN, Surfshark — все они ведут логи (несмотря на декларации), все они подчиняются юрисдикционным запросам, все они являются единой точкой отказа. Децентрализованный VPN распределяет это доверие по сети независимых операторов нод так, чтобы ни один из них не мог восстановить полный трафик пользователя.

Построить это правильно сложнее, чем кажется. Существующие протоколы — Sentinel, Mysterium, Orchid — уже решили часть задач, но имеют специфические архитектурные ограничения. Понимание этих ограничений критично до начала разработки.

Протокольный уровень: выбор транспорта

Сетевой транспорт — это фундамент, который нельзя поменять после запуска. Основные варианты:

WireGuard — современный, быстрый (< 300 строк кода в ядре), встроен в Linux 5.6+. Проблема для dVPN: WireGuard требует знания IP обеих сторон заранее, нет native support для roaming и динамических топологий. Peer конфигурация статична. Для dVPN с динамическим набором exit нод — нужна обёртка для управления конфигурацией.

OpenVPN — зрелый, но медленный и с большим attack surface. Реальных преимуществ перед WireGuard для новой разработки нет.

V2Ray / Xray с протоколами VLESS/VMESS — разработаны специально для обхода DPI (Deep Packet Inspection). Трафик маскируется под HTTPS (XTLS). Незаменимы если в требованиях — работа в странах с активной блокировкой (Китай, Иран, Россия). Sentinel использует именно V2Ray как один из транспортных слоёв.

Mixnet подход (Nym, Tor-style) — пакеты перемешиваются через несколько нод, добавляется задержка и dummy трафик для защиты от traffic analysis. Максимальная анонимность, но высокая latency (100–500ms overhead). Для обычного VPN-use-case overkill, для high-privacy приложений — единственный правильный выбор.

Для большинства dVPN проектов: WireGuard как транспорт + кастомный control plane для управления peers + опциональный V2Ray слой для DPI-obfuscation.

Архитектура privacy: onion routing vs proxy

Простая proxy-модель

Пользователь → Exit Node → Интернет. Exit нода знает IP пользователя и видит трафик (если не зашифрован HTTPS). Это модель Mysterium и большинства dVPN первого поколения. Защищает от ISP-слежки, не защищает от malicious exit node.

Multi-hop с onion encryption

Пользователь → Guard Node → Relay Node → Exit Node → Интернет. Каждый слой шифруется отдельным ключом (как Tor). Guard видит IP пользователя, но не знает exit. Exit видит destination, но не знает пользователя. Relay не знает ни того, ни другого.

Реализация через onion encryption:

Encrypted payload:
[
  encrypt(
    to: guard_pubkey,
    payload: {
      next_hop: relay_address,
      payload: encrypt(
        to: relay_pubkey,
        payload: {
          next_hop: exit_address,
          payload: encrypt(
            to: exit_pubkey,
            payload: { destination: "example.com:443", data: ... }
          )
        }
      )
    }
  )
]

Каждая нода расшифровывает только свой слой, видит только next hop, пересылает дальше. Алгоритм: X25519 для key exchange, ChaCha20-Poly1305 для симметричного шифрования — это выбор WireGuard и Signal Protocol.

Стоимость multi-hop: latency растёт линейно с числом хопов (~30–80ms на хоп в пределах одного региона). Для streaming — максимум 2 хопа, для максимальной приватности — 3.

Смарт-контракты и экономика

Payment channel для micropayments

Пользователи платят за трафик в реальном времени. Транзакция в блокчейне за каждый MB — нежизнеспособно (gas). Решение: unidirectional payment channels (схема как в Lightning, но проще для EVM).

contract DVPNChannel {
    struct Channel {
        address user;
        address provider;
        uint256 deposit;        // заблокированные средства
        uint256 settled;        // уже выплачено провайдеру
        uint256 expiry;         // таймаут канала
        bool closed;
    }

    mapping(bytes32 => Channel) public channels;

    event ChannelOpened(bytes32 indexed channelId, address user, address provider, uint256 deposit);
    event ChannelClosed(bytes32 indexed channelId, uint256 providerAmount, uint256 userRefund);

    // Пользователь открывает канал с депозитом
    function openChannel(address provider, uint256 duration) external payable returns (bytes32) {
        bytes32 channelId = keccak256(abi.encodePacked(msg.sender, provider, block.timestamp));
        channels[channelId] = Channel({
            user: msg.sender,
            provider: provider,
            deposit: msg.value,
            settled: 0,
            expiry: block.timestamp + duration,
            closed: false
        });
        emit ChannelOpened(channelId, msg.sender, provider, msg.value);
        return channelId;
    }

    // Провайдер закрывает канал с подписанным чеком от пользователя
    function closeChannel(
        bytes32 channelId,
        uint256 amount,         // сколько провайдер заработал
        bytes calldata userSig  // подпись пользователя
    ) external {
        Channel storage ch = channels[channelId];
        require(msg.sender == ch.provider, "Only provider");
        require(!ch.closed, "Already closed");
        require(amount <= ch.deposit, "Exceeds deposit");

        // Верификация подписи: пользователь подтвердил этот amount
        bytes32 hash = keccak256(abi.encodePacked(channelId, amount));
        bytes32 ethHash = MessageHashUtils.toEthSignedMessageHash(hash);
        address signer = ECDSA.recover(ethHash, userSig);
        require(signer == ch.user, "Invalid signature");

        ch.closed = true;
        ch.settled = amount;

        payable(ch.provider).transfer(amount);
        payable(ch.user).transfer(ch.deposit - amount);

        emit ChannelClosed(channelId, amount, ch.deposit - amount);
    }
}

Пользователь периодически подписывает «чеки» на нарастающую сумму off-chain. Провайдер хранит последний чек. При закрытии — предъявляет последний чек контракту. Это O(1) транзакций в блокчейне вне зависимости от объёма трафика.

Риск: пользователь может отозвать средства до закрытия канала провайдером. Защита: expiry — провайдер обязан закрыть канал до истечения срока. Timelock на withdrawal для пользователя: нельзя вывести средства до expiry или если провайдер не инициировал закрытие.

Node Registry

On-chain реестр провайдеров с stake, метаданными и репутацией:

struct NodeInfo {
    address operator;
    uint256 stake;              // залог
    string endpoint;            // WireGuard / V2Ray endpoint
    bytes32 locationHash;       // хэш от страны/региона (privacy)
    uint256 bandwidthCapacity;  // Mbps
    uint256 totalServed;        // суммарный трафик, верифицированный контрактом
    uint256 uptime;             // в basis points (9950 = 99.5%)
    NodeStatus status;
}

Endpoint хранить on-chain небезопасно для провайдеров из чувствительных юрисдикций. Альтернатива: endpoint хранится в IPFS или в зашифрованном виде, ключ расшифровки только у авторизованных пользователей.

Bandwidth proof: верификация без полного trust

Главная проблема: как доказать, что провайдер реально обслужил трафик? Простые решения — provider самоотчёт — очевидно неверифицируемы.

Proof of Bandwidth через challenge-response. Coordinating нода периодически посылает challenge exit ноде, требуя передать данные через установленный туннель. Latency и throughput измеряются, результат подписывается. Это не идеальная верификация, но значительно повышает порог мошенничества.

Client-side measurement. Клиентское приложение измеряет реальную скорость и подписывает результат. Провайдер не может предъявить контракту больше, чем подтвердил клиент. Проблема: клиент тоже может лгать (collusion), но incentive для этого нет — клиент платит больше при накрутке.

Third-party auditor nodes. Специализированные ноды-аудиторы, которые периодически проверяют провайдеров и публикуют результаты on-chain. Sentinel использует этот подход.

Client-side реализация

Клиентское приложение (desktop/mobile) — критичный компонент. Функции:

Node discovery и selection. Запрос к on-chain реестру → фильтрация по геолокации, цене, uptime → выбор оптимального провайдера. Кэширование списка нод локально, обновление по таймеру.

WireGuard management. На Linux/macOS — native WireGuard через wg-quick. На Windows — wireguard-windows. На Android/iOS — wireguard-go. Генерация keypair на клиенте, публикация public key провайдеру через зашифрованный канал.

Payment channel lifecycle. Открытие канала при подключении, периодическое подписание чеков (например, каждые 10 MB), закрытие при отключении. Всё это должно быть transparent для пользователя.

class DVPNClient {
    private channel: PaymentChannel | null = null;
    private wireguard: WireGuardInterface;

    async connect(nodeAddress: string): Promise<void> {
        // 1. Открываем payment channel
        this.channel = await this.openPaymentChannel(nodeAddress, {
            depositAmount: parseEther("0.1"),  // depozit
            duration: 3600,  // 1 час
        });

        // 2. Получаем WireGuard конфиг от провайдера (через зашифрованный handshake)
        const wgConfig = await this.negotiateWireGuard(nodeAddress, this.channel.id);

        // 3. Поднимаем туннель
        await this.wireguard.connect(wgConfig);

        // 4. Запускаем billing loop
        this.startBillingLoop();
    }

    private async startBillingLoop(): Promise<void> {
        setInterval(async () => {
            const bytesUsed = await this.wireguard.getStats();
            const owedAmount = this.calculateOwed(bytesUsed);
            const signedVoucher = await this.signVoucher(this.channel!.id, owedAmount);
            await this.sendVoucherToProvider(signedVoucher);
        }, 30_000);  // каждые 30 секунд
    }
}

Регуляторные и юридические аспекты

Exit ноды децентрализованного VPN несут юридическую ответственность за трафик, который через них проходит — так же, как обычные VPN-провайдеры. В некоторых юрисдикциях это проблема. Sentinel и Mysterium решают это через Terms of Service для операторов нод и технические ограничения на типы трафика (блокировка торрентов и P2P по умолчанию).

Это не технический вопрос, но он должен быть решён до launch в протокол-уровне политике.

Сроки разработки

MVP с desktop клиентом и 10–20 тестовыми нодами — 4–6 месяцев. Production-ready система с mobile поддержкой и достаточной децентрализацией — 8–12 месяцев.