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

สร้างปัญหาซ้ำหนึ่งครั้งอย่างตั้งใจ

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

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

ใครเป็นเจ้าของอินเทอร์เฟซ

WireGuard เองไม่มี daemon และไม่มีไฟล์ตั้งค่า บางอย่างเหนือขึ้นไปเรียก wg ตอนบูต และบางอย่างนั้นคือแหล่งของความจริง ผู้สมัครตามปกติคือ [email protected] โปรไฟล์การเชื่อมต่อของ NetworkManager ยูนิตเครือข่ายเฉพาะดิสทริบิวชัน หรือแผงจัดการที่เขียนฐานข้อมูลของตัวเอง

ถามระบบ ไม่ใช่เอกสารของดิสทริบิวชันคุณ systemctl status wg-quick@wg0 และ nmcli connection show มักจะตัดสินเรื่องนี้ได้ด้วยคำสั่งเดียวต่อตัว ถ้าทั้งสองอ้างสิทธิ์ในอินเทอร์เฟซ คุณเจอบั๊กแล้วก่อนแก้ไขอะไร: เจ้าของสองรายเขียนทับอุปกรณ์เดียวกันทุกครั้งที่เริ่ม และตัวที่รันสุดท้ายชนะ

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

สถานะขณะทำงานกับสถานะตอนเริ่มไม่ใช่ไฟล์เดียวกัน

wg set จัดการอุปกรณ์ที่กำลังทำงานผ่าน netlink มันไม่เขียน /etc/wireguard/wg0.conf โปรไฟล์ NetworkManager หรือฐานข้อมูลของแผง wg show ที่สำเร็จหลังจากนั้นพิสูจน์ว่าเคอร์เนลรับ peer แล้ว ไม่ใช่ว่ามีอะไรจะคืนมันกลับมา

มีกับดักที่สองในทิศตรงข้าม ตัวเลือก SaveConfig ของ wg-quick เขียนสถานะอินเทอร์เฟซปัจจุบันกลับลงไฟล์ตั้งค่าเมื่ออินเทอร์เฟซถูกปลดลง เมื่อเปิดใช้ การแก้ไฟล์ขณะอินเทอร์เฟซทำงานอยู่อาจถูกเขียนทับด้วยการปิดที่ตามมา และคุณจะสาบานว่าเคยมีบรรทัดนั้น ถ้า peer กลับมาซ้ำๆ ให้อ่านไฟล์หลังหยุด ไม่ใช่ก่อน

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

ทำให้การแก้ไขลงเอยทั้งสองที่

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

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

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

พิสูจน์ว่ามันรอดจากเหตุการณ์ในวงจรชีวิต

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

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

บทความที่เกี่ยวข้อง