สองไซต์ หนึ่งซับเน็ต: สร้างมุมมองนามแฝงสำหรับแต่ละแห่ง

สองไซต์ของลูกค้าต่างใช้ 192.168.50.0/24 และวิศวกรระยะไกลต้องเข้าถึงเครื่องพิมพ์ที่อยู่ที่อยู่เดียวกันในแต่ละไซต์ ไม่มีเทคนิคการกำหนดเส้นทางใดแก้ความกำกวมนั้นได้ด้วยตัวเอง แต่ละไซต์ต้องการมุมมองที่อยู่ที่แตกต่างกัน และเกตเวย์ต้องเลือกไซต์จากมุมมองนั้นก่อนส่งต่อสิ่งใด

แผนมีสี่ส่วน: คำนำหน้านามแฝง ทิศทางการแปลทั้งสองทิศทาง นโยบายโอเวอร์เลย์ และชื่อ แต่ละส่วนต้องสอดคล้องกับส่วนอื่น

เลือกคำนำหน้านามแฝงหนึ่งคำต่อไซต์

กำหนดคำนำหน้านามแฝงแบบเต็มให้แต่ละไซต์ซึ่งไม่มีใครอื่นในสภาพแวดล้อมเป็นเจ้าของ แผนสำหรับสองไซต์อาจแมป 192.168.50.0/24 ของไซต์ A ไปยัง 172.21.10.0/24 และ LAN ที่เหมือนกันของไซต์ B ไปยัง 172.21.20.0/24 ตรวจสอบผู้สมัครกับทุกเครือข่ายที่เข้าร่วม รวมถึง VPC บนคลาวด์และพูล VPN อื่น พื้นที่ที่อยู่ส่วนตัวถูกใช้ร่วมกันโดยทุกองค์กร ดังนั้นการที่ช่วงหนึ่งเป็น RFC 1918 ไม่ได้บอกอะไรว่าว่างที่นี่

เผยแพร่นามแฝง ไม่ใช่ซับเน็ตดั้งเดิม ให้ผู้ใช้ระยะไกล ช่วงดั้งเดิมยังคงเป็นข้อเท็จจริงภายใน

แปลทั้งสองทิศทาง

แปลทั้งสองทิศทาง การแมปปลายทางเขียนที่อยู่ของนามแฝงใหม่เป็นที่อยู่ดั้งเดิมที่ไซต์ที่เป็นเจ้าของ การแมปต้นทางเขียนผู้เรียกจากระยะไกลใหม่เป็นนามแฝงที่ไซต์อื่นแยกแยะได้

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

ขั้นตอนที่แน่นอนซึ่งนโยบาย ตัวเลือก และเส้นทางมีผลนั้นแตกต่างกันระหว่าง IPsec ที่อิงนโยบาย อุโมงค์ที่อิงเส้นทาง และผลิตภัณฑ์อื่น ออกแบบสำหรับสิ่งที่คุณใช้งาน

พาแผนผ่านโอเวอร์เลย์

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

การเผยแพร่ทั้งซับเน็ตกว้างกว่าการเผยแพร่บริการเดียว หากต้องการเพียงไม่กี่เครื่องหรือพอร์ต ให้เข้มงวดกฎการเข้าถึงให้แคบกว่าการแมป

การแปลส่วนหัวไม่ได้เขียนเพย์โหลดของแอปพลิเคชันใหม่ การเปลี่ยนเส้นทาง ที่อยู่ที่ฝังในไฟล์กำหนดค่า และสิทธิ์ที่อิงต้นทางยังคงพาที่อยู่ดั้งเดิมได้ทั้งหมด ทดสอบเส้นทางของแอปพลิเคชัน ไม่ใช่แค่ ping การตอบกลับ ICMP ที่ทำงานได้พิสูจน์ว่าการแมปมีอยู่ และไม่ได้บอกอะไรว่าแอปพลิเคชันยอมรับนามแฝงหรือไม่

แก้ไขชื่อที่ผู้เรียกแต่ละรายเห็น

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

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

บันทึกและตรวจสอบต่อไซต์

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

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