VPN 뒤의 Bitcoin 노드에 인바운드 피어가 없나요?

노드가 동기화되었고 VPN이 연결되었다고 보고하며, getpeerinfo이(가) 여덟 개 또는 열 개의 피어를 보여 줍니다. 그중 어느 것도 inbound이(가) true로 설정되어 있지 않습니다. 이 조합은 정상이며 결함이 아닙니다. 아웃바운드 연결은 노드가 다른 곳에 도달할 수 있음을 증명하지만, 그 어느 것도 누군가가 당신에게 도달할 수 있음을 증명하지 않습니다. 목표가 VPN을 통해 인바운드 P2P 연결을 받는 노드라면 그 방향을 따로 시험해야 합니다.

피어에서 리스너까지 패킷을 따라가 보세요

인바운드 P2P는 네 가지 요소의 사슬이며, 가장 흥미로운 고리가 아니라 가장 약한 고리에서 끊깁니다.

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

Core의 메인넷 P2P 기본값은 8333이지만, 제공자는 다른 공용 포트와 다른 클라이언트 측 목적지를 줄 수 있습니다. 공용 주소, 외부 포트, 제공자가 실제로 트래픽을 전달하는 지점을 적어 두세요. 그다음 요금제와 계정이 인바운드 연결을 아예 허용하는지 확인하세요. 전용 출구 주소는 포트 포워딩 계약이 아닙니다.

이 구분은 도달성을 기대하며 고정 IP를 사는 사람을 잡아냅니다. 주소가 안정적이라는 사실은 제공자가 인바운드 포트를 당신의 세션으로 전달하는지에 대해 아무것도 말해 주지 않습니다.

제공자를 확인하기 전에 리스너를 확인하세요

Core는 매핑이 전달하는 주소와 포트에서 수신해야 하고, 호스트 방화벽이 이를 허용해야 합니다. 노드가 컨테이너나 다른 LAN 머신에서 실행된다면 다음 홉과 그 응답 경로도 사슬의 일부입니다.

들어오는 패킷을 버리는 제공자 쪽에서는 로컬 방화벽 규칙으로 매핑을 만들 수 없고, 제공자의 매핑은 loopback에만 바인딩된 프로세스에는 닿지 않습니다. 양쪽이 같은 튜플에 합의해야 하며, 그래서 첫 단계는 튜플을 추측하는 것이 아니라 적어 두는 것입니다.

공지한 엔드포인트를 실제 매핑과 일치하게 유지하세요. 고정 주소는 할당된 포트나 그 임대를 재연결 사이에 영구적으로 만들지 않으므로, 몇 달 전에 게시한 엔드포인트가 지금은 아무것도 가리키지 않을 수 있습니다. 재연결 후마다 제공자 페이지를 다시 읽고 노드가 공지하는 내용과 비교하세요. 포트가 옮겨졌다면 옛 엔드포인트는 이제 아무의 것도 아니거나 다른 사람의 것입니다.

연결 총수가 아니라 인바운드 플래그를 읽으세요

권한이 있는 로컬 RPC 컨텍스트에서 이 읽기 전용 쿼리는 피어를 나열합니다:

bitcoin-cli getpeerinfo

RPC 참조는 inbound를 인바운드 연결이면 true, 아웃바운드 연결이면 false로 정의합니다. 그 필드를 보세요. 열을 넘는 총수는 방향에 대해 아무것도 증명하지 못하며, 총수와 분류는 구성과 릴리스에 따라 달라집니다.

그다음 매핑된 엔드포인트를 외부에서, 실행 권한이 있는 새 도달성 점검으로 시험하고 대응하는 인바운드 피어가 나타나는지 보세요. 지원 스레드에 붙여 넣는 출력은 조심하세요. 피어 주소는 다른 사람의 연결 정보이며, 질문에 답을 얻기 위해 공개할 필요가 없습니다.

RPC를 노출해서 해결하지 마세요

Bitcoin Core의 RPC 문서는 RPC 인터페이스를 공용 인터넷에 노출하지 말라고 명시적으로 경고합니다. 피어 연결과 인증된 관리는 서로 다른 서비스이며, RPC를 게시해 P2P를 도달 가능하게 만드는 것은 연결 문제를 훨씬 나쁜 문제와 맞바꾸는 일입니다.

인바운드 P2P에 전혀 의존하고 싶지 않다면 문서화된 대안은 onion 서비스이며, 나름의 전제 조건이 있습니다. Tor가 있어야 하고, 제어 인증이 구성되어야 하며, 서비스를 만들 수 있는 수신 설정이 필요합니다. VPN이 마침 돌고 있다고 해서 생기는 것이 아닙니다.

Core를 VPN에서 제외하는 것은 세 번째 설계이며 일부 운영자에게는 정당하지만, 피어 트래픽을 평소 연결에 올립니다. 그것은 VPN을 통한 인바운드 접근이 아니며, 라우터나 상위 NAT에 여전히 자체 허용 항목이 필요할 수 있습니다. 다른 무엇을 바꾸기 전에 세 가지 중 무엇을 실제로 시험하는지 고르세요.