VPN 너머의 Monero: 세 가지 네트워크 경로 중 무엇이 바뀌는가

지갑을 열고 데몬을 시작한 뒤 무엇이든 활성화하기 전에 화살표 세 개를 그리십시오. 하나는 지갑에서 노드의 RPC 포트로 향하고, 하나는 데몬의 피어 동기화를 나르며, 하나는 로컬에서 제출된 트랜잭션을 전달 경로 쪽으로 나릅니다. 서로 다른 설정을 가진 서로 다른 연결이며, VPN이나 익명 네트워크는 그중 하나, 둘 또는 어느 것도 덮지 않을 수 있습니다.

소프트웨어가 경로를 여는 순서대로 따라가십시오. 각 화살표에 목적지와 전송 방식을 적는 것이 이후의 프라이버시 주장을 검증 가능하게 만듭니다. 순서가 중요한 이유는 이후의 주장이 보통 그중 하나만 덮기 때문입니다.

지갑에서 노드로 가는 연결을 그리는 것부터 시작하십시오

원격 노드와 대화하는 지갑은 그 노드의 주소와 포트로 RPC 요청을 보냅니다. 로컬 데몬이 있는 지갑은 대신 루프백 인터페이스와 대화합니다. 일상 대화에서 둘 다 “노드”라고 불리지만 서로 다른 신뢰 관계입니다.

지갑이 사용하도록 설정된 주소, 포트, 전송 방식을 적어 두십시오. 지갑에 자체 프록시 설정이 있으면 데몬 설정과 별도로 기록하되, 한 프로세스를 설정한다고 다른 프로세스가 설정되지는 않습니다.

여기서 공개 RPC 엔드포인트가 유혹적으로 보입니다. 다이어그램을 단순화하려고 노드의 RPC 서비스를 노출하는 것은 네트워크 경로를 공격 표면과 맞바꾸는 일입니다. 지갑에서 노드로 가는 링크는 사설 경로나 루프백 인터페이스에 두고, 어느 쪽인지 문서화하십시오. 그 노출을 숨기는 다이어그램은 다이어그램이 없는 것보다 나쁩니다.

다음으로 데몬의 피어 트래픽을 따라가십시오

동기화 중인 데몬은 피어로 나가는 연결을 열고 피어 투 피어 포트로 체인 데이터를 교환합니다. 그 트래픽은 지갑의 RPC 링크가 아니며 지갑의 프록시를 자동으로 거치지도 않습니다. 데몬 자체의 네트워크 설정과 호스트의 라우팅 테이블을 따릅니다.

피어 포트, 연결 수, 그리고 데몬이 피어 트래픽에 프록시를 사용하도록 설정되었는지 기록하십시오. 그런 다음 예시 피어 주소에 대한 호스트 경로를 확인하십시오. VPN이 기본 경로를 잡으면 피어 연결은 아마 그것을 사용할 것이고, 데몬이 특정 인터페이스에 묶여 있으면 아닐 수도 있습니다. 이 두 사실이 화살표를 결정합니다.

이 경로에서는 관찰자에 대한 질문이 달라집니다. VPN은 피어 연결을 로컬 액세스 네트워크에서 숨기지만, VPN 엔드포인트와 피어 자신은 다른 모습을 봅니다. 두 관측 중 어느 것도 지갑의 요청이 같은 경로를 지났음을 증명하지 않습니다.

그런 다음 트랜잭션 전달 경로를 분리하십시오

로컬에서 제출된 트랜잭션은 설정된 릴레이나 프록시를 통해 네트워크 쪽으로 전달될 수 있습니다. 현재 Monero 데몬 문서에서 그 옵션은 프록시로 향하게 한 트랜잭션 전달 트래픽만 보냅니다. 모든 RPC, 지갑, 동기화 연결을 프록시를 거치는 트래픽으로 바꾸지는 않습니다.

프로젝트의 익명 네트워크 문서는 Tor와 I2P 통합을 실험적이라고 설명하고 전달 동작의 범위를 한정하지만, 실제로 실행하는 버전의 문서를 읽으십시오. 오래된 논의는 Kovri 같은 이름을 쓰고 더 이상 같은 형태로 존재하지 않는 구성 요소를 설명하기 때문입니다.

다이어그램에서 전달 경로를 따로 두십시오. 지갑의 잔액 조회가 원격 노드를 쓰는 동안 프록시로 나가는 트랜잭션에는 서로 다른 두 관찰자가 있으며, 트랜잭션이 프록시를 거쳤다는 사실은 조회 경로에 대해 아무것도 말해 주지 않습니다.

세 경로에 라벨을 붙인 뒤에만 VPN을 추가하십시오

화살표를 그린 뒤 VPN이 실제로 나르는 것이 무엇인지 표시하십시오. 전체 터널 VPN은 호스트의 기본 경로를 잡으므로 기본 경로를 따르는 연결은 그것을 사용합니다. 분할 터널, 묶인 인터페이스, 또는 특정 주소로 나가는 프록시는 일부 화살표를 터널 밖에 남길 수 있습니다.

이제 관찰자 모델을 명시하십시오. 익명 네트워크 연결이 VPN 안에서 동작하는 설계에서는 로컬 액세스 네트워크가 바깥쪽 VPN 연결을 보고, VPN 쪽은 그 다음 연결을 봅니다. 그것은 관찰자의 변화이며, 식별 신호가 사라진다는 증거가 아닙니다.

같은 순회의 일부로 실패 시 동작을 확인하십시오. VPN이 끊기면 데몬이 직접 피어 연결로 돌아가는지, 지갑이 원격 노드에 계속 질의하는지, 전달 프록시가 닫힌 상태로 실패하는지 확인하십시오. 차단이 설정되어 있지 않다면 재연결은 보통 침묵이 아니라 새로운 직접 시도를 의미합니다.

설정했다고 생각하는 경로를 검증하십시오

호스트 자체의 도구를 사용해 각 목적지의 경로를 읽고, 수신 대기 중인 소켓과 설정된 소켓을 살피고, 어떤 프로세스가 각 연결을 소유하는지 확인하십시오. 지갑, 데몬, 전달이 모두 실행 중일 때 이것을 하는 것은 시작할 때만 존재하는 경로가 재연결 후 사라질 수 있기 때문입니다.

VPN을 다시 연결한 뒤와 데몬을 재시작한 뒤에 반복하십시오. 목적지와 전송 방식을 다이어그램과 비교하십시오. 화살표가 움직였다면 모든 프로세스가 여전히 정상이라고 보고하더라도 프라이버시 모델도 함께 움직인 것입니다.

세 목적지, 각각의 전송 방식, 그리고 그것을 숨기려는 상대 관찰자를 기록하십시오. 한 기계에서 여러 독립 클라이언트가 실행될 때 이름 붙인 관찰자가 있는 짧은 경로 지도가 단일 VPN 표시보다 유용합니다.