ไม่มี peer ขาเข้าบนโหนด Bitcoin ของคุณหลัง VPN ใช่หรือไม่
peer ขาออกและเชนที่ซิงก์แล้วไม่ได้พิสูจน์การเข้าถึงจากภายนอก ตรวจสอบการแมป ตัวรับฟัง และแฟล็ก inbound ก่อนจะโทษ VPN
โหนดของคุณซิงก์แล้ว 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 ต้นทางอาจยังต้องมีรายการที่อนุญาตของตัวเอง เลือกให้ชัดว่าคุณกำลังทดสอบสิ่งใดในสามสิ่งก่อนจะเปลี่ยนอย่างอื่น