เพียร์ WireGuard ตัวหนึ่งเข้าไม่ถึงขณะที่อีกตัวทำงาน: รายการตรวจสอบ

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

ขั้นที่ 1: เขียนเส้นทางที่แพ็กเก็ตควรจะวิ่ง

ไคลเอนต์สองตัวบนฮับเดียวกันไม่ได้เข้าถึงกันโดยอัตโนมัติ ในแบบฮับและซี่ล้อ เซิร์ฟเวอร์รับแพ็กเก็ตบน wg0 และต้องส่งต่อออกจาก wg0 ไปยังเพียร์อีกตัว ซึ่งต้องเปิดการส่งต่อ IP และมีกฎการส่งต่อ ในแบบเพียร์ถึงเพียร์โดยตรง แต่ละฝั่งต้องมีปลายทางของอีกฝั่งและที่อยู่ของอุโมงค์อีกฝั่งอยู่ใน AllowedIPs ตัดสินใจก่อนว่าคุณกำลังแก้แบบไหนก่อนจะอ่านคอนฟิกใด ๆ

เส้นทางที่คาดไว้ยังบอกด้วยว่าควรมองตรงไหน ถ้าแพ็กเก็ตต้องข้ามฮับ ฮ็อปที่ล้มเหลวคือ AllowedIPs ของผู้ส่ง การส่งต่อของฮับ หรือ AllowedIPs ของผู้รับ ถ้าควรวิ่งตรง ฮับก็ไม่เกี่ยวข้อง และฟิลด์ปลายทางบนเพียร์ทั้งสองคือสิ่งที่สำคัญ

ขั้นที่ 2: เปรียบเทียบ AllowedIPs ทั้งสองฝั่ง ไม่ใช่ฝั่งเดียว

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

อ่านสถานะจริงแทนไฟล์ เพราะการโหลดใหม่ก่อนหน้านี้อาจล้มเหลวอย่างเงียบ ๆ: sudo wg show wg0 allowed-ips บนเซิร์ฟเวอร์ รายการของเพียร์ที่ล้มเหลวต้องมีที่อยู่ของอุโมงค์ เช่น 10.90.0.3/32 บนไคลเอนต์ รายการของเพียร์เซิร์ฟเวอร์ต้องมีปลายทางที่คุณทดสอบ ไม่ว่าจะเป็นที่อยู่ของอุโมงค์ฮับหรือซับเน็ตระยะไกล ช่วงที่ซ้อนกันทำให้การค้นหาไม่ชัดเจนและอาจเลือกเพียร์ที่คุณไม่ได้ตั้งใจ จึงควรแยกให้ชัด

ขั้นที่ 3: ตรวจสอบที่อยู่ต้นทางภายใน

ไคลเอนต์ที่เราต์ 10.90.0.3 ผ่าน wg0 แต่ส่งแพ็กเก็ตจากที่อยู่ Wi-Fi ของตัวเองจะถูกผู้รับปฏิเสธ เพราะต้นทางไม่ตรงกับ AllowedIPs ของเพียร์ ยืนยันว่าเคอร์เนลเลือกอะไรจริง ๆ ด้วย ip route get 10.90.0.3 from 10.90.0.2 และยืนยันที่อยู่ที่กำหนดให้อินเทอร์เฟซอุโมงค์ด้วย ip -brief addr show wg0

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

ขั้นที่ 4: ทบทวนการส่งต่อของฮับและเส้นทางกลับ

ถ้าฮับต้องส่งต่อระหว่างเพียร์ เคอร์เนลต้องมี net.ipv4.ip_forward=1 และไฟร์วอลล์ต้องยอมรับโฟลว์ที่ถูกส่งต่อ คือเข้า wg0 ออก wg0 จากที่อยู่อุโมงค์ของผู้ส่งไปยังของผู้รับ ความล้มเหลวที่พบบ่อยคือ กฎขาเข้าที่ยอมรับ UDP 51820 แต่ไม่มีกฎส่งต่อ] ทำให้แฮนด์เชกสำเร็จแต่เพย์โหลดตาย ให้แสดงกฎที่มีผลด้วย sudo nft list ruleset หรือคำสั่งเทียบเท่าของตัวจัดการไฟร์วอลล์ของคุณ

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

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

ขั้นที่ 5: เปลี่ยนเพียงอย่างเดียวและอย่าให้เพียร์ที่ทำงานได้เสียหาย

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

บันทึกว่าเส้นทางไหนสำเร็จ ไหนล้มเหลว และเอาต์พุตของคำสั่งที่แม่นยำของแต่ละอัน การเปรียบเทียบนั้นมีค่ากว่ารายงานกว้าง ๆ ว่า VPN พัง และเป็นสิ่งแรกที่คนถัดไปจะถามหา