Chuyển khỏi VPN dựa trên PPP mà không sao chép các giả định của nó

Một cuộc di trú VPN kết thúc khi người dùng, đích đến, phân giải tên và hành vi khi có sự cố vẫn đều đúng, không phải khi máy khách mới hiển thị biểu tượng xanh. Các triển khai cũ dựa trên PPP mang theo những giả định chưa từng được ghi lại: một bí mật chung vừa là kiểm tra danh tính duy nhất, một nhóm địa chỉ cố định mà tường lửa đưa vào danh sách cho phép, và một hậu tố DNS do máy chủ đẩy xuống. Thay giao thức mà không kiểm kê những giả định đó tạo ra một đường hầm hoàn tất handshake và một ranh giới không tồn tại. Trình tự dưới đây là trình tự tôi dùng, và bước cuối là bước mà các nhóm thường bỏ qua.

Bước 1: kiểm kê những gì kết nối cũ cung cấp

Bản kiểm kê được viết ra chứ không ghi nhớ. Ghi lại máy khách được hỗ trợ, các vai trò xác thực, nhóm địa chỉ, mạng được bảo vệ, yêu cầu DNS và quyền dịch vụ mà mỗi nhóm người dùng cần.

Với L2TP/IPsec, hãy tách rõ hai lớp. Danh tính của đối tác IPsec xác thực máy; PPP xác thực người dùng, thường bằng CHAP hoặc MSCHAPv2.

Chính trong sự tách biệt đó, các triển khai cũ giấu giả định của mình. Một khóa chia sẻ trước mà mọi máy khách dùng chung xác thực một nhóm chứ không phải một thiết bị, và thường đó là thứ duy nhất từng được luân chuyển. Nếu tài khoản PPP là kiểm soát thật theo từng người dùng, hãy nói rõ, vì giải pháp thay thế phải tái tạo kiểm soát đó bằng thứ không phải chuỗi chia sẻ. Cũng ghi lại địa chỉ nguồn cố định và ngoại lệ mạng nội bộ, vì đó là những phụ thuộc mà không ai ghi lại cho đến khi chúng hỏng.

Bước 2: thiết kế giải pháp thay thế một cách có chủ đích

Chọn giải pháp thay thế là ánh xạ yêu cầu theo yêu cầu: một giao thức và một máy khách được duy trì mà tổ chức hỗ trợ, với mỗi yêu cầu về danh tính và truy cập rơi vào một cơ chế thực. Bí mật chung không tự động tương đương khóa hay chứng chỉ theo từng thiết bị, và tài khoản PPP theo từng người dùng không tương đương chứng chỉ thiết bị.

Phối hợp dải địa chỉ trước mọi thứ khác, vì nhóm thay thế chồng lấn với LAN gia đình hoặc văn phòng tạo ra sự cố không liên quan gì đến độ mạnh của mật mã. Kiểm tra nhóm địa chỉ với cùng danh sách bạn đã lập cho dịch vụ cũ, cộng với những gì máy khách mới giả định theo mặc định. Xác nhận định tuyến trả về cho các mạng được bảo vệ và xác nhận rằng máy khách mới có thể đẩy hoặc ghi lại hậu tố DNS mà máy khách cũ đã đẩy. Hai điểm đó tạo ra nhiều phiếu di trú hơn chính việc đổi giao thức.

Bước 3: triển khai theo giai đoạn và xác minh cả cho phép lẫn từ chối

Triển khai với một người dùng đại diện và một ứng dụng đại diện. Đưa phân giải DNS nội bộ vào bài kiểm tra, vì một đường hầm đến được địa chỉ nhưng không phân giải được tên nội bộ mới chỉ di trú một nửa. Cũng đưa vào trạng thái không khả dụng mong đợi: điều gì phải xảy ra khi đường hầm rơi, và máy khách có thực thi điều đó không.

Sau đó kiểm tra một đích cần tiếp tục bị từ chối. Một quy tắc cho phép tạm thời rộng có thể làm đường hầm mới trông khỏe mạnh trong khi âm thầm gỡ bỏ ranh giới ủy quyền mà dịch vụ cũ thực thi, và không ai nhận ra cho đến khi kiểm toán. So sánh kết quả cho phép và từ chối cạnh nhau, từ cùng máy khách, trong cùng phiên. Giữ dịch vụ cũ chạy cho đến khi cả hai cột khớp với thiết kế.

Trước khi chuyển quyền truy cập quản trị, hãy xác nhận bạn có một đường khôi phục được ủy quyền không phụ thuộc vào đường hầm đang thay đổi.

Bước 4: ngừng sử dụng danh tính cũ

Ngừng sử dụng danh tính cũ đúng cách nghĩa là thu hồi người dùng và thông tin đăng nhập thiết bị lỗi thời thông qua dịch vụ sở hữu chúng, sau đó xóa hồ sơ và trình lắng nghe cũ khi không còn phụ thuộc nào. Xóa một tệp cục bộ không thu hồi bản sao ở nơi khác, và một trình lắng nghe cũ vẫn chấp nhận bí mật chung cũ là cánh cửa không được giám sát.

Điểm đó đáng để chậm lại. Một hồ sơ máy khách đã ngừng trên máy tính xách tay không phải là thông tin đăng nhập bị thu hồi; thông tin đăng nhập sống trên máy chủ và vẫn hợp lệ cho đến khi máy chủ ngừng chấp nhận nó. Hãy tìm các bản sao khác của cấu hình cũ — thiết bị kiểm thử, điện thoại bị quên, trình cài đặt mà ai đó giữ lại — và coi việc tắt trình lắng nghe là thời điểm dịch vụ cũ thực sự kết thúc. Cho đến lúc đó, cuộc di trú có hai cửa trước.

Bản ghi chấp nhận là bản kiểm kê từ bước một với một cột thêm vào: thiết kế mới làm gì cho từng hàng, và bạn đã xác minh thế nào. Điều đó biến một lần nâng cấp giao thức thành một yêu cầu dịch vụ có bằng chứng.

Giữ kết quả gắn với điều dịch vụ cần chứ không phải tên giao thức, vì một giao thức hiện đại với những giả định cũ được sao chép vào là cùng một rủi ro với khung tốt hơn. RFC 3193 mô tả cách L2TP được mang trên IPsec, một lời nhắc hữu ích rằng hai lớp luôn là những quyết định riêng. Nếu bản kiểm kê có một hàng bạn không giải thích được, hãy dừng lại và tìm hiểu cái gì phụ thuộc vào nó. Cuộc di trú kết thúc khi danh sách trở nên nhàm chán.