ลูปเส้นทางเริ่มต้นของ WireGuard: หาเส้นทางของปลายทาง

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

ยืนยันลูปก่อนเปลี่ยนเส้นทาง

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

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

รวมกฎนโยบายไว้ในการบันทึกนั้นด้วย เส้นทางเริ่มต้นที่ดูถูกต้องในตารางหลักยังอาจแพ้กฎที่เลือกตารางอื่นสำหรับทราฟฟิกที่มีเครื่องหมายหรือไม่มีเครื่องหมาย และลูปจะปรากฏอีกครั้งพร้อมตารางเส้นทางที่ดูปกติ

อ่านเส้นทางของปลายทาง ไม่ใช่เส้นทางของอุโมงค์

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

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

คืนค่าเส้นทางของปลายทางด้วยการเปลี่ยนแปลงที่สอดคล้องกันเพียงครั้งเดียว

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

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

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

ตรวจสอบ แล้วเก็บทางกลับไว้

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

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

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