Đổi ISP mà không đánh số lại địa chỉ VPN của site

Một chi nhánh đổi nhà cung cấp internet và máy chủ tệp vẫn giữ nguyên địa chỉ. Kết quả đó là bình thường trong VPN site định tuyến và gây bất ngờ cho bất kỳ ai cho rằng địa chỉ đầu cuối của tunnel chính là địa chỉ của ứng dụng. Hai thứ nằm ở các tầng thiết kế khác nhau và chỉ một thứ đã dịch chuyển. Coi chúng là một chính là cách một cuộc di trú nhà cung cấp biến thành dự án đánh số lại.

Hai phương án địa chỉ dịch chuyển độc lập

Phương án bên trong mô tả các địa chỉ riêng mà ứng dụng dùng: máy chủ chi nhánh tại 10.55.8.20, tiền tố trụ sở chính định tuyến tới đó và đường quay về. Phương án bên ngoài mô tả cách hai gateway đến được nhau: địa chỉ peer, cổng lắng nghe và đường đi xuyên internet.

Thay đổi nhà cung cấp tác động lên phương án bên ngoài. Tự nó không đòi hỏi phương án bên trong phải thay đổi.

Giữ hai bản kiểm kê tách biệt là lý do thực tế để chạy lớp phủ ngay cả khi ứng dụng đã tự mã hóa lưu lượng của mình. Lớp phủ cho bạn một cấu trúc liên kết bên trong ổn định, sống sót qua biến động bên ngoài. Ứng dụng giữ địa chỉ, quy tắc tường lửa và bản ghi DNS của nó. Chỉ các mục vận chuyển thay đổi, và đó là một lần rà soát nhỏ hơn nhiều.

Tunnel bên ngoài mang cuộc trò chuyện bên trong

Trong tunnel gateway-tới-gateway, tiêu đề IP bên ngoài đánh địa chỉ hai gateway. Tiêu đề bên trong vẫn nêu các đầu cuối ứng dụng thực tế. Mô tả gateway-tới-gateway trong RFC 7296 coi đây là định tuyến thông thường đưa lưu lượng qua các đầu cuối tunnel.

Đó là lý do máy chủ chi nhánh có thể giữ 10.55.8.20 trong khi địa chỉ công cộng của gateway thay đổi. Gói tin bên trong hoàn toàn không chứa địa chỉ của nhà cung cấp.

Sự tách biệt là một thuộc tính thiết kế, không phải bảo đảm tự động. Nếu đường truyền thay thế không thiết lập được tunnel được hỗ trợ, hoặc các tuyến bên trong không được cài lại, ứng dụng mất đường đi dù địa chỉ không đổi.

Việc chuyển nhà cung cấp vẫn có danh sách kiểm tra

Danh sách kiểm tra bên ngoài có năm mục: địa chỉ peer hoặc tên được duy trì, bộ lắng nghe và mọi lọc thượng nguồn, chuyển dịch trên đường, danh tính peer dự kiến và các thiết lập được phép của gateway kia. Mỗi mục có thể hỏng riêng. Hãy giữ một đường khôi phục riêng trong khi bạn đổi đường truyền mang quản trị. Cắt truy cập từ xa trong lúc chuyển đường truyền là sự cố do chính bạn tạo ra.

Sau đó kiểm tra tiền tố chi nhánh, tuyến theo cả hai chiều, chính sách bảo vệ và một luồng ứng dụng thật. Một tunnel vừa xác thực không sửa được tuyến đang trỏ tới subnet riêng cũ.

Trùng địa chỉ với một site khác đang kết nối là vấn đề quy hoạch riêng. Thay đổi nhà cung cấp không tạo ra nó, nhưng di trú thường là lúc nó lộ ra.

Những gì không tồn tại: nguồn công cộng và phiên

Địa chỉ máy chủ riêng ổn định không phải nguồn công cộng ổn định. Nếu duyệt web đi thẳng ra qua nhà cung cấp mới, các trang web thấy địa chỉ hướng tới nhà cung cấp mới.

Giữ địa chỉ đó ổn định cần một thiết kế lối ra có chủ đích, với tính sẵn sàng và chính sách riêng. Nó không đi kèm miễn phí với tunnel.

Các phiên đã thiết lập cũng không sống sót qua thay đổi đường đi. Tunnel có thể thiết lập lại trong vài giây mà vẫn làm đứt các kết nối dài hạn bị ghim vào đường cũ. Hãy lên kế hoạch chuyển trong khoảng thời gian mà việc kết nối lại là chấp nhận được. Đừng tuyên bố di trú sẽ vô hình trừ khi các client cụ thể và thời gian chờ của chúng đã được kiểm thử.

Xác minh việc chuyển bằng bốn kiểm tra

Sau thay đổi, hãy xác minh bốn điều theo thứ tự: tunnel được thiết lập với peer dự kiến, tuyến bên trong tới tiền tố chi nhánh tồn tại, chính sách cho phép luồng ứng dụng và ứng dụng phản hồi. Mỗi điều có lệnh riêng.

Trên một gateway Linux, ba điều này bao phần giữa của danh sách đó:

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

Giữ địa chỉ vận chuyển trong một bản kiểm kê và địa chỉ ứng dụng trong bản khác. Chỉ cập nhật những mục thực sự dịch chuyển. Đánh số lại các phụ thuộc bên trong vì địa chỉ bên ngoài của tunnel đã đổi là công việc có thể tránh được.