แฮนด์เชกทำงานอยู่ แต่แอดเดรสหายไป: สามสถานะของ WireGuard
แฮนด์เชกใหม่พิสูจน์ว่าเพียร์ตอบกลับแล้ว ไม่ได้พิสูจน์ว่าอินเทอร์เฟซยังถือแอดเดรสของตน หรือแพ็กเก็ตถัดไปจะออกผ่านลิงก์ขึ้นที่ตั้งใจไว้
WireGuard มีแฮนด์เชกใหม่และไม่มีแอดเดรสพร้อมกันได้ และสถานะนั้นสอดคล้องกันไม่ใช่ขัดแย้ง แฮนด์เชกเป็นเหตุการณ์ของเพียร์ แอดเดรสเป็นของอินเทอร์เฟซ และเส้นทางเป็นตัวตัดสินว่าแพ็กเก็ตออกผ่านลิงก์ขึ้นใด สามชั้น สามเจ้าของ และแต่ละชั้นล้มเหลวได้ขณะที่อีกสองชั้นดูปกติ
การอ่านทั้งหมดเป็นสถานะเดียวคือสิ่งที่เปลี่ยนการวินิจฉัยสองนาทีให้กลายเป็นทั้งบ่ายของการรีสตาร์ตบริการ
แฮนด์เชกเป็นเหตุการณ์ของเพียร์ ไม่ใช่เหตุการณ์ของการกำหนดแอดเดรส
แฮนด์เชกของ WireGuard พิสูจน์ว่าเพียร์ที่กำหนดไว้ตอบกลับด้วยคีย์ที่ถูกต้อง และคีย์ของเซสชันยังใช้ได้ มันไม่ได้บอกอะไรเกี่ยวกับแอดเดรสโลคัลบนอินเทอร์เฟซ และไม่ได้บอกว่ามีเส้นทางใดชี้ไปที่นั่นหรือไม่ ตัวช่วยหรือตัวจัดการเครือข่ายเป็นผู้กำหนดแอดเดรส ขณะที่การตั้งค่าโปรโตคอลเพียงระบุชื่อเพียร์และคีย์ การสับสนสองอย่างนี้คือเหตุที่แฮนด์เชกที่ปกติดีถูกอ่านว่าเป็นทันเนลที่ใช้งานได้
นี่คือเหตุที่ wg show รายงานแฮนด์เชกอายุไม่กี่วินาทีบนอินเทอร์เฟซที่ไม่สามารถรับแพ็กเก็ตแม้แต่ตัวเดียวจากแอปพลิเคชันได้
ตัวจัดการที่สร้างอินเทอร์เฟซใหม่สามารถทิ้งแอดเดรสได้โดยไม่แตะการตั้งค่าเพียร์ และแฮนด์เชกครั้งถัดไปสำเร็จทันทีเพราะคีย์ไม่เคยเปลี่ยน บันทึกที่บอกว่าแฮนด์เชกสำเร็จจึงถูกต้องแต่ไม่เกี่ยวกับความล้มเหลว
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
แอดเดรสของอินเทอร์เฟซมีเจ้าของของตัวเอง
แอดเดรสบนอุปกรณ์ทันเนลอาจมาจากบรรทัด Address ของตัวช่วย จากไคลเอนต์ DHCP ที่ทำงานบนอินเทอร์เฟซ หรือจากดีมอนจัดการที่สร้างขึ้นตอนเชื่อมต่อ ไม่ว่าจะเป็นอะไร ส่วนประกอบนั้นเป็นเจ้าของแอดเดรสและจะคืนค่าหรือไม่ก็ตามตรรกะของมัน การอ่านแอดเดรสโดยไม่ระบุเจ้าของทำให้อธิบายไม่ได้ว่าทำไมมันหายไป
เจ้าของสองรายบนอินเทอร์เฟซเดียวคือความล้มเหลวแบบคลาสสิก การเริ่มตัวช่วยและตัวจัดการเครือข่ายเดสก์ท็อปบนอุปกรณ์เดียวกันทำให้เกิดการแย่งกัน โดยฝ่ายหนึ่งลบสิ่งที่อีกฝ่ายเพิ่งตั้งค่าไว้ และปลายทางยังคงตอบกลับตลอดเวลา
เลือกเจ้าของเพียงรายเดียวและให้เครื่องมืออีกตัวเฝ้าดูแทนการจัดการ การตัดสินใจนี้ควรบันทึกไว้ เพราะอาการจะปรากฏในอีกหลายสัปดาห์และดูเหมือนแอดเดรสหายแบบสุ่ม
เส้นทางเป็นตัวเลือกลิงก์ขึ้น ไม่ใช่อินเทอร์เฟซ
เส้นทางภายในที่ชี้ไปยัง wg0 ตัดสินว่า ทราฟฟิกเข้าสู่ทันเนล การตัดสินใจแยกต่างหากส่งแพ็กเก็ตภายนอกที่เข้ารหัสไปยังเพียร์ และบนโฮสต์ที่มีหลายลิงก์ขึ้น การตัดสินใจนั้นมาจากตารางส่งต่อและกฎนโยบาย การโรม Wi-Fi เปลี่ยนเส้นทางภายนอกได้โดยไม่แตะแอดเดรสภายใน
ดังนั้นทันเนลที่ใช้งานได้กับเพียร์ที่เข้าถึงไม่ได้จึงเป็นสถานะที่เข้ากันได้ เช่นเดียวกับเพียร์ที่ถูกต้องกับเส้นทางภายในที่เสีย การสังเกตทั้งสามต้องทำพร้อมกันในเวลาเดียวกัน ไม่อย่างนั้นการเปรียบเทียบก็ไม่มีความหมาย
เปรียบเทียบสามสถานะในการตรวจครั้งเดียว
คำสั่งอ่านอย่างเดียวสามคำสั่งตอบคำถามสามข้อตามลำดับที่แยกความล้มเหลวได้เร็วที่สุด รันโดยไม่เปลี่ยนแปลงสิ่งใดระหว่างนั้น
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferคำสั่งแรกแสดงว่าอินเทอร์เฟซมีแอดเดรสหรือไม่ คำสั่งที่สองแสดงว่าอุปกรณ์ใดจะถูกใช้สำหรับปลายทางหนึ่งในตอนนี้ คำสั่งที่สามรายงานเวลาของแฮนด์เชกล่าสุดและตัวนับไบต์ และเป็นหนึ่งเดียวในสามคำสั่งที่อธิบายเพียร์แทนที่จะเป็นโฮสต์โลคัล
อ่านตัวนับควบคู่กับเวลา แฮนด์เชกที่ต่ออายุตลอดเวลาขณะที่การถ่ายโอนนิ่งอยู่หมายถึงเพียร์ตอบกลับแต่ไม่มีอะไรที่มีประโยชน์ผ่านไป ซึ่งชี้ไปที่การหาเส้นทางหรือ ACL ไม่ใช่ที่คีย์ เวลาที่หยุดเดินหน้าทั้งที่มีแอดเดรสอยู่กลับชี้ไปทางต้นน้ำ ทั้งสองการอ่านมาจากบรรทัดผลลัพธ์เดียวกัน และไม่มีอันใดมองเห็นได้หากตรวจเพียงว่ามีแฮนด์เชกอยู่
แก้ไขสถานะเฉพาะที่ผิด แล้วทดสอบแอปพลิเคชันอีกครั้งไม่ใช่ทันเนล แฮนด์เชกใหม่เป็นหลักฐานเกี่ยวกับเพียร์ และหลักฐานเกี่ยวกับเพียร์ไม่ใช่หลักฐานว่าคำขอถัดไปจากเบราว์เซอร์ของคุณจะพบแอดเดรส เส้นทาง และลิงก์ขึ้นที่ใช้งานได้ คู่มือ wg-quick ระบุชัดเจนว่าตัวช่วยตั้งค่าสิ่งใดและสิ่งใดเป็นของโปรโตคอล