WireGuard: เส้นทางครึ่งเดียวสองเส้นกับ 0.0.0.0/0 ใน wg-quick

คำนำหน้า /1 สองรายการครอบคลุมที่อยู่ IPv4 ชุดเดียวกับ /0 หนึ่งรายการ และความเท่าเทียมนั้นใช้ได้เฉพาะภายในรายการคำนำหน้าที่ได้รับอนุญาตของเพียร์เท่านั้น มันหยุดใช้ได้ในขณะที่เครื่องมือตั้งค่าตัดสินใจว่าจะกำหนดเส้นทางอย่างไร เพราะ Linux wg-quick จัดการคำนำหน้าเริ่มต้นเป็นกรณีพิเศษไม่ใช่การคำนวณ สาขาพิเศษจะติดตั้งตารางเฉพาะ กฎนโยบายสองข้อ เครื่องหมายซ็อกเก็ต และการตั้งค่าเส้นทางย้อนกลับที่เส้นทางครึ่งคู่ไม่เคยได้รับ ดังนั้นเมื่อพร็อกซีหรือเบราว์เซอร์หยุดทำงานหลังการแก้ไข คำนำหน้าจึงเป็นส่วนที่น่าสนใจน้อยที่สุดของการเปลี่ยนแปลง

รายการคำนำหน้าไม่ใช่การกำหนดค่าทั้งหมด

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

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

สาขาเริ่มต้นเพิ่มอะไรเกินกว่าเส้นทางหนึ่งเส้น

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

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

จุดที่การจัดวางสองแบบแยกจากกัน

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

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

อ่านกฎและเครื่องหมายก่อนแก้ไข

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

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

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

ซ้อมการสูญเสียอุโมงค์ก่อนปล่อยใช้งาน

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

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

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