ทำไม peer ของ WireGuard ที่ลบไปแล้วจึงกลับมาหลังรีสตาร์ต
สถานะสองอย่างเก็บรายการ peer ไว้: อินเทอร์เฟซที่กำลังทำงานและสิ่งที่เขียนมันตอนบูต ลบออกจากทั้งสอง และตรวจ SaveConfig ก่อนแก้ไขอะไร
ตัวตนหายไปจากอินเทอร์เฟซที่กำลังทำงานและดูเหมือนการเปลี่ยนแปลงเสร็จแล้ว หลังจากบริการรีสตาร์ต มันกลับมา ซึ่งอ่านได้ราวกับว่า WireGuard ไม่สนใจคำสั่ง สิ่งที่เกิดขึ้นจริงนั้นง่ายกว่า: คอนฟิกูเรชันตอนบูตยังมี peer นั้นอยู่
มีสองสถานะที่ถือรายการนี้ไว้ การเพิกถอนจะเป็นจริงก็ต่อเมื่อทั้งสองสูญเสียมันไป
wg set เปลี่ยนอะไรจริง ๆ
คำสั่ง wg set wg0 peer <public-key> remove แก้ไขอินเทอร์เฟซที่กำลังทำงานอยู่ในเคอร์เนล มันไม่เขียนอะไรลงดิสก์ ไฟล์คอนฟิกูเรชัน โปรไฟล์ของ NetworkManager หรือสถานะที่บันทึกไว้ของเราเตอร์ยังคงไม่ถูกแตะต้อง นั่นคือการออกแบบ ไม่ใช่บั๊ก
การแยกจากกันนั้นเป็นเจตนา เพราะเครื่องมือไม่รู้เลยว่าใครเป็นเจ้าของอินเทอร์เฟซ คำสั่งตอนรันไทม์ต้องปลอดภัยต่ออินเทอร์เฟซที่ถูกจัดการโดยสิ่งอื่น มันเดาไม่ได้ว่าสำเนาถาวรอยู่ที่ไหน ผลลัพธ์พูดง่าย ๆ คือ การลบตอนรันไทม์เป็นเรื่องชั่วคราวโดยโครงสร้างของมันเอง
ดังนั้น peer จึงกลับมาในการรีสตาร์ตครั้งถัดไป และกลับมาพร้อมคำนำหน้าที่อนุญาตเดิมของมัน ทุกอย่างที่ถูกเราเตอร์ผ่านมันก็ถูกสร้างใหม่ด้วย ตัวตนที่คิดว่าเพิกถอนแล้วจึงสามารถไปถึงปลายทางเดิมได้หลังการโหลดใหม่ ไม่มีอะไรในเอาต์พุตตอนรันไทม์ที่เตือนใครเลย
หาตัวผู้เขียนก่อนแก้ไฟล์
อินเทอร์เฟซมีเจ้าของ อาจเป็น wg-quick ที่อ่านไฟล์ NetworkManager ที่ใช้โปรไฟล์ คอนฟิกูเรชันอินเทอร์เฟซของเราเตอร์เอง หรือจุดเข้าใช้งานของคอนเทนเนอร์ที่สร้างอินเทอร์เฟซใหม่ตอนเริ่ม การแก้ไฟล์ที่เจ้าของไม่เคยอ่านไม่ก่อให้เกิดการเปลี่ยนแปลงถาวรใด ๆ เลย
เริ่มจากอินเทอร์เฟซที่กำลังทำงานและระบุกุญแจสาธารณะ เพราะชื่อและที่อยู่เป็นตัวระบุที่อ่อนกว่ากุญแจเอง จากนั้นเปรียบเทียบรายการนั้นกับคอนฟิกูเรชันที่บันทึกไว้ซึ่งเจ้าของอ่านจริง
wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard
อินเทอร์เฟซที่ยังทำงานซึ่งรายการ peer กับเนื้อหาไฟล์ไม่ตรงกันคือการวินิจฉัยทั้งหมด คอนฟิกูเรชันที่บันทึกไว้ชนะตอนบูต และสถานะตอนรันไทม์แพ้ เปรียบเทียบทั้งสองก่อนจะเปลี่ยนอันใดอันหนึ่ง
กับดัก SaveConfig
wg-quick เพิ่มรอยพับที่ดักคนที่แก้ไฟล์ด้วยมือ เมื่อเปิด SaveConfig พฤติกรรมการปิดที่เขียนไว้ในเอกสารจะเขียนสถานะตอนรันไทม์ปัจจุบันทับไฟล์คอนฟิกูเรชัน
นั่นกลับทิศทางการคงอยู่ตามปกติ คุณลบ peer ออกจากไฟล์ แล้วบริการก็หยุด สถานะที่กำลังทำงานถูกเขียนทับการแก้ไขของคุณและคืน peer ที่คุณเพิ่งลบไป
ลำดับจึงสำคัญ: แก้ไฟล์ตอนอินเทอร์เฟซปิดอยู่ หรือปิด SaveConfig ก่อนแก้ แล้วค่อยเปิดอินเทอร์เฟซขึ้นมาใหม่และยืนยันว่าโหลดอะไรเข้าไป การแก้ด้วยมือตอนอินเทอร์เฟซเปิดอยู่คือการแข่งกับการเขียนตอนปิด
เปลี่ยนทั้งสองสถานะ แล้วโหลดใหม่
ตอนรันไทม์ ลบ peer ตามกุญแจ ในคอนฟิกูเรชันที่บันทึกไว้ ลบบล็อกเดียวกันผ่านการดำเนินการที่เจ้าของรองรับ แทนที่จะแก้ไขรอบ ๆ มัน
จากนั้นทบทวนว่า peer แบกอะไรไว้ เครือข่ายที่ถูกเราเตอร์ซึ่งเคยเป็นของตัวตนที่เพิกถอนแล้วควรถูกกำหนดใหม่โดยเจตนาหรือลบออก ไม่ใช่ถูกสืบทอดอย่างเงียบ ๆ โดย peer ที่จะถูกแก้ไขถัดไป
เก็บเส้นทางกู้คืนไว้หากเกตเวย์แบกการเข้าถึงของผู้ดูแลระบบของคุณด้วย การรีสตาร์ตที่ลบ peer ผิดตัวคือการหยุดชะงักที่คุณก่อเอง เช่นเดียวกับการรีสตาร์ตที่ลบเส้นทางผิด
การทดสอบที่ผ่านมีหน้าตาอย่างไร
โหลดใหม่หรือรีสตาร์ตบริการ แล้วอ่านรายการ peer อีกครั้ง กุญแจเก่าต้องหายไป และ peer ที่คุณตั้งใจเก็บไว้ต้องยังอยู่และทำงานได้
wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers
ที่ที่สถานการณ์เอื้ออำนวย ยืนยันว่าตัวตนเดิมเข้าถึงทรัพยากรเดิมไม่ได้แล้ว รายการอินเทอร์เฟซที่เรียบร้อยก่อนรีสตาร์ตคือครึ่งหนึ่งของการทดสอบ อีกครึ่งคือสิ่งที่ตัวตนยังทำได้หลังจากนั้น
หากตัวจัดการใดยังคืน peer อยู่ตลอด ให้หยุดทำการลบระดับต่ำซ้ำ ๆ แก้ทะเบียนที่ตัวผู้เขียนนั้นอ่าน เพราะจนถึงตอนนั้นทุกการรีสตาร์ตคือคำเชิญอีกครั้งให้ตัวตนปรากฏขึ้นมาใหม่