VPN и P2P-трафик: port forwarding, NAT и настройка туннеля для приватного файлообмена

Торрент-клиент за VPN без проброса портов работает в режиме «только исходящие»: он может скачивать данные у пиров, которые сами инициируют соединение, но не способен принимать входящие подключения. Это снижает скорость, уменьшает число доступных пиров и в некоторых случаях делает раздачу невозможной. Проблема — в NAT: VPN-сервер получает пакеты из интернета, но не знает, на какой внутренний адрес туннеля их перенаправить, если правило не задано явно.

Почему P2P требует входящих соединений​

Протокол BitTorrent использует TCP (и в современных реализациях QUIC/UDP для uTP) для обмена данными между пирами. Каждый клиент слушает определённый порт и объявляет его через трекер или DHT. Когда другой пир хочет подключиться, он отправляет SYN на объявленный IP и порт.

Без VPN это прямой адрес машины. С VPN ситуация меняется:

• Исходящий трафик клиента уходит через туннель и появляется в интернете с IP сервера.
  
• Входящий трафик на IP сервера должен быть перенаправлен обратно в туннель на конкретный внутренний адрес клиента.
  
• Если перенаправления нет, входящие пакеты отбрасываются ядром сервера.
  

Результат: клиент видит статус «за firewall» или «нет входящих соединений», скорость падает, а seed-рейтинг не растёт.

WireGuard как основа туннеля​

WireGuard инкапсулирует IP-пакеты в UDP и создаёт сетевой интерфейс (wg0, wg1 и т. д.), который настраивается стандартными утилитами ip и wg. Маршрутизация внутри туннеля строится на концепции Cryptokey Routing: каждому пиру сопоставляется список AllowedIPs, который одновременно работает как таблица маршрутизации (куда отправлять) и как ACL (от кого принимать).

Для P2P-сценария типичная топология:

• Сервер имеет публичный IP и слушает UDP-порт WireGuard.
  
• Клиент получает внутренний адрес туннеля (например, 10.8.0.2/32).
  
• На сервере настраивается проброс TCP-порта с публичного интерфейса на 10.8.0.2.
  

Настройка сервера: проброс порта​

Предположим, сервер WireGuard имеет интерфейс wg0 с адресом 10.8.0.1/24, публичный интерфейс eth0 с адресом 203.0.113.10, а клиенту назначен 10.8.0.2. Нужно пробросить TCP-порт 51413 (стандартный для многих торрент-клиентов) на клиента.

Разрешение форвардинга​

sysctl -w net.ipv4.ip_forward=1

Для сохранения после перезагрузки — строка net.ipv4.ip_forward = 1 в /etc/sysctl.conf или в файле внутри /etc/sysctl.d/.

Правило DNAT​

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 51413 -j DNAT --to-destination 10.8.0.2:51413
iptables -A FORWARD -i eth0 -o wg0 -p tcp --dport 51413 -d 10.8.0.2 -j ACCEPT

Первое правило переписывает адрес назначения входящего пакета. Второе разрешает форвардинг через цепочку FORWARD, если политика по умолчанию — DROP.

Маскарадинг для исходящего трафика клиента​

Чтобы клиент мог выходить в интернет через сервер, нужен SNAT или MASQUERADE:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Без этого правила ответные пакеты из интернета не вернутся в туннель, потому что сервер не будет знать, что их нужно отправить обратно на 10.8.0.2.

Конфигурация WireGuard на сервере​

[Interface]
PrivateKey = <приватный_ключ_сервера>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <публичный_ключ_клиента>
AllowedIPs = 10.8.0.2/32

AllowedIPs = 10.8.0.2/32 означает, что сервер принимает от этого пира только пакеты с источником 10.8.0.2 и отправляет ему всё, что адресовано на 10.8.0.2.

Настройка клиента: full tunnel​

Чтобы весь трафик клиента, включая торренты, шёл через VPN, в конфигурации указывается AllowedIPs = 0.0.0.0/0:

[Interface]
PrivateKey = <приватный_ключ_клиента>
Address = 10.8.0.2/24
DNS = 10.8.0.1

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 — это wildcard: клиент шифрует и отправляет на сервер пакеты с любым адресом назначения. Сервер, в свою очередь, должен обеспечить их выход в интернет через MASQUERADE.

PersistentKeepalive = 25 отправляет keepalive-пакет каждые 25 секунд, что предотвращает закрытие NAT-маппинга на промежуточных маршрутизаторах. Для P2P это особенно важно, потому что входящие соединения могут приходить после длительных пауз.

