คำนำหน้าโฮสต์ของ WireGuard: ทำไมที่อยู่หนึ่งจึงใช้ได้และที่เหลือไม่

อุโมงค์เปิดอยู่ handshake เกิดขึ้นทุกสองนาที และมีเพียงที่อยู่เดียวฝั่งตรงข้ามที่ตอบกลับ ping ไปยังที่อยู่ tunnel ของ peer ทำงาน แต่ไม่มีอะไรอยู่ข้างหลังทำงาน คนหนึ่งอ่านการตั้งค่าอินเทอร์เฟซ เห็นคำนำหน้าโฮสต์ แล้วสรุปว่า mask ผิด การขยายเป็น /24 แก้ ping ได้ชั่วคราวแล้วก็ทำให้อย่างอื่นพัง คำนำหน้าไม่เคยเป็นสาเหตุ และเส้นทางที่หายไปก็ไม่ใช่เส้นทางที่ mask ควบคุม

คำนำหน้าอินเทอร์เฟซสร้างอะไรจริง ๆ

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

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs คือสองกฎภายใต้ชื่อเดียว

รายการที่อนุญาตต่อ peer ของ WireGuard ทำงานสองอย่างพร้อมกัน และไวยากรณ์การตั้งค่าทำให้ดูเหมือนอย่างเดียว ฝั่งขาเข้า มันอนุญาตว่าที่อยู่ต้นทางใดที่ peer จะนำเสนอได้ ฝั่งขาออก มันเลือกว่าจะส่งแพ็กเก็ตไปยัง peer ใด โดยหาการจับคู่ที่เฉพาะเจาะจงที่สุด

งานทั้งสองไม่ใช่การกำหนดเส้นทาง เคอร์เนลยังต้องตัดสินว่าแพ็กเก็ตเป็นของอินเทอร์เฟซอุโมงค์ก่อนที่ WireGuard จะมองมัน และการตัดสินนั้นมาจากตารางเส้นทาง รายการ peer ที่มีรายการอนุญาตกว้าง ไม่ได้ติดตั้งเส้นทางด้วยตัวเอง

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

เส้นทางมาจากไหน

หากใช้ wg-quick เส้นทางจะถูกสร้างให้จากรายการที่อนุญาตของแต่ละ peer เว้นแต่จะตั้ง Table = off และรับการควบคุมเอง นั่นคือพฤติกรรมที่เครื่องมือบันทึกไว้ และเป็นเหตุผลที่การตั้งค่าที่ไม่มีคำสั่งเส้นทางชัดเจนยังทำงานได้

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

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

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

คำนำหน้าที่กว้างขึ้นไม่ได้เพิ่มรายการ peer

การแก้ที่ล่อใจคือเปลี่ยนที่อยู่เป็น /24 เพื่อให้เส้นทางที่เชื่อมต่อครอบคลุม LAN ของเซิร์ฟเวอร์ ดูเหมือนได้ผล และเหตุผลที่ดูเหมือนได้ผลคือเส้นทางที่เชื่อมต่อตรงกันแล้ว ไม่ใช่เพราะ WireGuard เรียนรู้อะไรใหม่

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

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

ยืนยันทั้งสองทิศทางก่อนเปลี่ยนแปลงอะไร

จัดการสองปลายแยกกันและเขียนว่าแต่ละฝั่งพูดอะไร บนไคลเอนต์คือเส้นทางและรายการ peer บนเซิร์ฟเวอร์คือภาพสะท้อนบวกเส้นทางขากลับของมันเอง:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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