โหนดของคุณซิงก์แล้ว VPN รายงานว่าเชื่อมต่ออยู่ และ getpeerinfo แสดง peer แปดหรือสิบราย ไม่มีรายใดมี inbound ถูกตั้งเป็น true การผสมแบบนี้เป็นเรื่องปกติและไม่ใช่ข้อผิดพลาด: การเชื่อมต่อขาออกพิสูจน์ว่าโหนดเข้าถึงผู้อื่นได้ และไม่มีอะไรในนั้นพิสูจน์ว่าใครจะเข้าถึงคุณได้ หากเป้าหมายคือโหนดที่รับการเชื่อมต่อ P2P ขาเข้าผ่าน VPN คุณต้องทดสอบทิศทางนั้นแยกต่างหาก

ติดตามแพ็กเก็ตจาก peer ไปยังตัวรับฟังของคุณ

P2P ขาเข้าเป็นห่วงโซ่ของสี่สิ่ง และมันขาดที่ห่วงที่อ่อนแอที่สุด ไม่ใช่ห่วงที่น่าสนใจที่สุด

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

ค่าเริ่มต้น P2P ของ Core บนเมนเน็ตคือ 8333 แต่ผู้ให้บริการอาจให้พอร์ตสาธารณะคนละพอร์ตและปลายทางฝั่งไคลเอนต์คนละที่ จดที่อยู่สาธารณะ พอร์ตภายนอก และจุดที่ผู้ให้บริการส่งทราฟฟิกจริง จากนั้นยืนยันว่าแพ็กเกจและบัญชีของคุณอนุญาตการเชื่อมต่อขาเข้าเลยหรือไม่ เพราะที่อยู่ทางออกเฉพาะไม่ใช่สัญญาการส่งต่อพอร์ต

ความต่างนี้จับคนที่ซื้อ IP แบบคงที่โดยหวังว่าจะเข้าถึงได้ ความที่ที่อยู่คงที่ไม่บอกอะไรเลยว่าผู้ให้บริการส่งต่อพอร์ตขาเข้าไปยังเซสชันของคุณหรือไม่

ตรวจสอบตัวรับฟังก่อนตรวจสอบผู้ให้บริการ

Core ต้องรับฟังบนที่อยู่และพอร์ตที่การแมปส่งไปถึง และไฟร์วอลล์ของโฮสต์ต้องอนุญาต หากโหนดทำงานในคอนเทนเนอร์หรือเครื่องอื่นใน LAN การกระโดดถัดไปและเส้นทางตอบกลับก็อยู่ในห่วงโซ่ด้วย

กฎไฟร์วอลล์ภายในไม่สามารถสร้างการแมปที่ผู้ให้บริการซึ่งทิ้งแพ็กเก็ตขาเข้าได้ และการแมปของผู้ให้บริการไม่สามารถไปถึงโปรเซสที่ผูกกับ loopback เท่านั้น ทั้งสองฝั่งต้องตกลงบนทูเพิลเดียวกัน นั่นคือเหตุผลที่ขั้นแรกคือจดทูเพิลลงไปแทนที่จะเดา

รักษาปลายทางที่ประกาศให้สอดคล้องกับการแมปที่ใช้งานจริง ที่อยู่คงที่ไม่ได้ทำให้พอร์ตที่จัดสรรหรือสัญญาเช่าของมันถาวรข้ามการเชื่อมต่อใหม่ ดังนั้นปลายทางที่ประกาศเมื่อหลายเดือนก่อนอาจชี้ไปที่ไม่มีอะไรแล้ว อ่านหน้าผู้ให้บริการอีกครั้งหลังการเชื่อมต่อใหม่ทุกครั้งและเทียบกับสิ่งที่โหนดของคุณประกาศ หากพอร์ตย้ายไป ปลายทางเก่าตอนนี้ไม่เป็นของใครหรือเป็นของคนอื่น

อ่านแฟล็กขาเข้า ไม่ใช่จำนวนการเชื่อมต่อทั้งหมด

จากบริบท RPC ภายในที่ได้รับอนุญาต คำค้นแบบอ่านอย่างเดียวนี้จะแสดงรายการ peer:

bitcoin-cli getpeerinfo

เอกสารอ้างอิง RPC inbound เป็น true สำหรับการเชื่อมต่อขาเข้าและ false สำหรับการเชื่อมต่อขาออก ดูที่ฟิลด์นั้น ยอดรวมที่เกินสิบไม่พิสูจน์อะไรเกี่ยวกับทิศทาง และยอดรวมกับหมวดหมู่ก็เปลี่ยนตามการกำหนดค่าและเวอร์ชันอยู่แล้ว

จากนั้นทดสอบปลายทางที่แมปจากภายนอกด้วยการตรวจสอบการเข้าถึงใหม่ที่คุณได้รับอนุญาตให้รัน และดูว่ามี peer ขาเข้าที่สอดคล้องปรากฏขึ้นหรือไม่ ระวังผลลัพธ์ที่คุณวางในกระทู้สนับสนุน: ที่อยู่ของ peer คือรายละเอียดการเชื่อมต่อของคนอื่น และไม่จำเป็นต้องเผยแพร่เพื่อให้คำถามของคุณได้รับคำตอบ

อย่าแก้ด้วยการเปิดเผย RPC

เอกสาร RPC ของ Bitcoin Core เตือนอย่างชัดเจนไม่ให้เปิดเผยอินเทอร์เฟซ RPC สู่อินเทอร์เน็ตสาธารณะ การเชื่อมต่อ peer และการดูแลระบบที่ผ่านการพิสูจน์ตัวตนเป็นบริการที่ต่างกัน และการทำให้ P2P เข้าถึงได้ด้วยการเผยแพร่ RPC คือการแลกปัญหาการเชื่อมต่อกับปัญหาที่แย่กว่ามาก

หากคุณไม่อยากพึ่งพา P2P ขาเข้าเลย ทางเลือกที่บันทึกไว้คือบริการ onion และมันมีข้อกำหนดเบื้องต้นของตัวเอง: มี Tor พร้อมใช้งาน ตั้งค่าการพิสูจน์ตัวตนของ control แล้ว และการตั้งค่าการรับฟังที่อนุญาตให้สร้างบริการได้ มันไม่ได้ปรากฏขึ้นเพียงเพราะบังเอิญมี VPN ทำงานอยู่

การแยก Core ออกจาก VPN เป็นดีไซน์ที่สาม และชอบธรรมสำหรับผู้ดูแลบางราย แต่มันวางทราฟฟิก peer ไว้บนการเชื่อมต่อปกติของคุณ นั่นไม่ใช่การเข้าถึงขาเข้าผ่าน VPN และเราเตอร์หรือ NAT ต้นทางอาจยังต้องมีรายการที่อนุญาตของตัวเอง เลือกให้ชัดว่าคุณกำลังทดสอบสิ่งใดในสามสิ่งก่อนจะเปลี่ยนอย่างอื่น

บทความที่เกี่ยวข้อง