สองกลุ่มไคลเอนต์ หนึ่งเซิร์ฟเวอร์: จะบังคับใช้นโยบายที่ใด
ซับเน็ตเป็นเพียงป้ายกำกับกลุ่ม ไม่ได้แยกกลุ่มออกจากกัน ตัดสินใจว่าเส้นทางส่งต่อใดเป็นเจ้าของกฎ แล้วเขียนเมทริกซ์ที่การนำไปใช้ต้องบังคับ
การวางสองกลุ่มไคลเอนต์บนซับเน็ตที่ต่างกันดูเหมือนการแยกกัน แต่ไม่ใช่ ที่อยู่บอกว่าแพ็กเก็ตดูเหมือนมาจากไหน ขณะที่สิทธิ์คือการตัดสินใจของสิ่งที่ส่งต่อมัน คำถามนี้ตอบด้วยการกำหนดค่าไม่ใช่มาสก์ ดังนั้นจงตัดสินใจว่าองค์ประกอบใดส่งต่อทราฟฟิกระหว่างเพียร์ก่อนเขียนกฎใด ๆ
ซับเน็ตคือป้ายกำกับ ไม่ใช่กฎ
การจัดสรรพูลหนึ่งพูลต่อกลุ่มให้ที่อยู่ที่อ่านง่ายและไม่มีอะไรอื่น ไคลเอนต์ที่ยอมรับเส้นทางเพิ่มเติมได้รับความสามารถในการเข้าถึง และความสามารถในการเข้าถึงไม่ใช่การอนุญาต สิทธิ์ในการสื่อสารอยู่ในคำตัดสินใจส่งต่อ ซึ่งอาจอยู่ในดีมอนหรือในเคอร์เนล ขึ้นอยู่กับการกำหนดค่าของเซิร์ฟเวอร์
ความเป็นเจ้าของที่อยู่คือสิ่งที่ทำให้คำนำหน้าใช้เป็นตัวเลือกกลุ่มได้ เอกลักษณ์ที่ผ่านการตรวจสอบแต่ละรายต้องแมปกับที่อยู่หรือช่วงที่คาดเดาได้ และการแมปนั้นล้มเหลวทันทีที่อุปกรณ์หลายเครื่องใช้ข้อมูลรับรองชุดเดียวและการจัดสรรรายการเดียว แก้ปัญหาเอกลักษณ์และความพร้อมกันก่อนพึ่งพาคำนำหน้าต้นทาง เพราะนโยบายที่เดาว่าเครื่องใดกำลังเรียกจะอนุญาตเครื่องที่ผิดในจังหวะที่แย่ที่สุด
เลือกเส้นทางที่ขนส่งทราฟฟิกระหว่างเพียร์
เมื่อดีมอนส่งต่อแพ็กเก็ตเพียร์ภายในโปรเซสของตัวเอง แพ็กเก็ตเหล่านั้นไม่เคยไปถึงฮุกการส่งต่อของโฮสต์ ดังนั้นกฎของเคอร์เนลจึงมองไม่เห็น ปิดการส่งต่อภายในนั้น แล้วเคอร์เนลจะกลายเป็นจุดส่งต่อ ซึ่งกฎการส่งต่อปกติมีผล
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain
ช่องข้อมูลที่ออฟโหลดและเซิร์ฟเวอร์ที่ผลิตภัณฑ์จัดการเผยแพร่แบบจำลองการบังคับใช้ของตัวเอง ดังนั้นจงยืนยันว่าคุณใช้แบบใดแทนการสมมติพฤติกรรมของชุมชน ความล้มเหลวที่ควรหลีกเลี่ยงคือกฎที่ดูถูกต้องในการทบทวนแต่ไม่เคยถูกเรียกใช้ตอนรัน
เขียนเมทริกซ์ก่อนเขียนกฎ
เมทริกซ์สั้นตรวจทานง่ายกว่าชุดกฎ และเป็นสัญญาที่การนำไปใช้ต้องทำให้ได้: เพียร์ในกลุ่มเดียวกันอนุญาต เพียร์ข้ามกลุ่มห้าม ทั้งสองกลุ่มอนุญาตไปยังบริการที่ใช้ร่วมกันหนึ่งบริการที่มีชื่อ อย่างอื่นทั้งหมดห้าม เขียนสี่บรรทัดนั้นก่อนเปิดตัวแก้ไขไฟร์วอลล์ ผู้ทบทวนที่ไม่ได้อ่านไวยากรณ์ของกฎยังตรวจเมทริกซ์ได้ จากนั้นการนำไปใช้เพียงต้องตรงกับบรรทัดเหล่านั้น
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
แยกประเภทปลายทางสามประเภทออกจากกันขณะเขียน บริการบนโฮสต์ VPN คืออินพุตภายในเครื่อง ไคลเอนต์อื่นคือการผ่านของเพียร์ และเครื่องที่อยู่หลังเกตเวย์คือเส้นทางส่งต่ออีกแบบ กฎที่ใจกว้างหนึ่งข้ออาจให้ทั้งสามอย่างโดยไม่ตั้งใจ และนั่นคือวิธีที่นโยบายกลุ่มกลายเป็นเครือข่ายแบนราบพร้อมขั้นตอนเพิ่มเติม เขียนประเภทไว้ข้างแต่ละแถวเพื่อให้เจตนาคงอยู่ในการแก้ไขครั้งถัดไป
วางกฎไว้ในที่ที่มันอยู่รอด
เพิ่มคำตัดสินใจในที่เดียวกับที่ดูแลไฟร์วอลล์ส่วนที่เหลือ ก่อนกฎที่อนุญาตใด ๆ ที่จะกลืนมัน ลำดับกฎเป็นส่วนหนึ่งของนโยบาย และกฎที่ถูกต้องซึ่งวางไว้หลังการอนุญาตแบบกว้างไม่ได้บังคับใช้สิ่งใดเลย บันทึกหมายเลขกฎก่อนและหลังการเปลี่ยนแปลง นโยบายที่มีอยู่ในตัวแก้ไขแต่ไม่มีในชุดกฎที่ทำงานอยู่คือแผน ไม่ใช่การควบคุม
ตัดสินใจว่าจะเกิดอะไรขึ้นกับโฟลว์ที่มีอยู่แล้วเมื่อนโยบายเปลี่ยน เพราะเซสชันที่เปิดก่อนการเปลี่ยนแปลงอาจดำเนินต่อไปได้ หากสมาชิกที่จากไปต้องเสียการเข้าถึงทันที ชุดกฎต้องมีวิธีสิ้นสุดสถานะนั้นแทนการรอให้การเชื่อมต่อปิดเอง
ทำให้กฎคงอยู่ผ่านกลไกที่เป็นเจ้าของไฟร์วอลล์ส่วนที่เหลือ และบันทึกเมทริกซ์ไว้ข้าง ๆ นโยบายที่ไม่มีการบันทึกจะถูกอนุมานใหม่จากความจำระหว่างเหตุการณ์ครั้งถัดไป โดยปกติโดยคนที่รีบ
พิสูจน์จากทั้งสองด้าน
ทดสอบการเข้าถึงภายในกลุ่มเดียวกัน ความล้มเหลวข้ามกลุ่ม และบริการที่ใช้ร่วมกันจากไคลเอนต์หนึ่งเครื่องในแต่ละกลุ่ม การทดสอบครั้งเดียวจากไคลเอนต์เดียวพิสูจน์เมทริกซ์ได้ครึ่งเดียว และครึ่งที่ละไว้มักเป็นครึ่งที่ผิด ทำทิศทางปฏิเสธซ้ำสองครั้ง เพราะเซสชันที่แคชไว้อาจซ่อนข้อผิดพลาดในการบังคับใช้ บันทึกว่าทดสอบคู่ใดเพื่อให้คนต่อไปไม่ทำซ้ำ
ทำการตรวจซ้ำบน IPv6 หากอุโมงค์ขนส่งมัน และคงการพิสูจน์ตัวตนของแอปพลิเคชันตามปกติ คำนำหน้าต้นทางไม่ใช่บัญชี ดังนั้นการผ่านนโยบายเครือข่ายไม่ได้หมายความว่าบริการควรเชื่อถือผู้เรียก