ให้ผู้ใช้ VPN เข้าถึงบริการเดียว ไม่ใช่ทั้งซับเน็ต

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

เขียนความต้องการเป็นบริการ ไม่ใช่ซับเน็ต

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

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

ถ้ารายการการพึ่งพาเกินสามรายการ แอปนั้นน่าจะต้องมีการพูดคุยเรื่องการออกแบบของตัวเอง

กำหนดเส้นทางให้แคบ แต่บังคับใช้ที่อื่น

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

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

จัดทำเอกสารจุดบังคับใช้อย่างชัดเจน ไม่อย่างนั้นการเปลี่ยนแปลงครั้งต่อไปจะย้ายมันโดยไม่ตั้งใจ

ตรวจสอบต้นทางที่บริการเห็นจริง

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

เลือกการแปลอย่างตั้งใจ มันทำให้การกำหนดเส้นทางง่ายขึ้นและทำลายตัวตนของต้นทาง ซึ่งสำคัญต่อการตรวจสอบและกฎต่อผู้ใช้

จดว่าคุณเลือกอย่างใดจากสองอย่าง ไว้ข้างกฎที่ขึ้นอยู่กับมัน

การอนุญาตของแอปไม่ใช่ทางเลือก

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

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

เก็บกฎเครือข่ายและบทบาทของแอปไว้ในระบบแยกกัน และปลดระวางแยกกัน

พิสูจน์ทั้งเส้นทางที่อนุญาตและที่ถูกปฏิเสธ

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

อย่าปิดใช้งานตัวกรองการส่งต่อเพื่อให้การทดสอบการยอมรับผ่าน เพราะนั่นเปลี่ยนสิ่งที่กำลังถูกทดสอบ

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