วิธีกำหนดขนาดพื้นที่ที่อยู่สำหรับ VPN ระหว่างไซต์

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

ตั้งชื่อบทบาททั้งสี่ก่อนจะจัดสรรอะไร

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

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

ip -br addr show
ip route show | head -40

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

นับลิงก์และโทโพโลยี ไม่ใช่อุปกรณ์

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

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

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

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

เก็บซับเน็ตของเกตเวย์ไว้นอกพูลของ LAN

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

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

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

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

บันทึกบทบาท เจ้าของ และการเติบโตของทุกคำนำหน้า

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

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

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