Monero через VPN: какой из трёх сетевых путей меняется?

Откройте кошелёк, запустите демон и нарисуйте три стрелки, прежде чем что-либо включать. Одна стрелка идёт от кошелька к RPC-порту узла, другая несёт пиринговую синхронизацию демона, третья несёт локально отправленные транзакции к пути пересылки. Это разные соединения с разными настройками, и VPN или сеть анонимности может покрывать одно, два или ни одного из них.

Пройдите пути в том порядке, в каком их открывает программное обеспечение. Обозначение каждой стрелки её назначением и транспортом делает последующее утверждение о приватности проверяемым. Порядок важен, потому что последующее утверждение обычно охватывает только один из них.

Начните с рисования соединения кошелька с узлом

Кошелёк, который общается с удалённым узлом, отправляет RPC-запросы на адрес и порт этого узла. Кошелёк с локальным демоном общается вместо этого с интерфейсом обратной петли. Это разные отношения доверия, хотя в обычном разговоре и то и другое называют «узлом».

Запишите адрес, порт и транспорт, которые кошелёк настроен использовать. Если у кошелька есть собственная настройка прокси, запишите её отдельно от настроек демона; настройка одного процесса не настраивает другой.

Здесь же публичная конечная точка RPC становится соблазнительной. Открытие RPC-службы узла ради упрощения схемы меняет сетевой путь на поверхность атаки. Держите связь кошелька с узлом на приватном пути или на интерфейсе обратной петли и задокументируйте, что именно. Схема, которая скрывает это раскрытие, хуже отсутствия схемы.

Далее проследите пиринговый трафик демона

Синхронизирующий демон открывает исходящие соединения к пирам и обменивается данными цепочки через свой пиринговый порт. Этот трафик не является RPC-соединением кошелька и не направляется автоматически через прокси кошелька. Он следует собственным сетевым настройкам демона и таблице маршрутизации хоста.

Запишите пиринговый порт, число соединений и то, настроен ли демон использовать прокси для пирингового трафика. Затем проверьте маршрут хоста для примера адреса пира. Если VPN перехватывает маршрут по умолчанию, пиринговые соединения, вероятно, используют его; если демон привязан к определённому интерфейсу, возможно, нет. Эти два факта решают стрелку.

Вопрос о наблюдателе меняется вместе с этим путём. VPN скрывает пиринговые соединения от локальной сети доступа, но конечная точка VPN и сами пиры видят другую картину. Ни одно из этих наблюдений не доказывает, что запросы кошелька пошли тем же маршрутом.

Затем изолируйте путь пересылки транзакций

Локально отправленные транзакции можно пересылать в сеть через настроенный ретранслятор или прокси. В текущей документации демона Monero этот параметр отправляет через прокси только тот трафик пересылки транзакций, который вы на него направляете. Он не превращает каждое RPC-, кошельковое и синхронизационное соединение в трафик через прокси.

Документация проекта о сетях анонимности описывает интеграцию Tor и I2P как экспериментальную и ограничивает область поведения при пересылке. Читайте документацию той версии, которую действительно запускаете, потому что в старых обсуждениях используются имена вроде Kovri и описываются компоненты, которых в том же виде больше нет.

Держите путь пересылки на схеме отдельно. Транзакция, которая выходит через прокси, пока запросы баланса кошелька используют удалённый узел, имеет двух разных наблюдателей, и то, что транзакция шла через прокси, ничего не говорит о пути запроса.

Добавляйте VPN только после того, как три пути обозначены

Когда стрелки нарисованы, отметьте, какие из них VPN действительно несёт. VPN с полным туннелем перехватывает маршрут хоста по умолчанию, поэтому соединения, следующие по умолчанию, будут его использовать. Разделённый туннель, привязанный интерфейс или прокси, выходящий через конкретный адрес, могут оставить часть стрелок вне туннеля.

Теперь явно сформулируйте модель наблюдателя. В схеме, где соединение сети анонимности работает внутри VPN, локальная сеть доступа видит внешнее соединение VPN, а сторона VPN видит дальнейшее соединение. Это смена наблюдателя, а не доказательство того, что идентифицирующие сигналы исчезают.

Проверьте поведение при отказе как часть того же прохода. Если VPN падает, возвращается ли демон к прямому пиринговому соединению, продолжает ли кошелёк опрашивать удалённый узел и закрывается ли прокси пересылки при отказе? Если блокировка не настроена, переподключение обычно означает новую прямую попытку, а не тишину.

Проверьте пути, которые, как вы думаете, вы настроили

Используйте собственные инструменты хоста: прочитайте маршрут для каждого назначения, осмотрите слушающие и установленные сокеты и подтвердите, какой процесс владеет каждым соединением. Делайте это, пока кошелёк, демон и пересылка работают, потому что путь, существующий только при запуске, может исчезнуть после переподключения.

Повторите после переподключения VPN и после перезапуска демона. Сравните назначения и транспорты со схемой. Если стрелка сдвинулась, модель приватности сдвинулась вместе с ней, даже если каждый процесс по-прежнему сообщает, что он здоров.

Запишите три назначения, транспорт для каждого и наблюдателя, от которого вы собираетесь их скрывать. Краткая карта путей с названными наблюдателями полезнее одного индикатора VPN, когда на одной машине работает несколько независимых клиентов.