WireGuard хранит IP на сервере — это реально проблема приватности или хайп?

[davidwor]

Читал, что WireGuard по дизайну сохраняет IP-адреса подключённых клиентов в памяти сервера до перезагрузки. Коммерческие провайдеры это как-то обходят через double NAT или ротацию ключей, но если поднимаешь сам — это реальная дыра? Насколько это критично если сервер у тебя на VPS и ты единственный пользователь?

[kernel_veteran]

Если сервер твой и ты единственный пользователь — это вообще не проблема. Кто придёт с запросом к твоему VPS? Провайдер VPS и так знает твой IP из биллинга. Проблема актуальна для мультипользовательских серверов, где оператор не должен знать кто когда подключался. Там да, без скриптов очистки или double NAT — все сессии видны в `wg show`.

[Rhemix]

Mullvad решает это через двойной NAT: первый интерфейс даёт всем клиентам одинаковый внутренний IP, второй делает динамический NAT на выход. В итоге в памяти ядра висит только общий IP, а не твой. Для self-hosted можно сделать похожее через nftables: `nft add rule nat postrouting oifname eth0 masquerade` + отдельный неймспейс. Но честно говоря — для личного использования это overhead.

[clickhouse_ops]

Я добавил в cron скрипт который каждые 15 минут делает `wg syncconf wg0 <(wg-quick strip wg0)` — это сбрасывает статистику handshake и last-endpoint не отключая туннель. Не идеально, но уменьшает окно. Ещё вариант — поднять WireGuard через Tor, тогда IP на сервере будет выходной нодой Tor, а не твоим реальным.

[hunter22]

Честно говоря вся эта паника по поводу IP в памяти WireGuard — немного из серии «безопасность ради безопасности». Если у тебя нормальная модель угрозы (обход блокировок, защита трафика в кафе), то это вообще не в списке рисков. Если у тебя модель угрозы — сервер конфискуют и форенсят оперативную память — у тебя другие проблемы.

[debianpro]

@Rhemix, Тут важен контекст: WireGuard изначально проектировался как безопасный туннель, а не анонимизирующий инструмент. Это принципиальная разница. Для анонимности нужен Tor или правильно настроенный I2P. WireGuard + VPS даёт шифрование и смену IP, но не анонимность — провайдер VPS всегда знает кто платит и откуда подключается.

[Planed]

Кстати про WebRTC утечки с WireGuard никто не упомянул. Статичный внутренний IP (обычно 10.x.x.x) может утечь через WebRTC даже когда туннель поднят. В Firefox отключается через `media.peerconnection.enabled = false` в about:config, в Chrome — только через расширение типа WebRTC Leak Prevent. Проверяйте на browserleaks.com.

[fpga87]

Стоит разделить два слоя: что WireGuard держит в памяти ядра (endpoint, last handshake, счётчики трафика) и что вообще пишется на диск — а на диск он сам по себе не пишет ничего. Перезагрузил VPS — состояние чистое. Реальный след оставляет не WireGuard, а хостер: биллинг, логи гипервизора, NetFlow на аплинке. Так что если строить модель угрозы для одиночного VPS, то `wg show` в ней — самый маленький из всех зверей. Я бы больше беспокоился о том, что DNS-запросы уходят мимо туннеля, если в конфиге забыт DNS= — вот это утекает постоянно и логируется у резолвера.

[go_pro]

@clickhouse_ops, с syncconf есть нюанс: если у клиентов стоит PersistentKeepalive=25 (а он почти у всех стоит, иначе за NAT туннель умирает), то endpoint и handshake вернутся в память максимум через 25 секунд после твоего сброса. То есть скрипт реально чистит данные только по отвалившимся клиентам, для активных окно сужается с «до ребута» до «до следующего keepalive». Для одиночного сервера это нормальный компромисс, просто чтобы не было иллюзии, что каждые 15 минут всё обнуляется.

[heckman]

@Planed, про WebRTC поправка: современные браузеры уже несколько лет отдают локальные ICE-кандидаты как mDNS-имена вида xxxx.local, а не сырой 10.x.x.x, так что внутренний адрес туннеля через WebRTC сейчас утекает гораздо реже, чем пишут в старых статьях. Реальная WebRTC-проблема — это когда туннель поднят не на уровне системы, а в виде прокси внутри браузера: тогда STUN может уйти мимо и слить именно внешний домашний IP. Проверять стоит, согласен, но бояться надо другого сценария.