WireGuard: ไม่มีเส้นทางไปยังเพียร์หลังเปลี่ยนซับเน็ต — สองทางออก
การเปลี่ยนซับเน็ตทำให้ WireGuard พังสองจุด: AllowedIPs และเส้นทางขากลับ เปรียบเทียบการเปลี่ยนเลขในที่กับการสร้างอินเทอร์เฟซใหม่
แฮนด์เชกยังใหม่ใน wg show ปลายทางถูกต้อง กุญแจไม่เคยเปลี่ยน — แต่ ping ยังบอกว่าไม่มีเส้นทางไปยังเพียร์ คุณเปลี่ยนซับเน็ตของอุโมงค์เมื่อชั่วโมงที่แล้ว อาการนั้นเป็นลายเซ็นของการไม่ตรงกันของพรีฟิกซ์ ไม่ใช่ปัญหากุญแจ: WireGuard ทำแฮนด์เชกเสร็จแล้วทิ้งข้อมูลเพราะที่อยู่ต้นทางไม่ตรงกับสิ่งที่เพียร์ฝั่งรับจะยอมรับแล้ว มีสองวิธีที่สมเหตุสมผลในการดำเนินการเปลี่ยนซับเน็ต และทั้งสองล้มเหลวในจุดที่ต่างกัน
สองวิธีในการดำเนินการเปลี่ยน และค่าใช้จ่ายของแต่ละวิธี
ตัวเลือก A คือการเปลี่ยนเลขในที่: แก้ไขที่อยู่ของอินเทอร์เฟซ ช่วงของเพียร์ เส้นทาง และสำเนาของการกำหนดค่าทุกชุด แล้วโหลดใหม่ ตัวเลือก B คือสร้างอินเทอร์เฟซที่สองบนพรีฟิกซ์ใหม่ข้างของเดิม ย้ายเพียร์ และลบอินเทอร์เฟซเดิมเมื่อทราฟฟิกย้ายจริงแล้ว
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
สถานะที่ใช้งานครึ่งๆ กลางๆ คือสิ่งที่ทำให้ตัวเลือก A อันตราย เพราะมันดูไม่พัง อินเทอร์เฟซขึ้น แฮนด์เชกสำเร็จ และมีเพียงเส้นทางข้อมูลที่ล้มเหลว ตัวเลือก B ต้องทำงานมากกว่าแต่รักษาเส้นทางที่ใช้งานได้ให้มีชีวิตอยู่ระหว่างที่คุณตามหาทุกการอ้างอิง
สิ่งที่ต้องเคลื่อนไปพร้อมกันในฝั่งของคุณ
สี่สิ่งบนโฮสต์โลคัลอธิบายซับเน็ตเดียวกัน และการเปลี่ยนหนึ่งคือการเปลี่ยนทั้งหมด: ที่อยู่ของอินเทอร์เฟซ AllowedIPs ของแต่ละเพียร์ เส้นทางที่ระบบใช้สำหรับปลายทางเหล่านั้น และสิ่งที่ผู้จัดการติดตั้งให้แทนคุณ ด้วย wg-quick สองอย่างหลังถูกสร้างจากการกำหนดค่าทุกครั้งที่อินเทอร์เฟซขึ้น ดังนั้นสำเนาที่เก่าจะติดตั้งพรีฟิกซ์เดิมกลับมาอย่างเงียบๆ
เปรียบเทียบสิ่งที่กำหนดไว้กับสิ่งที่ทำงานอยู่จริง แทนที่จะเชื่ออย่างใดอย่างหนึ่ง:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5การค้นหาเส้นทางคือขั้นตอนที่คนข้ามไป มันตอบว่าเคอร์เนลจะทำอะไรจริงสำหรับปลายทางหนึ่ง รวมถึงเส้นทางที่เจาะจงกว่าซึ่งผู้จัดการหรือรันไทม์ของคอนเทนเนอร์ทิ้งไว้ ถ้ามันรายงานอินเทอร์เฟซอื่นที่ไม่ใช่อุโมงค์ การกำหนดค่าไม่ใช่ปัญหา
สำหรับอินเทอร์เฟซที่ทำงานอยู่ ให้ใช้ไฟล์ที่แก้ไขแล้วโดยไม่รื้ออุโมงค์:
wg syncconf wg0 <(wg-quick strip wg0)นั่นอัปเดตเพียร์และช่วงในที่ ไม่ได้อัปเดตที่อยู่ของอินเทอร์เฟซหรือเส้นทาง เพราะสิ่งเหล่านั้นไม่ใช่การตั้งค่าของ WireGuard — การเปลี่ยนเลขจึงยังต้องสร้างอินเทอร์เฟซใหม่หรือเปลี่ยนที่อยู่ด้วย ip แล้วตรวจเส้นทางอีกครั้ง
สิ่งที่ต้องเคลื่อนไปพร้อมกันที่ปลายไกล
นี่คือจุดที่การเปลี่ยนซับเน็ตมักตาย AllowedIPs ไม่ใช่แค่คำใบ้การกำหนดเส้นทาง แต่ยังเป็นรายการที่อยู่ต้นทางที่เพียร์ได้รับอนุญาตให้เสนอด้วย เมื่อคุณเปลี่ยนเลขไคลเอนต์และปล่อย AllowedIPs ของเซิร์ฟเวอร์ไว้บนพรีฟิกซ์เดิม เซิร์ฟเวอร์จะยอมรับแฮนด์เชก รับแพ็กเก็ตที่เข้ารหัสแล้วและทิ้งมัน เพราะต้นทางภายในไม่ตรงกับช่วงใดที่มันเชื่อมโยงกับเพียร์นั้น ไม่มีข้อผิดพลาดถูกบันทึก และไคลเอนต์เห็นการหมดเวลา
ดังนั้นอัปเดตฝั่งรับอย่างตั้งใจ: รายการเพียร์บนเซิร์ฟเวอร์ต้องระบุพรีฟิกซ์ใหม่ของไคลเอนต์ เส้นทางขากลับของเซิร์ฟเวอร์เองต้องชี้ไปที่อุโมงค์สำหรับพรีฟิกซ์นั้น และเครือข่ายปลายน้ำใดๆ หลังเซิร์ฟเวอร์ต้องเรียนรู้เส้นทางใหม่ นโยบายไฟร์วอลล์ที่ระบุช่วงเดิมก็ต้องการการดูแลแบบเดียวกัน และอะไรก็ตามที่ทำการเลือกตามต้นทางก็เช่นกัน
การวินิจฉัยที่แยกความล้มเหลวสองอย่างนั้นราคาถูก แฮนด์เชกใหม่แต่ไม่มีข้อมูลหมายความว่าอุโมงค์ขึ้นอยู่และการกำหนดที่อยู่ภายในไม่ตรงกัน ไม่มีแฮนด์เชกเลยหมายความว่าคุณกำลังดูการเข้าถึงหรือกุญแจ อย่าหมุนกุญแจเพราะปัญหาพรีฟิกซ์ เพราะมันรีเซ็ตสิ่งเดียวที่ทำงานอยู่
สำเนาเก่าที่อายุยืนกว่าการแก้ไขของคุณ
การแก้ไขไฟล์ไม่เหมือนกับการเปลี่ยนระบบที่กำลังทำงาน และสำเนามีมากกว่าที่คนคาดคิด: ยูนิตหรือผู้จัดการที่เป็นเจ้าของอินเทอร์เฟซ โปรไฟล์ที่สองชื่อเดียวกันในไดเรกทอรีอื่น คอนเทนเนอร์ที่การกำหนดค่าอบอยู่ในอิมเมจ อินเทอร์เฟซของเราเตอร์ที่เก็บเวอร์ชันที่แก้ไขของตัวเอง และแอปไคลเอนต์ที่นำเข้าอุโมงค์ที่บันทึกไว้ใหม่เมื่อเริ่มทำงาน แต่ละอย่างสามารถคืนพรีฟิกซ์เดิมได้หลังจากการเปลี่ยนแปลงของคุณดูเหมือนเสร็จสิ้น
ชื่อก็เดินทางเช่นกัน ถ้าเส้นทางตัวเลขทำงานแต่ชื่อโฮสต์ล้มเหลว บันทึก DNS ภายในหรือการกำหนดค่าบริการยังชี้ไปที่ที่อยู่เดิมของอุโมงค์ แก้ไขการอ้างอิงแทนการขยายช่วงของเพียร์ทุกช่วง ซึ่งจะกลบปัญหาจริงและขยาย ACL ต้นทางไปพร้อมกัน
เปิดเส้นทางกู้คืนไว้หนึ่งทางระหว่างทำงาน: วิธีที่สองในการเข้าสู่โฮสต์ คอนโซลอนุกรม หรือการย้อนกลับตามกำหนดเวลาของไฟล์การกำหนดค่า การเปลี่ยนอุโมงค์ที่ล็อกคุณออกจากเครื่องที่คุณกำลังเปลี่ยนคือวิธีที่งานนี้กลายเป็นทั้งคืนที่พบบ่อยที่สุด
การเลือกระหว่างสองวิธี และการตรวจสอบการสลับ
เลือก A เมื่อคุณเป็นเจ้าของทุกเพียร์ จำนวนน้อย และการหยุดชะงักสั้นๆ เป็นที่ยอมรับ เลือก B เมื่อเพียร์เป็นมือที่อยู่ไกลที่คุณไม่ได้ควบคุม เมื่อลิงก์ระหว่างไซต์ต้องคงอยู่ หรือเมื่อคุณไม่สามารถรับประกันได้ว่าทุกสำเนาจะได้รับการอัปเดตในการผ่านครั้งเดียว ในกรณีนั้นให้เพิ่มพรีฟิกซ์ใหม่ให้ทั้งสองอินเทอร์เฟซ ย้ายเพียร์ทีละตัว ดูทราฟฟิกบนตัวใหม่ และหลังจากนั้นจึงลบอินเทอร์เฟซเดิมและเส้นทางของมัน
ในทั้งสองตัวเลือก การเปลี่ยนแปลงเสร็จสิ้นเมื่อการตรวจสอบสี่ข้อผ่าน: แฮนด์เชกยังใหม่ การค้นหาเส้นทางสำหรับปลายทางบนพรีฟิกซ์ใหม่ระบุชื่ออุโมงค์ เพย์โหลดสองสามร้อยไบต์ผ่านได้ทั้งสองทิศทาง และเป็นเช่นเดียวกันหลังจากรีสตาร์ตโฮสต์หรือผู้จัดการ สำหรับ คู่มือ wg(8) เป็นเอกสารอ้างอิงว่า AllowedIPs หมายถึงอะไรในแต่ละทิศทาง และคุ้มค่าที่จะอ่านซ้ำก่อนที่คุณจะขยายช่วงเพื่อให้อาการหายไป
- แฮนด์เชกใหม่และไม่มีข้อมูล: ดู AllowedIPs ที่ฝั่งรับก่อนแตะกุญแจ
- การค้นหาเส้นทางชี้ไปที่อินเทอร์เฟซผิด: ผู้จัดการหรือคอนเทนเนอร์เป็นเจ้าของเส้นทาง ไม่ใช่ไฟล์ของคุณ
- ที่อยู่ตัวเลขใช้ได้แต่ชื่อโฮสต์พัง: การอ้างอิงเก่า ไม่ใช่ลูปการกำหนดเส้นทาง
- การเปลี่ยนแปลงจะเสร็จสมบูรณ์เมื่อหลังรีสตาร์ตยังใช้พรีฟิกซ์ใหม่อยู่