วางแผนซับเน็ตก่อนทำ VPN ระหว่างไซต์: กำหนดหมายเลขใหม่หรือแปลที่อยู่

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

จัดทำบัญชีทุกช่วง รวมถึงช่วงที่คุณลืม

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

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

ทำ IPv6 แยกต่างหาก เพราะแผนและการทับซ้อนของมันเป็นอิสระจากกัน

เปรียบเทียบคำนำหน้า ไม่ใช่ที่อยู่ที่คุ้นเคย

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

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

ตารางคำนำหน้าพร้อมมาสก์ก็เพียงพอ แผนภาพที่ไม่มีมาสก์ไม่เพียงพอ

ตัดสินใจว่าอะไรต้องข้ามจริง ๆ

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

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

เขียนรายการการเข้าถึงก่อนการกำหนดค่าอุโมงค์ ไม่ใช่หลังจากที่มันล้มเหลว

กำหนดหมายเลขใหม่หรือแปลที่อยู่ และรู้ต้นทุน

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

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

วิธีเลี่ยงที่ไม่มีเส้นทางกลับไม่ใช่วิธีเลี่ยง

ใช้เมทริกซ์เส้นทางเป็นการทดสอบการยอมรับ

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

การ ping ระหว่างที่อยู่ของอุโมงค์พิสูจน์ว่าอุโมงค์มีอยู่ และไม่ได้บอกอะไรเกี่ยวกับแผนที่อยู่เบื้องหลัง

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