การส่งผ่านแบบเข้ารหัสไม่ได้ให้สิทธิ์เข้าถึงผู้ขนส่ง

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

ทำตามขั้นตอนด้านล่างตามลำดับ และถือว่าความล้มเหลวในขั้นตอนใดก็ตามเป็นการเปลี่ยนแปลงการออกแบบ ไม่ใช่การปรับแต่งการกำหนดค่า

กำหนดทั้งสองขอบเขตก่อนที่จะแตะการกำหนดค่า

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

เขียนทั้งสองเป็นรายการที่อยู่ พอร์ต และทิศทาง หากเขียนรายการไม่ได้ แสดงว่าขอบเขตยังไม่ได้กำหนด

ขั้นตอนที่ 1: จำกัดอุโมงค์ชั้นนอก

บนอินเทอร์เฟซที่หันไปทางผู้ขนส่ง อนุญาตเฉพาะสิ่งที่อุโมงค์ต้องการ: IKE บน UDP 500 และ 4500 ระหว่างที่อยู่เกตเวย์สองที่ และ ESP ในจุดที่ไม่ใช้การทะลุผ่าน NAT ปฏิเสธทุกสิ่งอื่นที่มาถึงอินเทอร์เฟซนั้น รวมถึงโปรโตคอลการจัดการ ข้อกำหนด ESP ครอบคลุมบริการป้องกัน แต่ไม่ได้กล่าวถึงว่าบริการใดของผู้ขนส่งเองที่เกตเวย์ใช้ได้ เขียนสิ่งนี้เป็นรายการอนุญาตที่ชัดเจน เพื่อให้บริการของผู้ขนส่งที่เผยแพร่ใหม่ไม่สามารถเข้าถึงได้โดยค่าเริ่มต้น

นี่คือชุดกฎที่ทำให้การออกแบบเป็นการออกแบบการส่งผ่าน ไม่ใช่ข้อตกลงเพียริง

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

ขั้นตอนที่ 2: ตัดสินใจว่าเกตเวย์ปลายทางส่งมอบอะไร

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

แผนภาพที่หยุดเมื่อถอดรหัสสำเร็จได้ข้ามการตัดสินใจที่สำคัญที่สุดไป

ขั้นตอนที่ 3: รักษาความเป็นเจ้าของในแต่ละชั้น

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

กำหนดเจ้าของให้แต่ละชั้น ชั้นที่ไม่มีเจ้าของคือชั้นที่คลาดเคลื่อน

ขั้นตอนที่ 4: ตรวจสอบ แล้วจึงมอบให้หน่วยงาน

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

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