ปลายทั้งสองมีซับเน็ตเดียวกัน: แมป LAN ระยะไกลไปยังช่วงว่าง

บ้านและสำนักงานใช้ 192.168.1.0/24 เหมือนกัน คำขอไปยัง 192.168.1.1 จึงมีคำตอบที่เป็นไปได้สองอย่างและไคลเอนต์เลือกอย่างใดอย่างหนึ่งโดยไม่ถาม การเปลี่ยนเลขเครือข่ายสำนักงานที่ใช้งานอยู่แทบไม่เคยเป็นที่นิยม และที่อยู่ของเราเตอร์มักถูกฝังไว้ในเครื่องพิมพ์ กล้อง และเอกสาร การแมปที่อยู่ฝั่งไคลเอนต์สามารถนำเสนอเครือข่ายระยะไกลภายใต้ช่วงว่างแทน และส่วนโฮสต์สามารถคงเดิมได้เพื่อให้ 192.168.1.20 ปรากฏเป็น 10.203.41.20 จุดที่ต้องระวังคือมีไคลเอนต์เพียงบางตัวที่ใช้งานมัน และมันไม่ได้ทำอะไรให้เส้นทางกลับเลย

สองมุมมองของโฮสต์เดียวกัน

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

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

ลำดับอาร์กิวเมนต์คือกลอุบายทั้งหมด

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

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

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

การแมปไม่ได้สร้างเส้นทางกลับ

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

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

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

ชื่อและเพย์โหลดรอดจากการแปล

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

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

สามการตรวจสอบก่อนผูกมัด

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

อย่างที่สอง ตรวจสอบเส้นทางและการแปลแยกกันด้วยหน้าต่างวินิจฉัยสั้น ๆ ที่ระดับรายละเอียดสูง แล้วทดสอบบริการจริงแทน ping อย่างที่สาม ยืนยันว่าเราเตอร์ภายในและทรัพยากรระยะไกลยังแยกออกจากไคลเอนต์ได้ เพราะนั่นคือเป้าหมายเดิม

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