รวมศูนย์การเข้าถึง VPN ของพาร์ตเนอร์โดยไม่ต้องรวมพาร์ตเนอร์เข้าด้วยกัน
VPN ของพาร์ตเนอร์บนเกตเวย์ที่ใช้ร่วมกันยุติความขัดแย้งของแล็ปท็อป แต่สร้างบริการที่ใช้ร่วมกัน จัดเก็บการอนุญาต การกำหนดเส้นทาง และตัวตนของแต่ละพาร์ตเนอร์แยกกัน
ข้อเสนอนี้สมเหตุสมผล: อุโมงค์พาร์ตเนอร์ห้าอุโมงค์ที่กระจายอยู่บนแล็ปท็อปกว่าสิบเครื่อง ชุดเวอร์ชันไคลเอนต์ห้าชุด สคริปต์ช่วยเหลือห้าชุด และวิศวกรหนึ่งคนที่รู้ว่าทั้งหมดประกอบกันอย่างไร การย้ายไปยังชั้นการเข้าถึงที่ควบคุมได้ช่วยแก้ปัญหาจุดปลายที่กระจัดกระจาย ในขณะเดียวกันก็สร้างวัตถุใหม่ในสถาปัตยกรรมของคุณ — บริการการเข้าถึงที่ใช้ร่วมกันซึ่งตอนนี้ต้องมีแบบจำลองการอนุญาตของตัวเอง และความล้มเหลวที่ทุกคนประเมินต่ำเกินไปคืออุปกรณ์ศูนย์กลางที่เปิดอุโมงค์ทั้งหมดไว้อย่างเงียบ ๆ กลายเป็นเครือข่ายส่งผ่านระหว่างองค์กรที่ไม่เคยตกลงจะเป็นเพื่อนบ้านกัน ความเสี่ยงนั้นคือการเลือกออกแบบ ไม่ใช่สิ่งที่ฮาร์ดแวร์ทำเอง งานด้านล่างนี้คือวิธีที่ฉันรักษาความสะดวกไว้โดยไม่ยอมรับผลข้างเคียงที่ไม่ได้ตั้งใจ
เริ่มจากสัญญาที่แต่ละพาร์ตเนอร์ลงนามไว้แล้ว
ก่อนการกำหนดค่าใด ๆ ให้ยืนยันว่าพาร์ตเนอร์อนุญาตให้ใช้เกตเวย์หรือการเชื่อมต่อไซต์ร่วมกันหรือไม่ บัญชีการเข้าถึงระยะไกลส่วนบุคคล ข้อกำหนดสภาวะอุปกรณ์ หรือโฟลว์ MFA แบบโต้ตอบอาจไม่สามารถถ่ายโอนไปยังอุโมงค์ร่วมที่ไม่มีผู้ดูแลได้ และการรวมพนักงานไว้หลังตัวตนไคลเอนต์ที่คัดลอกมาเพียงตัวเดียวคือทางลัดประเภทที่อยู่ได้จนกว่าพาร์ตเนอร์จะตรวจสอบบันทึกของตน สำหรับการเชื่อมต่อที่ได้รับอนุญาตแต่ละรายการ ให้บันทึกช่วงปลายทาง โดเมน DNS ส่วนตัว แหล่งภายในที่ได้รับอนุญาต ผู้รับผิดชอบการพิสูจน์ตัวตน และสิ่งที่ควรเกิดขึ้นเมื่ออุโมงค์ล้มเหลว ขอให้พาร์ตเนอร์ยืนยันการเชื่อมต่อร่วมเป็นลายลักษณ์อักษร รวมถึงช่วงต้นทางที่พวกเขาจะยอมรับ การอนุมัติด้วยวาจามักเปลี่ยนความหมายในสัปดาห์ที่ทีมรักษาความปลอดภัยของพวกเขาสับเปลี่ยน
บันทึกนั้นคือสิ่งที่ส่งมอบ ถ้าคุณเขียนมันให้พาร์ตเนอร์รายหนึ่งไม่ได้ พาร์ตเนอร์รายนั้นยังไม่พร้อมที่จะรวมศูนย์
กำหนดเส้นทางตามบริบท ไม่ใช่ตามปลายทางเพียงอย่างเดียว
ในที่สุดพาร์ตเนอร์สองรายจะใช้ช่วงส่วนตัวเดียวกัน เพราะทุกองค์กรเลือกจากพื้นที่ RFC 1918 เดียวกัน ตารางกำหนดเส้นทางธรรมดาตารางเดียวไม่สามารถเลือกพาร์ตเนอร์ที่ถูกต้องจากที่อยู่ปลายทางเพียงอย่างเดียวได้ ดังนั้นช่วงที่ทับซ้อนกันจึงต้องมีบริบทการกำหนดเส้นทางแยกกันหรือการออกแบบอื่นที่ตกลงกันไว้ แบบจำลองโดเมนส่งต่อใน RFC 4364 อธิบายว่าทำไมการแยกนี้จึงสำคัญ และการติดตั้งใช้งานไม่จำเป็นต้องรัน MPLS เพื่อต้องการคุณสมบัติเดียวกันจากแพลตฟอร์มเกตเวย์ของตน
ถามแพลตฟอร์มด้วยคำถามตรง ๆ: พาร์ตเนอร์สองรายใช้คำนำหน้าปลายทางเดียวกันร่วมกันแล้วยังแยกแยะได้ด้วยบริบทพนักงานที่เซสชันมาจากหรือไม่? ถ้าคำตอบคือไม่ ข้อจำกัดนั้นกำหนดรูปแบบการออกแบบมากกว่ารายการคุณสมบัติของผู้ขายรายใด
ที่ใดคำตอบคือใช่ บริบทการกำหนดเส้นทางก็กลายเป็นสิ่งที่คุณจัดทำเอกสารและทดสอบ เพราะมันมองไม่เห็นใน traceroute
ตัดสินใจว่าพนักงานพิมพ์อะไรและพาร์ตเนอร์บันทึกอะไร
งานพาร์ตเนอร์บางส่วนเหมาะกับพร็อกซีแอปพลิเคชันหรือพื้นที่ทำงานระยะไกลที่เปิดภายในบริบทของพาร์ตเนอร์รายนั้น งานอื่นต้องใช้การเข้าถึงเครือข่ายแบบกำหนดเส้นทางจากเซกเมนต์พนักงานที่ได้รับอนุมัติ และทั้งสองแบบสร้างที่อยู่ต้นทางและร่องรอยการตรวจสอบที่แตกต่างกันที่ปลายทางไกล ที่อยู่ต้นทางที่แปลแล้วซึ่งใช้ร่วมกันสามารถทำให้ผ่านรายการที่อนุญาตได้ในขณะที่ซ่อนว่าอุปกรณ์ใดทำอะไร ดังนั้นจึงควรรักษาบันทึกความสัมพันธ์ระหว่างพนักงานกับเซสชันที่เชื่อถือได้ และคงการพิสูจน์ตัวตนของแอปพลิเคชันไว้แทนที่จะถือว่าที่อยู่เกตเวย์เป็นตัวตน ซึ่งสะดวกจนถึงวินาทีที่พาร์ตเนอร์ถามว่าใครทำ
จากนั้นเดินตามงานจริงหนึ่งงานจากฝั่งพนักงาน: พวกเขาคลิกอะไร ระบบขออะไร และพาร์ตเนอร์จะเห็นอะไรถ้าขอบันทึกในล็อก ถ้าการเดินตามนั้นทำซ้ำไม่ได้ การออกแบบก็ยังไม่เสร็จ
ปฏิเสธการส่งผ่านระหว่างพาร์ตเนอร์อย่างชัดเจน
ฮาร์ดแวร์ที่ใช้ร่วมกันไม่ควรหมายถึงความไว้วางใจที่ใช้ร่วมกัน เพิ่มการปฏิเสธเป็นกฎที่ตั้งใจพร้อมผู้รับผิดชอบที่มีชื่อ ไม่ใช่เป็นอุบัติเหตุจากการกำหนดค่าที่ขาดหาย และทดสอบจากทั้งสองทิศทางด้วยคำขอที่ปกติจะสำเร็จ การทดสอบสำคัญเพราะการอนุญาตที่เพียงแต่ไม่มีอยู่อาจถูกเรียกคืนโดยวิศวกรคนถัดไปที่เพิ่มเส้นทางเพื่อแก้เรื่องร้องเรียนที่ไม่เกี่ยวข้อง
เขียนการปฏิเสธลงในบันทึกของพาร์ตเนอร์ข้างการอนุญาต เพื่อให้เจตนาคงอยู่แม้พนักงานเปลี่ยน
ดำเนินการเป็นบริการที่ใช้ร่วมกัน ไม่ใช่แล็ปท็อปที่ใหญ่ขึ้น
การต่ออายุอุโมงค์ การหมุนเวียนข้อมูลรับรอง ความจุ และการเปลี่ยนเกตเวย์ ตอนนี้ล้วนเป็นการเปลี่ยนแปลงของบริการที่ใช้ร่วมกัน ซึ่งหมายความว่าต้องมีกำหนดการและช่องทางสื่อสารที่แล็ปท็อปแต่ละเครื่องไม่เคยต้องการ ใบรับรองของพาร์ตเนอร์ที่หมดอายุวันเสาร์ไม่ใช่การหยุดให้บริการของผู้ใช้คนเดียวอีกต่อไป แต่เป็นการหยุดของทุกเซสชันของพาร์ตเนอร์รายนั้นพร้อมกัน
ยอมรับชั้นนั้นเมื่อคำขอข้ามพาร์ตเนอร์ที่ถูกปฏิเสธล้มเหลวตรงตามที่ตั้งใจ และคำขอของพนักงานที่ได้รับอนุญาตไปถึงปลายทางที่ถูกต้องด้วยต้นทางที่ถูกต้อง การขจัดความขัดแย้งของแล็ปท็อปขณะที่รักษาขอบเขตของแต่ละพาร์ตเนอร์ไว้คือประเด็นทั้งหมด การออกแบบที่ทุกคำนำหน้าระยะไกลเข้าถึงได้จากทุกโต๊ะเพียงแค่ย้ายปัญหาไปที่อื่น
เก็ตารางเล็ก ๆ ของพาร์ตเนอร์ บริบท ช่วงที่อนุญาต และผู้รับผิดชอบ มันจะเป็นสิ่งแรกที่ใคร ๆ ขอเมื่อเกิดเหตุการณ์