เปลี่ยน ISP โดยไม่ต้องเปลี่ยนเลขที่อยู่ VPN ของไซต์

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

แผนที่อยู่สองแผนที่เคลื่อนที่อย่างเป็นอิสระ

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

การเปลี่ยนผู้ให้บริการแตะแผนภายนอก โดยตัวมันเองไม่เรียกร้องให้แผนภายในเปลี่ยน

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

อุโมงค์ภายนอกบรรทุกบทสนทนาภายใน

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

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

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

การย้ายผู้ให้บริการยังมีรายการตรวจสอบ

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

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

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

สิ่งที่อยู่รอดไม่ได้: แหล่งสาธารณะและเซสชัน

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

การรักษาที่อยู่นั้นให้เสถียรต้องมีการออกแบบทางออกอย่างตั้งใจ พร้อมความพร้อมใช้งานและนโยบายของตัวเอง มันไม่ได้มาฟรีพร้อมอุโมงค์

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

ตรวจสอบการย้ายด้วยการตรวจสี่อย่าง

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

บนเกตเวย์ Linux สามอย่างนี้ครอบคลุมตรงกลางของรายการนั้น

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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