เมื่อใดที่ NAT ภายใน VPN แบบไซต์ทูไซต์จึงคุ้มค่ากับตำแหน่งของมัน

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

ตัดสินใจว่าจะเขียนแอดเดรสใดใหม่

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

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

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

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

ติดตามเพย์โหลดและเส้นทางกลับ

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

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

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

ชั่งน้ำหนักกับการเปลี่ยนเลขไซต์

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

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

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

พิสูจน์ทั้งสองทิศทางด้วยเซสชันจริง

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

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

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

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