Monero przez VPN: która z trzech ścieżek sieciowych się zmienia?

Otwórz portfel, uruchom demona i narysuj trzy strzałki, zanim cokolwiek włączysz. Jedna strzałka biegnie od portfela do portu RPC węzła, jedna niesie synchronizację peeringową demona, a jedna niesie lokalnie wysłane transakcje w stronę ścieżki przekazywania. To różne połączenia z różną konfiguracją, a VPN lub sieć anonimowości może obejmować jedno, dwa lub żadne z nich.

Przejdź ścieżki w kolejności, w jakiej otwiera je oprogramowanie. Oznaczenie każdej strzałki celem i transportem jest tym, co czyni późniejsze twierdzenie o prywatności sprawdzalnym. Kolejność ma znaczenie, bo późniejsze twierdzenie zwykle obejmuje tylko jedną z nich.

Zacznij od narysowania połączenia portfela z węzłem

Portfel, który rozmawia ze zdalnym węzłem, wysyła żądania RPC na adres i port tego węzła. Portfel z lokalnym demonem rozmawia natomiast z interfejsem pętli zwrotnej. To różne relacje zaufania, choć w codziennej rozmowie oba nazywa się „węzłem”.

Zapisz adres, port i transport, do których portfel jest skonfigurowany. Jeśli portfel ma własne ustawienie proxy, zanotuj je osobno od ustawień demona; skonfigurowanie jednego procesu nie konfiguruje drugiego.

Tu także publiczny punkt końcowy RPC staje się kuszący. Wystawienie usługi RPC węzła, aby uprościć diagram, wymienia ścieżkę sieciową na powierzchnię ataku. Trzymaj połączenie portfela z węzłem na prywatnej ścieżce lub na interfejsie pętli zwrotnej i udokumentuj, która to. Diagram, który ukrywa to wystawienie, jest gorszy niż brak diagramu.

Następnie śledź ruch peeringowy demona

Synchronizujący się demon otwiera połączenia wychodzące do peerów i wymienia dane łańcucha przez swój port peer-to-peer. Ten ruch to nie łącze RPC portfela i nie jest automatycznie kierowany przez proxy portfela. Podlega własnym ustawieniom sieciowym demona i tablicy routingu hosta.

Zapisz port peerów, liczbę połączeń i to, czy demon jest skonfigurowany do używania proxy dla ruchu peeringowego. Następnie sprawdź trasę hosta dla przykładowego adresu peera. Jeśli VPN przechwytuje trasę domyślną, połączenia peeringowe prawdopodobnie jej używają; jeśli demon jest przypisany do konkretnego interfejsu, może nie. Te dwa fakty decydują o strzałce.

Pytanie o obserwatora zmienia się wraz z tą ścieżką. VPN ukrywa połączenia peeringowe przed lokalną siecią dostępową, ale punkt końcowy VPN i same peery widzą inny obraz. Żadna z tych obserwacji nie dowodzi, że żądania portfela poszły tą samą trasą.

Następnie wyodrębnij ścieżkę przekazywania transakcji

Lokalnie wysłane transakcje można przekazać w stronę sieci przez skonfigurowany przekaźnik lub proxy. W obecnej dokumentacji demona Monero ta opcja wysyła przez proxy tylko ten ruch przekazywania transakcji, który na niego skierujesz. Nie zamienia każdego połączenia RPC, portfela i synchronizacji w ruch przechodzący przez proxy.

Dokumentacja projektu dotycząca sieci anonimowości opisuje integrację Tor i I2P jako eksperymentalną i ogranicza zakres zachowania przy przekazywaniu. Czytaj dokumentację tej wersji, którą naprawdę uruchamiasz, ponieważ starsze dyskusje używają nazw takich jak Kovri i opisują komponenty, których nie ma już w tej samej formie.

Trzymaj ścieżkę przekazywania osobno na diagramie. Transakcja, która wychodzi przez proxy, podczas gdy zapytania o saldo portfela korzystają ze zdalnego węzła, ma dwóch różnych obserwatorów, a fakt, że transakcja przeszła przez proxy, nic nie mówi o ścieżce zapytania.

Dodaj VPN dopiero po oznaczeniu trzech ścieżek

Po narysowaniu strzałek zaznacz, które VPN naprawdę niesie. VPN z pełnym tunelem przechwytuje domyślną trasę hosta, więc połączenia podążające za domyślną będą jej używać. Tunel dzielony, przypisany interfejs lub proxy wychodzące przez konkretny adres mogą zostawić część strzałek poza tunelem.

Teraz wyraźnie sformułuj model obserwatora. W projekcie, w którym połączenie sieci anonimowości działa wewnątrz VPN, lokalna sieć dostępowa widzi zewnętrzne połączenie VPN, a strona VPN widzi połączenie dalsze. To zmiana obserwatora, a nie dowód, że sygnały identyfikujące znikają.

Sprawdź zachowanie przy awarii jako część tego samego przejścia. Jeśli VPN padnie, czy demon wraca do bezpośredniego połączenia peeringowego, czy portfel nadal odpytuje zdalny węzeł i czy proxy przekazywania zawodzi w stanie zamkniętym? O ile blokowanie nie jest skonfigurowane, ponowne połączenie zwykle oznacza nową bezpośrednią próbę, a nie ciszę.

Zweryfikuj ścieżki, które uważasz za skonfigurowane

Użyj narzędzi samego hosta: odczytaj trasę dla każdego celu, obejrzyj gniazda nasłuchujące i ustanowione i potwierdź, który proces posiada każde połączenie. Rób to, gdy portfel, demon i przekazywanie działają, ponieważ ścieżka istniejąca tylko przy starcie może zniknąć po ponownym połączeniu.

Powtórz po ponownym połączeniu VPN i po restarcie demona. Porównaj cele i transporty z diagramem. Jeśli strzałka się przesunęła, model prywatności przesunął się razem z nią, nawet jeśli każdy proces nadal zgłasza, że jest zdrowy.

Zapisz trzy cele, transport każdego i obserwatora, przed którym zamierzasz je ukryć. Krótka mapa ścieżek z nazwanymi obserwatorami jest użyteczniejsza niż jeden wskaźnik VPN, gdy na jednej maszynie działa kilka niezależnych klientów.