Không có peer đến trên node Bitcoin của bạn sau VPN?

Node của bạn đã đồng bộ, VPN báo đã kết nối, và getpeerinfo hiển thị tám hoặc mười peer. Không peer nào trong số đó có inbound được đặt thành true. Sự kết hợp đó là bình thường và không phải lỗi: các kết nối đi ra chứng minh node có thể tiếp cận người khác, và không có gì trong đó chứng minh ai đó có thể tiếp cận bạn. Nếu mục tiêu là một node chấp nhận các kết nối P2P đến qua VPN, bạn phải kiểm tra riêng hướng đó.

Theo dõi gói tin từ peer đến trình lắng nghe của bạn

P2P đến là một chuỗi gồm bốn thứ, và nó đứt ở mắt xích yếu nhất chứ không phải ở mắt xích thú vị nhất.

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

Giá trị mặc định P2P của Core trên mạng chính là 8333, nhưng nhà cung cấp có thể cấp cho bạn một cổng công khai khác và một đích khác ở phía máy khách. Hãy ghi lại địa chỉ công khai, cổng bên ngoài và nơi nhà cung cấp thực sự chuyển lưu lượng đến. Sau đó xác nhận rằng gói và tài khoản của bạn có cho phép kết nối đến hay không, vì một địa chỉ thoát riêng không phải là hợp đồng chuyển tiếp cổng.

Sự khác biệt đó bắt được những người mua IP tĩnh với hy vọng có thể tiếp cận. Việc địa chỉ ổn định không nói lên điều gì về việc nhà cung cấp có chuyển tiếp một cổng đến vào phiên của bạn hay không.

Kiểm tra trình lắng nghe trước khi kiểm tra nhà cung cấp

Core phải lắng nghe trên địa chỉ và cổng mà ánh xạ chuyển đến, và tường lửa của máy chủ phải cho phép điều đó. Nếu node chạy trong container hoặc trên một máy khác trong LAN, bước nhảy tiếp theo và tuyến phản hồi của nó cũng thuộc chuỗi.

Một quy tắc tường lửa cục bộ không thể tạo ánh xạ tại nhà cung cấp vốn bỏ các gói đến, và ánh xạ của nhà cung cấp không thể đến được một tiến trình chỉ gắn với loopback. Cả hai nửa phải đồng ý về cùng một bộ giá trị, đó là lý do bước đầu tiên là ghi bộ giá trị ra thay vì đoán nó.

Giữ endpoint được công bố khớp với ánh xạ hiện hành. Một địa chỉ tĩnh không làm cho cổng được cấp hay thời hạn thuê của nó trở nên vĩnh viễn qua các lần kết nối lại, nên một endpoint công bố vài tháng trước có thể giờ không trỏ tới đâu cả. Đọc lại trang của nhà cung cấp sau mỗi lần kết nối lại và so sánh với những gì node của bạn công bố. Nếu cổng đã dịch chuyển, endpoint cũ giờ hoặc không thuộc về ai hoặc thuộc về người khác.

Đọc cờ đến, không phải tổng số kết nối

Từ một ngữ cảnh RPC cục bộ được cấp quyền, truy vấn chỉ đọc này liệt kê các peer:

bitcoin-cli getpeerinfo

Tài liệu tham chiếu RPC định nghĩa inbound là true cho kết nối đến và false cho kết nối đi. Hãy nhìn vào trường đó. Tổng số trên mười không chứng minh được gì về hướng, và các tổng cùng danh mục vốn thay đổi theo cấu hình và phiên bản.

Sau đó kiểm tra endpoint đã ánh xạ từ bên ngoài bằng một lần kiểm tra khả năng tiếp cận mới mà bạn được phép chạy, và xem liệu có xuất hiện một peer đến tương ứng hay không. Hãy cẩn thận với đầu ra bạn dán vào một luồng hỗ trợ: địa chỉ peer là thông tin kết nối của người khác và không cần phải công bố để câu hỏi của bạn được trả lời.

Đừng giải quyết bằng cách phơi bày RPC

Tài liệu RPC của Bitcoin Core cảnh báo rõ ràng chống lại việc phơi bày giao diện RPC ra internet công cộng. Kết nối peer và quản trị có xác thực là những dịch vụ khác nhau, và việc làm P2P có thể tiếp cận bằng cách công bố RPC đánh đổi một vấn đề kết nối lấy một vấn đề tồi tệ hơn nhiều.

Nếu bạn không muốn phụ thuộc vào P2P đến chút nào, phương án thay thế đã được ghi nhận là một dịch vụ onion, và nó có các điều kiện tiên quyết riêng: có Tor, xác thực điều khiển đã được cấu hình và cài đặt lắng nghe cho phép tạo dịch vụ. Nó không xuất hiện chỉ vì tình cờ có một VPN đang chạy.

Loại Core khỏi VPN là thiết kế thứ ba, và chính đáng với một số nhà vận hành, nhưng nó đặt lưu lượng peer lên kết nối thường của bạn. Đó không phải truy cập đến qua VPN, và bộ định tuyến hoặc NAT thượng nguồn vẫn có thể cần mục được cho phép của riêng nó. Hãy chọn xem bạn thực sự đang kiểm tra cái nào trong ba trước khi thay đổi bất cứ điều gì khác.