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, коли на одній машині працює кілька незалежних клієнтів.