พูลขุดเหมืองผ่าน VPN: เก็บเซสชันให้อยู่บนเส้นทางที่ถูกต้อง
ไมเนอร์พูลเปิดเซสชัน Stratum ขาออกเพียงหนึ่งเซสชัน ไม่ใช่พอร์ต peer วางอุโมงค์ไว้ใต้กระบวนการนั้นแล้วอ่านเส้นทางและตัวแปลงชื่อจากเนมสเปซของมัน
ซอฟต์แวร์ขุดเหมืองเก็บซ็อกเก็ตเดียวเปิดไว้ยังที่อยู่เดียว และทุกคำถามเกี่ยวกับอุโมงค์ เส้นทาง และงานที่ถูกให้เครดิตล้วนแขวนอยู่บนซ็อกเก็ตนั้น ซ็อกเก็ตนั้นคือเซสชันไคลเอนต์ขาออกไปยังปลายทางของพูล ไม่ใช่ตัวรับฟังที่รับ peer การเดินด้านล่างติดตามมันตั้งแต่สี่ค่าที่พูลออกให้ไปจนถึงส่วนแบ่งที่พูลบันทึกจริง และปล่อยบริการอื่นของโฮสต์ไว้ตามเดิม ทุกขั้นตอนให้คำตอบที่คุณเปรียบเทียบได้ ไม่ใช่ความรู้สึก
เริ่มจากปลายทางที่พูลออกให้จริง
พูลให้ค่าสี่ค่าที่ประกอบเป็นสัญญาทั้งหมด: ชื่อโฮสต์หรือที่อยู่ พอร์ต รูปแบบโปรโตคอล และสตริงบัญชี รับค่าเหล่านี้จากแดชบอร์ดของพูลหรือข้อความต้อนรับ ไม่ใช่จากบทช่วยสอนของพูลอื่น มีชาร์ดระดับภูมิภาคสำหรับบริการเดียวกัน ดังนั้นชื่อโฮสต์ที่คัดลอกจากคู่มือเก่ายังเชื่อมต่อได้และยังให้เครดิตบัญชีที่คุณไม่เคยตั้งใจจะใช้ได้ คัดลอกค่าทั้งสี่ลงในคอนฟิกูเรชันของไมเนอร์ตามตัวอักษร เพราะสตริงบัญชีที่พิมพ์ใหม่จะสูญเสียตัวคั่น
กระแสที่คุณกำลังกำหนดเส้นทางคือสิ่งที่คู่มือนักพัฒนา Bitcoin เรียกว่า เซสชัน Stratum : การเชื่อมต่อ TCP สองทางที่คงอยู่ ซึ่งพูลแจกจ่ายงานและไมเนอร์ส่งส่วนแบ่งกลับ ไม่ใช่กระแสเดียวกับการเชื่อมต่อ peer ของโหนดเต็มหรือการซิงก์เชนของกระเป๋าเงิน และการพับทั้งหมดนั้นเข้าคลาสทราฟฟิกเดียวคือจุดที่ความสับสนส่วนใหญ่เริ่มต้น มีเพียงอย่างแรกเท่านั้นที่อยู่ภายใต้นโยบายนี้
ที่ใดที่พูลเสนอ TLS ให้คงการตรวจสอบเซิร์ฟเวอร์ตามที่เอกสารกำหนด อุโมงค์เข้ารหัสท่อนจากการเครื่องของคุณถึงเซิร์ฟเวอร์ VPN และสิ้นสุดตรงนั้น มันไม่ได้รับประกันผู้ที่ตอบกลับอีกฝั่ง ให้คงการตรวจสอบทั้งสองไว้ ข้างละหนึ่ง หากต้องการให้เซสชันอยู่รอดจากการออกที่ถูกบุกรุก
ผูกอุโมงค์กับกระบวนการ ไม่ใช่กับครัวเรือน
จุดผูกสองจุดใช้ได้: รันไคลเอนต์ VPN ภายในเนมสเปซเครือข่ายที่ไมเนอร์ใช้ หรือมอบเกตเวย์ให้เนมสเปซนั้นพาทราฟฟิกเข้าไปในอุโมงค์ การจัดวางทั้งสองแบบวางเซสชันบนเส้นทางก่อนที่พูลจะเห็นมัน ความล้มเหลวปกติคือไคลเอนต์บนโฮสต์ ไมเนอร์ในคอนเทนเนอร์ที่มีบริดจ์ของตัวเอง และเส้นทางของโฮสต์ที่คอนเทนเนอร์ไม่เคยถาม หน้าต่างไคลเอนต์ดูปกติขณะที่พูลบันทึกที่อยู่บ้านของคุณ
ตรวจสอบการขนส่งของอุโมงค์เองก่อนจำกัดอะไร ไคลเอนต์ต้องไปถึงเซิร์ฟเวอร์ของมันผ่านชั้นล่าง ดังนั้นนโยบายที่ดักทุกแพ็กเก็ตก็ดักแพ็กเก็ตที่จะสร้างอุโมงค์ด้วย จากนั้นอุโมงค์เริ่มไม่ได้และไม่มีอะไรอื่นออกไปด้วย เลือกด้วยฟีเจอร์อุโมงค์แยกของไคลเอนต์ว่าอะไรเข้าไปในอุโมงค์ การแก้ไขเส้นทางเริ่มต้นด้วยมือคือวิธีที่ชั้นล่างหายไป
เมื่อนโยบายเข้าที่แล้ว ให้อ่านตารางซ็อกเก็ตในเนมสเปซที่เป็นเจ้าของไมเนอร์ กระแสไปยังพอร์ตของพูลควรอยู่บนอินเทอร์เฟซของอุโมงค์ และคำสั่งสองคำตอบคำถามนั้น พอร์ตด้านล่างเป็นตัวอย่าง ให้แทนที่ด้วยพอร์ตที่พูลออกให้
sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10อ่านเส้นทางและตัวแปลงชื่อจากบริบทของไมเนอร์เอง
การกำหนดเส้นทางและการแปลงชื่อเป็นรายเนมสเปซ ดังนั้นการตรวจที่รันในเชลล์ธรรมดาจะอธิบายเครื่องผิดทุกครั้งที่ไมเนอร์อยู่ในคอนเทนเนอร์ เข้าเนมสเปซก่อนแล้วถามว่าอินเทอร์เฟซใดจะพาแพ็กเก็ตไปยังที่อยู่ของพูล และตัวแปลงชื่อใดจะตอบสำหรับชื่อโฮสต์ของมัน คำตอบของโฮสต์ไม่ถ่ายโอน และช่องว่างระหว่างกันเป็นแหล่งที่มาทั่วไปของการตำหนิผิดที่
ตั้งชื่ออินเทอร์เฟซที่คุณได้: อุโมงค์หมายความว่าเซสชันอยู่บนเส้นทางที่ตั้งใจ ขณะที่ลิงก์กายภาพหมายความว่ากฎจับได้เร็วกว่าที่คุณคาด ความยาวพรีฟิกซ์ตัดสินก่อน จากนั้นเมตริก จากนั้นกฎนโยบาย ตารางที่มีรายการเริ่มต้นหลายรายการจึงไม่ทำแพ็กเก็ตซ้ำ มันแค่แพ้
ตัวแปลงชื่อล้มเหลวแยกจากเส้นทาง อุโมงค์ที่เขียน /etc/resolv.conf ใหม่สามารถทิ้งเนมสเปซให้ชี้ไปยังตัวแปลงชื่อที่เข้าถึงได้เฉพาะจากในอุโมงค์ ซึ่งล้มเหลวก่อนการจับมือ TCP ใดจะเกิดขึ้น แก้ชื่อโฮสต์ของพูลภายในเนมสเปซและเทียบกับที่อยู่ที่เผยแพร่ หากการค้นหาหมดเวลาหรือคืนค่าอื่น ให้แก้การแปลงชื่อก่อนแตะเส้นทาง
แยกไคลเอนต์ของพูลกับตัวรับฟังของโหนดออกจากกัน
พอร์ต 8333 คือพอร์ต peer ของ Bitcoin Core ที่โหนดเต็มรับฟังการเชื่อมต่อขาเข้า ไมเนอร์พูลไม่เคยต้องการให้มันเปิด และการเปิดก็ไม่ได้ซ่อมแซมความล้มเหลวขาออก ตัวรับฟังขาเข้าและเซสชันขาออกเป็นบทบาทตรงข้ามด้วยข้อสันนิษฐานความเชื่อใจตรงข้าม ไม่มีสิ่งใดในคอนฟิกูเรชันของไมเนอร์ผูกพอร์ตนั้น ดังนั้นพอร์ตที่ปิดจึงอธิบายข้อผิดพลาดใดที่มันรายงานไม่ได้ คำแนะนำที่เขียนขึ้นเพื่อความเข้าถึงของโหนดจึงอาจทิ้งบริการสาธารณะให้ทำงานบนโฮสต์ที่ควรจะส่งเฉพาะส่วนแบ่ง
หากเครื่องเดียวทำทั้งสองอย่างจริง ให้ถือว่าแต่ละบทบาทเป็นบริการของตัวเองด้วยการตัดสินการเข้าถึงของตัวเอง ตัวรับฟังของโหนดอยู่หลังนโยบายที่คุณใช้กับบริการสาธารณะ และเซสชันของไมเนอร์เป็นของนโยบายขาออกที่เลือกอุโมงค์ บันทึกว่าโฮสต์มีบทบาทใดและลบกฎของอีกบทบาทเมื่อสิ่งนั้นเปลี่ยน เพราะกฎอนุญาตที่ตกค้างมีอายุยืนกว่าเหตุผลของมัน
พิสูจน์ว่าพูลได้รับงาน
พัดลมที่ทำงานหนักและแฮชเรตที่สูงขึ้นแสดงว่าไมเนอร์กำลังคำนวณ ไม่ใช่มีบางอย่างไปถึงพูล หลักฐานอยู่ในตัวนับการส่งของไคลเอนต์หรือบนแดชบอร์ดของพูล: ส่วนแบ่งที่ยอมรับ ส่วนแบ่งที่ปฏิเสธ และเหตุผลที่แนบมากับการปฏิเสธแต่ละครั้ง ตัวเลขเหล่านั้นแยกความล้มเหลวสามอย่างที่ดูเหมือนกันจากภายนอก: ไม่มีเซสชัน เซสชันที่ไม่ได้รับเครดิต และเซสชันที่เชื่อมต่อใหม่ตลอดเวลา อ่านก่อนเปลี่ยนคอนฟิกูเรชันใด
เฝ้าดูความพยายามเชื่อมต่อหนึ่งครั้งพร้อมการบันทึกละเอียดและจดขั้นตอนสุดท้ายที่สำเร็จ ขั้นตอนที่ลำดับหยุดมีประโยชน์กว่าข้อความเดี่ยวใดรอบ ๆ มัน:
| Last stage reached | What it rules out | Probe to run next |
|---|---|---|
| Name lookup completed | Resolver and namespace reachability | ip route get for the returned address |
| TCP connect completed | Route and egress filtering | ss -tnp on the tunnel interface |
| Subscription returned a job | Endpoint or protocol mismatch | Accepted against rejected counts |
จากนั้นให้ไคลเอนต์ทำงานเป็นช่วงเวลาที่กำหนดและนับผลลัพธ์ทั้งสองจากการบันทึกของมัน grep หนึ่งครั้งต่อตัวนับก็พอ และการเปรียบเทียบในช่วงเดียวกันจะแยกพูลที่ช้าออกจากเส้นทางที่พัง ปรับเส้นทางไปยังที่ที่ไคลเอนต์ของคุณเขียน เพราะการนับทั้งสองไม่ขึ้นกับตำแหน่ง:
grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.logหากกฎห้ามการเชื่อมต่อพูลโดยตรงทุกครั้งที่อุโมงค์ล่ม ให้แสดงออกเป็นการบล็อกอย่างชัดเจนที่ปลายทางของพูล ไคลเอนต์ที่พยายามซ้ำเงียบ ๆ ผ่านลิงก์กายภาพจะขุดต่อไปและฝ่าฝืนกฎนั้นต่อไป และจอสถานะของมันจะไม่กล่าวถึง ทดสอบกฎด้วยการทำให้อุโมงค์ล่มโดยเจตนาและยืนยันว่าพอร์ตของพูลเข้าถึงไม่ได้เลย