Monero via un VPN : laquelle des trois voies réseau change ?

Ouvrez le portefeuille, démarrez le démon et tracez trois flèches avant d'activer quoi que ce soit. Une flèche relie le portefeuille au port RPC d'un nœud, une autre porte la synchronisation de pairs du démon, et une troisième porte les transactions soumises localement vers une voie de retransmission. Ce sont des connexions différentes avec des configurations différentes, et un VPN ou un réseau d'anonymat peut en couvrir une, deux ou aucune.

Parcourez les voies dans l'ordre où le logiciel les ouvre. Étiqueter chaque flèche avec sa destination et son transport est ce qui rend vérifiable l'affirmation ultérieure sur la confidentialité. L'ordre compte, car l'affirmation ultérieure ne couvre généralement qu'une seule d'entre elles.

Commencez par tracer la connexion du portefeuille au nœud

Un portefeuille qui parle à un nœud distant envoie des requêtes RPC à l'adresse et au port de ce nœud. Un portefeuille doté d'un démon local parle quant à lui à l'interface de bouclage. Ce sont des relations de confiance différentes, même si les deux sont appelées « le nœud » dans une conversation courante.

Notez l'adresse, le port et le transport que le portefeuille est configuré à utiliser. Si le portefeuille a son propre réglage de mandataire, consignez-le séparément de celui du démon ; configurer un processus ne configure pas l'autre.

C'est aussi là qu'un point de terminaison RPC public devient tentant. Exposer le service RPC du nœud pour simplifier le schéma échange une voie réseau contre une surface d'attaque. Gardez la liaison entre le portefeuille et le nœud sur une voie privée ou sur l'interface de bouclage, et documentez laquelle. Un schéma qui masque cette exposition est pire que pas de schéma du tout.

Ensuite, suivez le trafic de pairs du démon

Un démon qui se synchronise ouvre des connexions sortantes vers des pairs et échange des données de chaîne sur son port pair à pair. Ce trafic n'est pas la liaison RPC du portefeuille, et il ne passe pas automatiquement par le mandataire du portefeuille. Il suit les réglages réseau propres au démon et la table de routage de l'hôte.

Notez le port de pairs, le nombre de connexions et si le démon est configuré pour utiliser un mandataire pour le trafic de pairs. Vérifiez ensuite la route de l'hôte pour une adresse de pair prise en exemple. Si le VPN capte la route par défaut, les connexions de pairs l'utilisent probablement ; si le démon est lié à une interface précise, peut-être pas. Ces deux faits décident de la flèche.

La question de l'observateur change avec cette voie. Un VPN masque les connexions de pairs au réseau d'accès local, mais le point de terminaison du VPN et les pairs eux-mêmes voient une autre image. Aucune des deux observations ne prouve que les requêtes du portefeuille ont emprunté la même route.

Isolez ensuite la voie de retransmission des transactions

Les transactions soumises localement peuvent être transférées vers le réseau via un relais ou un mandataire configuré. Dans la documentation actuelle du démon Monero, cette option n'envoie par le mandataire que le trafic de retransmission de transactions que vous y dirigez. Elle ne transforme pas chaque connexion RPC, de portefeuille et de synchronisation en trafic mandaté.

La documentation du projet sur les réseaux d'anonymat décrit l'intégration de Tor et d'I2P comme expérimentale et délimite le comportement de retransmission. Lisez la documentation de la version que vous exécutez réellement, car des discussions plus anciennes emploient des noms comme Kovri et décrivent des composants qui n'existent plus sous la même forme.

Gardez la voie de retransmission séparée dans le schéma. Une transaction qui sort par un mandataire tandis que les requêtes de solde du portefeuille utilisent un nœud distant a deux observateurs différents, et le fait que la transaction soit passée par un mandataire ne dit rien de la voie de la requête.

N'ajoutez le VPN qu'une fois les trois voies étiquetées

Une fois les flèches tracées, marquez celles que le VPN transporte réellement. Un VPN en tunnel complet capte la route par défaut de l'hôte, donc les connexions qui suivent la route par défaut l'utiliseront. Un tunnel divisé, une interface liée ou un mandataire qui sort par une adresse précise peuvent laisser certaines flèches hors du tunnel.

Formulez maintenant le modèle d'observateur explicitement. Dans une conception où une connexion de réseau d'anonymat s'exécute à l'intérieur du VPN, le réseau d'accès local voit la connexion VPN extérieure, tandis que le côté VPN voit la connexion vers l'avant. C'est un changement d'observateur, pas la preuve que les signaux identifiants disparaissent.

Vérifiez le comportement en cas de panne dans le cadre du même parcours. Si le VPN tombe, le démon revient-il à une connexion directe aux pairs, le portefeuille continue-t-il d'interroger le nœud distant, et le mandataire de retransmission échoue-t-il en position fermée ? Sauf si le blocage est configuré, une reconnexion signifie généralement une nouvelle tentative directe plutôt qu'un silence.

Vérifiez les voies que vous croyez avoir configurées

Utilisez les outils de l'hôte lui-même : lisez la route de chaque destination, inspectez les sockets en écoute et établies, et confirmez quel processus possède chaque connexion. Faites-le pendant que le portefeuille, le démon et la retransmission tournent tous, car une voie qui n'existe qu'au démarrage peut disparaître après une reconnexion.

Répétez après une reconnexion du VPN et après un redémarrage du démon. Comparez les destinations et les transports avec le schéma. Si une flèche s'est déplacée, le modèle de confidentialité s'est déplacé avec elle, même si chaque processus se déclare toujours sain.

Notez les trois destinations, le transport de chacune et l'observateur auquel vous comptez les soustraire. Une courte carte des voies avec des observateurs nommés est plus utile qu'un seul indicateur VPN lorsque plusieurs clients indépendants tournent sur une même machine.