กลุ่มเพื่อน WireGuard บนฮับ: ความเป็นเจ้าของต้นทางและนโยบาย
แยกกลุ่มเพื่อนออกจากกันด้วยที่อยู่ต้นทางแคบ ๆ ต่อเพื่อนหนึ่งรายและนโยบายการส่งต่อ โดยไม่ต้องมีอินเทอร์เฟซอุโมงค์แยกสำหรับแต่ละกลุ่ม
ฮับที่รัน WireGuard สามารถแยกกลุ่มเพื่อนออกจากกันได้โดยไม่ต้องมีอินเทอร์เฟซหรือตารางเส้นทางแยกสำหรับแต่ละกลุ่ม กลไกสองอย่างทำงานนี้ และการสับสนระหว่างสองสิ่งนี้คือสาเหตุปกติที่นโยบายดูถูกต้องแต่ไม่ทำอะไรเลย ชั้นหนึ่งตัดสินว่าใครสามารถอ้างที่อยู่ต้นทางได้ อีกชั้นหนึ่งตัดสินว่าแพ็กเก็ตนั้นได้รับอนุญาตให้ไปที่ใด
สองงานที่แยกจากกัน
ชั้นอุโมงค์ตอบคำถามแคบ ๆ ว่า กุญแจของเพื่อนรายนี้อนุญาตที่อยู่ต้นทางภายในนี้หรือไม่ ชั้นส่งต่อตอบคำถามที่กว้างกว่า ว่าแพ็กเก็ตนี้สามารถออกไปยังปลายทางนั้นได้หรือไม่ ไม่มีชั้นใดตอบคำถามของอีกชั้น และไม่มีชั้นใดเพียงลำพังเป็นนโยบายการเข้าถึงที่สมบูรณ์
การแยกนี้คือเหตุผลที่เพื่อนรายหนึ่งอาจได้รับการพิสูจน์ตัวตน มีที่อยู่ถูกต้อง แต่ยังไม่สามารถไปถึงโฮสต์ที่ไม่ควรไปถึงได้ มันยังอธิบายสิ่งที่ตรงกันข้ามด้วย กฎไฟร์วอลล์ที่อนุญาตทุกอย่างไม่ได้พิสูจน์อะไรเกี่ยวกับว่าใครสามารถอ้างที่อยู่ใดได้
ออกแบบทั้งสองชั้นไปด้วยกัน แล้วทดสอบทั้งสอง การตั้งค่าที่ถูกต้องในชั้นหนึ่งและยังไม่ได้ทดสอบในอีกชั้นหนึ่งจะล้มเหลวแบบเปิดหรือแบบปิดขึ้นอยู่กับค่าเริ่มต้น
ให้เพื่อนแต่ละรายมีเพียงที่อยู่ของตัวเอง
เพื่อนที่มีหลายโฮสต์ทำให้คุณอยากให้ช่วงทั้งกลุ่มฝั่งเซิร์ฟเวอร์ การอนุญาตนั้นคือการอ้างที่อยู่ต้นทาง ลูกค้าที่ถูกบุกรุกหรือตั้งค่าผิดจึงสามารถนำเสนอที่อยู่ใดก็ได้ในช่วงนั้นและอุโมงค์จะยอมรับ กำหนด /32 ต่อเพื่อนหนึ่งรายสำหรับที่อยู่ภายในของตัวเอง ตั้งช่วงของกลุ่มเฉพาะบนลูกค้าเท่านั้น ซึ่งช่วงนั้นอธิบาย ปลายทางที่ลูกค้ารายนั้นสามารถไปถึง ไม่ใช่ต้นทางที่ลูกค้ารายนั้นสามารถใช้
จากนั้นไฟร์วอลล์จะจับคู่กับต้นทางที่ไว้ใจได้ กฎที่เขียนสำหรับช่วงของกลุ่มยังคงเป็นการจัดกลุ่มที่มีประโยชน์ และจะมีความหมายก็ต่อเมื่อไม่มีเพื่อนรายใดรายหนึ่งสามารถอ้างที่อยู่ที่เป็นของสมาชิกอีกรายได้
เขียนนโยบายการส่งต่อที่แยกกลุ่มออกจากกัน
ทราฟฟิกที่น่าสนใจในที่นี้เข้าออกผ่านอินเทอร์เฟซอุโมงค์เดียวกัน จึงผ่านเส้นทางการส่งต่อไม่ใช่เส้นทางขาเข้าของโฮสต์ กฎเหล่านี้อยู่ในเชนส่งต่อที่มีอยู่ของตัวจัดการไฟร์วอลล์ที่ถือครองโฮสต์ และมันเป็นเพียงชิ้นส่วนไม่ใช่ชุดกฎที่สมบูรณ์
iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept iifname "wg0" oifname "wg0" drop
กฎสองข้อแรกอนุญาตทราฟฟิกภายในแต่ละกลุ่ม ส่วนข้อสุดท้ายบล็อกทุกอย่างอื่นที่ผ่านอินเทอร์เฟซนั้น และนั่นคือสิ่งที่สร้างการแยกจากกันระหว่างกลุ่ม เพิ่มกฎที่ชัดเจนสำหรับตระกูลที่อยู่อีกตระกูลหากต้องการ เพราะ drop ที่เขียนสำหรับ IPv4 ไม่ได้อนุญาตหรืออธิบายพฤติกรรมของ IPv6
ลำดับเป็นตัวตัดสินว่านโยบายมีผลหรือไม่
ลำดับของกฎสำคัญกว่าตัวชิ้นส่วนเอง กฎทั่วไปที่ยอมรับการเชื่อมต่อที่สร้างไว้แล้วและวางไว้ก่อนรายการเหล่านี้จะปล่อยให้โฟลว์ข้ามกลุ่มเก่ายังดำเนินต่อไป การแยกจึงใช้กับเฉพาะการเชื่อมต่อใหม่ ตัดสินใจว่าต้องการผลลัพธ์ใดในสองอย่างนี้ก่อนโหลดใหม่
คำตัดสินว่ายอมรับก็ไม่ใช่ที่สุดท้ายเสมอไปข้ามเชนบนฮุกเดียวกัน หากเชนฐานอื่นทำงานภายหลัง นโยบายที่มีผลจริงคือการรวมกัน จึงตรวจดูตัวนับไม่ใช่ไฟล์ที่คุณแก้ไข ตัวนับเป็นหลักฐานที่ถูกที่สุดเท่าที่มี กฎที่ไม่มีจำนวนแพ็กเก็ตไม่ได้จับคู่ และกฎที่จับคู่ในขณะที่เชนภายหลังยอมรับบอกคุณว่า drop อยู่ผิดที่
ทดสอบเมทริกซ์ ไม่ใช่จำนวนไฟล์
สร้างเมทริกซ์เล็ก ๆ ของผลลัพธ์ที่คาดหวังและตรวจทุกช่อง กลุ่ม A ไปกลุ่ม A ควรได้ผล กลุ่ม B ไปกลุ่ม B ควรได้ผล และ A ไป B ไม่ควร ทั้งสองทิศทางและทั้งสองตระกูลที่อยู่หากคุณรองรับ
nft list ruleset wg show wg0 allowed-ips ping -c 2 10.66.10.5 conntrack -L -s 10.66.20.7 2>/dev/null | head
สองคำสั่งแรกแสดงสิ่งที่ตั้งค่าไว้ ping จากสมาชิกของกลุ่มที่ผิดแสดงว่าเกิดอะไรขึ้นจริง รายการ conntrack แสดงว่าโฟลว์เก่ายังได้รับการยอมรับหรือไม่ และนี่คือวิธีที่การเปลี่ยนแปลงการแยกจากกันล้มเหลวอย่างเงียบ ๆ ที่จะมีผล
บริการโฮสต์บนฮับและการเข้าถึง LAN ที่อยู่เบื้องหลังเป็นเส้นทางแยกที่มีนโยบายแยก บันทึกว่าเมทริกซ์ครอบคลุมสิ่งใดบ้าง เพราะการทดสอบที่ตรวจเฉพาะทราฟฟิกระหว่างเพื่อนไม่บอกอะไรเกี่ยวกับทั้งสองอย่างนั้น