WireGuard — почему это новый стандарт

Когда Линус Торвальдс назвал WireGuard «произведением искусства» и принял в ядро Linux (5.6, март 2020) — индустрия признала: новый стандарт VPN. 4 000 строк кода против 600 000 у OpenVPN. Быстрее IPsec в 2 раза. Криптография намертво зашита, конфигурация — одна страница. Но у него есть критическая слабость для обхода блокировок.

1. Философия WireGuard: «opinionated» дизайн

Jason Donenfeld в 2015 сел и решил написать VPN с нуля, опираясь на современную криптографию и многолетний опыт боли OpenVPN/IPsec. Ключевые принципы:

1. Один шифр, один key exchange, один MAC. Никакого согласования алгоритмов (как в TLS). Криптография зашита: Curve25519, ChaCha20-Poly1305, BLAKE2s. Не нравится — не используй WireGuard. Если завтра ChaCha20 сломают — выйдет WireGuard 2.0.
2. UDP-only. Никакого TCP. TCP-over-TCP даёт «meltdown» при потерях.
3. Stateless handshake. Сервер не помнит «полусоединения» — нет DoS-уязвимости.
4. Crypto-routing. Адрес клиента в туннеле жёстко привязан к его публичному ключу в конфиге (AllowedIPs). Не угадаешь IP — не подменишь.
5. Stealth. Сервер не отвечает на левые пакеты вообще. Без знания ключа — порт «закрыт».
6. Конфигурация — текстовый файл на 10 строк. Не XML, не GUI, не базу.

2. Криптопримитивы — почему именно эти

3. Noise_IK handshake — 4 сообщения

WireGuard использует паттерн Noise_IK из Noise Framework (см. урок 02). 4 сообщения: Initiation, Response, далее уже data. Каждое — фиксированной длины.

Сообщение 1 — Handshake Initiation побайтово

match: udp.length == 148 AND udp.payload[0] == 0x01
       AND udp.payload[1..4] == 0x000000
       AND udp.payload[8..40] looks like X25519 point
action: drop, blacklist src_ip for 60s
    

4. Cookie reply — защита от DoS

Сервер делает дорогое X25519-вычисление при каждой Initiation. Атакующий мог бы засыпать сервер фальшивыми Initiation — сервер тратил бы CPU. Решение: cookie-reply.

Если сервер под нагрузкой — на следующую Initiation от данного IP он отвечает не Response, а специальным cookie-пакетом (type=3). Cookie — это hmac(secret, client_ip), валиден 2 минуты. Клиент должен включить cookie в mac2 следующей Initiation.

5. Data-пакет побайтово

После handshake клиент и сервер обмениваются Transport Data packets:

Длина зашифрованного пакета = длина оригинального IP-пакета + 16 байт (auth tag) + дополнения до 16-байтового выравнивания (padding). Overhead самого WireGuard над исходным IP-пакетом: 16 (data-header) + 16 (tag) = 32 байта. С учётом внешнего IPv4 (20) и UDP (8) полный overhead туннеля — ≈ 60 байт (поэтому типичный MTU интерфейса WireGuard — 1420).

6. Реализации: kernel vs userspace

7. Минимальная конфигурация

Серверная сторона /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = SERVER_PRIV_KEY_BASE64       # ← wg genkey
Address    = 10.8.0.1/24                  # внутренний IP туннеля
ListenPort = 51820                        # UDP-порт (любой)
PostUp     = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown   = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey  = CLIENT_PUB_KEY_BASE64        # ← клиент сообщает свой публичный ключ
AllowedIPs = 10.8.0.2/32                  # какие IP пропускать «как от этого клиента»
  

Клиентская сторона:

[Interface]
PrivateKey = CLIENT_PRIV_KEY_BASE64
Address    = 10.8.0.2/24
DNS        = 1.1.1.1, 1.0.0.1            # DNS внутри туннеля (необязательно)

[Peer]
PublicKey  = SERVER_PUB_KEY_BASE64
Endpoint   = vpn.example.com:51820        # IP/домен сервера
AllowedIPs = 0.0.0.0/0, ::/0              # «весь трафик в туннель»
PersistentKeepalive = 25                  # каждые 25с пинг, чтобы NAT не закрыл маппинг
  

Всё. Стартуем: sudo wg-quick up wg0. Никаких XML, GUI, БД.

8. Мини-лаба: попробуй прямо сейчас

Поднять настоящий туннель нужен root и сервер, но ключи и интерфейс WireGuard можно пощупать локально за пару минут — установи пакет wireguard-tools:

# 1. Сгенерируй пару ключей — как в разделе 7. Это X25519 из урока 2
wg genkey | tee priv.key | wg pubkey > pub.key
cat priv.key   # приватный — секрет
cat pub.key    # публичный — отдаёшь серверу

# 2. Если есть права root — подними пустой интерфейс и посмотри его
sudo ip link add dev wg-test type wireguard
sudo wg set wg-test private-key ./priv.key listen-port 51820
sudo ip addr add 10.9.0.1/24 dev wg-test
sudo ip link set wg-test up
ip a show wg-test        # вот он — тот самый виртуальный интерфейс из урока 1!
sudo wg show wg-test     # public key, порт, пиры (пока пусто)

# 3. Прибери за собой
sudo ip link del wg-test

# 4. Нет root? Хотя бы посмотри, детектируем ли WG «по форме» —
#    handshake WG всегда начинается с байта 0x01 и имеет длину 148 байт.
#    Именно это и ищет ТСПУ. Убедись, почему раздел 8 (AmneziaWG) необходим.

9. AmneziaWG — российский ответ на детект

Российская команда AmneziaVPN доработала WireGuard, чтобы обойти проблему «первый байт всегда 0x01 / длина всегда 148». Идея — добавить junk-пакеты и обфускацию.

10. Задачи самопроверки — реши, потом раскрой ответ

11. Словарик урока

12. Итог

В следующем уроке — модель противника. Что такое DPI, как он работает, что видит: JA3/JA4, ALPN-fingerprinting, active probing. Без этой модели бессмысленно говорить об обходе блокировок — сначала нужно понять, что именно ищет ТСПУ/GFW и по каким признакам отличает VPN-трафик от обычного.