DNS = 10.8.0.1 указывает клиенту использовать DNS-сервер на стороне VPN. Если на сервере не запущен резолвер, можно указать публичный (например, 1.1.1.1), но тогда DNS-запросы пойдут в обход туннеля, если не настроен отдельный маршрут.

Торрент-клиент: привязка к интерфейсу​

Большинство клиентов (qBittorrent, Transmission, Deluge) позволяют привязать исходящие соединения к конкретному сетевому интерфейсу. Это дополнительная страховка: если туннель упадёт, клиент не переключится на прямой интерфейс и не раскроет реальный IP.

В qBittorrent это поле «Сетевой интерфейс» в настройках соединения. Указывают wg0 или его IP-адрес 10.8.0.2. В Transmission — параметр bind-address-ipv4 в конфигурации.

Kill switch: защита от утечек при обрыве туннеля​

Если WireGuard-интерфейс пропадает или сервер недоступен, ОС может отправить трафик через основной интерфейс напрямую. Для P2P это означает мгновенную утечку реального IP.

Простейший kill switch на клиенте (Linux):

iptables -A OUTPUT ! -o wg0 -m owner --uid-owner $(id -u) -j DROP

Это правило блокирует весь исходящий трафик текущего пользователя, кроме идущего через wg0. Если туннель падает, торрент-клиент теряет связь с интернетом вместо того, чтобы работать напрямую.

Альтернатива — использовать network namespace. WireGuard поддерживает работу в пространствах имён: интерфейс создаётся в основном namespace (где есть доступ к интернету), а затем перемещается в изолированный namespace, в котором запускается торрент-клиент. Единственный способ выхода из этого namespace — через туннель.

Проверка результата​

После настройки стоит убедиться, что всё работает корректно:

Проверка	Что делать	Ожидаемый результат
IP-адрес	Открыть https://ifconfig.me или аналогичный сервис	Показывается IP VPN-сервера, не реальный
DNS-утечка	https://dnsleaktest.com или https://ipleak.net	DNS-серверы принадлежат VPN или указанному резолверу
Входящий порт	В торрент-клиенте проверить статус порта или использовать https://canyouseeme.org	Порт открыт, статус «reachable»
Привязка интерфейса	Остановить туннель, запустить клиент	Клиент не может подключиться к интернету
WebRTC	https://browserleaks.com/webrtc в браузере	Не показывает реальный IP (актуально, если браузер тоже в туннеле)

Типичные ошибки​

Забыт MASQUERADE. Клиент устанавливает туннель, но не может выйти в интернет. Пакеты уходят с сервера с внутренним адресом 10.8.0.2, и ответы не возвращаются.

AllowedIPs на сервере слишком широкий. Если указать AllowedIPs = 0.0.0.0/0 для клиента на стороне сервера, сервер будет пытаться отправить весь трафик через этого клиента. Для P2P-сервера с одним клиентом это не проблема, но при нескольких пирах маршрутизация ломается.

Порт в клиенте не совпадает с пробросом. Если торрент-клиент слушает порт 6881, а на сервере проброшен 51413, входящие соединения не дойдут. Порт в правиле DNAT и в настройках клиента должен совпадать.

Нет PersistentKeepalive. За NAT (домашний роутер, корпоративный firewall) маппинг UDP-порта закрывается через 30–120 секунд без активности. Без keepalive туннель «засыпает», и входящие TCP-соединения на проброшенный порт не находят путь обратно.

Kill switch не покрывает IPv6. Если в системе активен IPv6, трафик может уходить через него в обход правил iptables для IPv4. Нужно либо отключить IPv6 на клиенте, либо добавить аналогичные правила через ip6tables.

Ограничения и нюансы​

• Некоторые VPN-провайдеры блокируют P2P-трафик или не поддерживают port forwarding. При использовании собственного сервера WireGuard это ограничение снимается, но нагрузка на канал и IP-репутация сервера становятся вашей ответственностью.
  
• Проброс порта делает сервер частично «видимым» для сканирования извне. Если сервер используется не только для VPN, стоит ограничить доступ к проброшенному порту по IP или использовать fail2ban.
  
• WireGuard работает поверх UDP. В сетях, где UDP фильтруется (корпоративные firewall, некоторые страны), туннель может не устанавливаться. В таких условиях рассматривают обёртки вроде AmneziaWG AmneziaWG: настройка собственного VPN-сервера с защитой от DPI, которые маскируют трафик под разрешённые протоколы.
  
• Для нескольких клиентов за одним сервером каждому нужен отдельный проброс порта или диапазон портов, привязанный к его внутреннему адресу.
  

Источники​

• WireGuard: fast, modern, secure VPN tunnel