การตั้งค่า punchy ของ Nebula: อันไหนแก้ NAT ของคุณ

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

ยืนยันปลายทางก่อนเรื่องจังหวะเวลา

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

บันทึกคู่ปลายทางที่คุณใช้ทดสอบไว้ เพื่อให้การเปรียบเทียบครั้งหลังใช้เพียร์เดียวกัน ไม่ใช่เครื่องอื่นอีกสองเครื่อง

punch รักษาการแมป ส่วน respond เปิดทิศทาง

ตัวเลือก punch ส่งแพ็กเก็ตว่างเป็นระยะไปยังแอดเดรสชั้นล่างของเพียร์ที่มีอุโมงค์อยู่แล้ว จุดประสงค์ไม่หรูหรา คือป้องกันไม่ให้ NAT ที่มีสถานะหรือไฟร์วอลล์ปล่อยให้การแมปที่เส้นทางตรงต้องพึ่งพาหมดอายุ ตัวเลือก respond เปลี่ยนสิ่งที่เกิดขึ้นเมื่อมีการแจ้งเตือนจากประภาคาร ทำให้โฮสต์พยายามจับมือย้อนกลับไปยังเพียร์ที่พยายามเข้าถึงมัน ทั้งสองเป็นกลไกต่างกันที่มีรูปแบบล้มเหลวต่างกัน

เลือก punch เมื่อเส้นทางตรงทำงานแล้วค่อย ๆ อ่อนลง เลือก respond เมื่อเส้นทางไม่เคยเกิดขึ้นในทิศทางหนึ่ง การเปิดทั้งสองอย่างแล้วหวังคือวิธีที่การแก้ไขห้านาทีกลายเป็นการปรับจูนหนึ่งสัปดาห์

ความล่าช้าตัดสินว่าเมื่อไร ไม่ใช่ว่าจะเกิดหรือไม่

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

ปล่อยมันไว้จนกว่ากลไกจะถูกต้อง จากนั้นปรับเพียงอันเดียว และจดค่าเดิมไว้

เมื่อรีเลย์คือคำตอบที่ซื่อตรง

การรวมกันของ NAT บางแบบไม่สามารถรองรับเส้นทางตรงได้ ไม่ว่าจะจัดจังหวะอย่างไร NAT แบบสมมาตรทั้งสองข้าง หรือไฟร์วอลล์ที่ทิ้งทราฟฟิกขาเข้าที่ไม่ได้ร้องขอทั้งหมด ไม่เหลืออะไรให้เจาะ

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

ทดสอบคู่ที่ล้มเหลว หลังจากปล่อยว่างไว้

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

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