เมื่อไคลเอนต์รีโมตแอ็กเซสต้องทำหน้าที่เป็นเกตเวย์สาขา

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

สิ่งที่ป้ายชื่อโปรโตคอลไม่ได้บอกคุณ

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

คำถามที่ต้องตัดสินก่อนคือเจ้าของ VPN รองรับบทบาทการส่งต่อหรือไม่เลย ถ้าไม่ การกำหนดเส้นทางฝั่งไคลเอนต์มากเท่าใดก็ทำให้มันได้รับการรองรับไม่ได้

สัญญามีสองด้าน: สาขาและสำนักงานใหญ่

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

เส้นทางขากลับคือส่วนที่มักถูกข้ามไป ที่อยู่ tunnel ของไคลเอนต์ไม่ได้ประกาศซับเน็ตที่อยู่เบื้องหลัง ดังนั้นเราเตอร์ของสำนักงานใหญ่จึงต้องการเส้นทางที่ชี้ไปยังเกตเวย์ VPN สำหรับคำนำหน้านั้น

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

เราเตดหรือแปลง: เลือกเส้นทางขากลับอย่างตั้งใจ

เลือกแบบเราเตดเมื่อตัวตนรายอุปกรณ์และนโยบายรายโฮสต์มีความสำคัญ และคุณสามารถดูแลเส้นทางขากลับบนเราเตอร์ที่เกี่ยวข้องทุกตัวได้

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

การตรวจสอบที่มีประโยชน์เป็นแบบอสมมาตร: ขอทรัพยากรจากอุปกรณ์ในสาขา แล้วยืนยันว่าคำตอบออกจากสำนักงานใหญ่ไปยังคำนำหน้าของสาขา traceroute -n 10.60.4.20 จากโฮสต์ในสำนักงานใหญ่จะแสดงว่าเส้นทางนั้นผ่านเกตเวย์ VPN หรือไม่

ปฏิบัติกับมันเหมือนโครงสร้างพื้นฐาน ไม่ใช่การล็อกอิน

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

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

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