VPN qua nhiều đường: bốn bảo đảm mà nhà cung cấp phải cung cấp

Thêm liên kết WAN thứ hai và các đường hầm hoạt động, nhưng việc sao chép tệp vẫn đình trệ khi một đường chập chờn. Các liên kết khỏe mạnh và tiến trình VPN đang chạy; thứ còn thiếu là một hợp đồng giữa nhà cung cấp và đường hầm. Nhiều socket không tự động hành xử như một kết nối, và ứng dụng bên trên không thể thấy khác biệt cho đến khi việc phân phối hỏng. Mỗi phần của hợp đồng tương ứng với một lỗi bạn có thể kiểm thử, và đó là điều khiến nó hữu ích.

Hãy viết hợp đồng đó trước khi chọn sản phẩm. Nó có bốn phần: luồng mà VPN nhận, cách nhà cung cấp khôi phục dữ liệu bị thiếu, danh tính điểm cuối nào tồn tại qua thay đổi đường, và cách tổng thể hành xử khi một đường hỏng.

Triệu chứng: các liên kết hoạt động, phiên vẫn đứt

Một biểu đồ giám sát cho thấy cả hai liên kết hoạt động chỉ chứng minh rằng mỗi đường có thể mang lưu lượng. Nó không chứng minh VPN thấy một luồng có thứ tự, rằng gói mất trên một đường được khôi phục trên đường khác, hay rằng đối tác vẫn biết mình đang nói với phiên nào. Phần còn lại của hợp đồng bao quát điều biểu đồ đó không thể hiện.

Khi một lần truyền bị đình trệ, hãy tìm hiểu xem nhà cung cấp có tiếp tục phân phối trên đường còn sống không. Nếu phiên chết trong khi liên kết thứ hai nhàn rỗi, nhà cung cấp chưa bao giờ dùng nó. Nếu phiên sống nhưng dữ liệu đến sai thứ tự hoặc trùng lặp, nhà cung cấp đang chuyển gói mà không có hợp đồng ở cấp kết nối. Dấu thời gian ở hai bên thường làm rõ điều đó.

Sự khác biệt đó quyết định cách sửa. Vấn đề định tuyến hoặc chính sách cần thay đổi lựa chọn đường; thiếu tầng sắp xếp và khôi phục cần một giao vận khác, không phải bộ đệm lớn hơn.

Bảo đảm một: luồng byte cấp kết nối

Nếu VPN cần một luồng có thứ tự đáng tin cậy, nhà cung cấp phải xác định phạm vi byte phía trên từng đường. Mỗi kết nối TCP bên dưới chỉ đánh số các đoạn của chính nó, nên bên nhận không thể sắp xếp lại giữa các đường chỉ bằng những số đó.

Multipath TCP là ví dụ đã chuẩn hóa. Nó trình bày một luồng byte đáng tin cậy trong khi điều phối vài luồng con TCP, với ánh xạ tuần tự và xác nhận ở cấp dữ liệu. Ứng dụng đọc một luồng, không phải luồng con tình cờ giao một mảnh trước.

Trên Linux, MPTCP là opt-in theo từng socket qua IPPROTO_MPTCP. Khi thương lượng không thể dùng hành vi đa đường, phương án dự phòng được ghi nhận là TCP thông thường, nghĩa là ứng dụng có thể tiếp tục trên một đường mà không bao giờ dùng đường thứ hai. Hãy kiểm tra hành vi mà socket đã triển khai thực sự thương lượng thay vì giả định cấu hình nhân đã áp dụng.

Bảo đảm hai: thứ tự, trùng lặp và khôi phục

Các đường có độ trễ và tỷ lệ mất khác nhau buộc nhà cung cấp phải đệm, sắp xếp lại và truyền lại. Hợp đồng phải nêu rõ được phép đệm bao nhiêu, ứng dụng thấy áp lực ngược nào và đường nào mang lần truyền lại.

Một đường vẫn kết nối nhưng ngừng phân phối khó hơn một lần đóng sạch. Nhà cung cấp phải phát hiện nó, di chuyển dữ liệu còn tồn và tránh chờ mãi một đoạn sẽ không bao giờ đến. Kiểm tra đơn giản rằng cả hai liên kết đang hoạt động không bao quát trạng thái này.

Trùng lặp cần quy tắc riêng. Gửi cùng tải trọng trên cả hai đường có thể cải thiện độ trễ, nhưng bên nhận phải chặn bản sao trước khi nó đến VPN. Anti-replay của IPsec là tùy chọn theo hiệp hội bảo mật và kiểm tra số tuần tự; một tầng trùng lặp sắp xếp lại hoặc phát lại gói có thể kích hoạt nó hoặc che giấu vấn đề cho đến khi đường hầm sụp.

Bảo đảm ba: danh tính điểm cuối và kết nạp đường

Đối tác cần một cách ổn định để nhận ra phiên khi một đường mới xuất hiện. Nếu mỗi đường được xác thực như một đường hầm riêng, VPN có thể thấy hai phiên thay vì một. Nếu nhà cung cấp hợp nhất các đường dưới một phiên, nó phải định nghĩa cách đường mới được xác thực và điều gì xảy ra với đường cũ.

Ghi lại địa chỉ và định danh nào vẫn ổn định: điểm cuối đường hầm, định danh phiên của nhà cung cấp và bất kỳ proxy trung gian. Proxy thêm một ranh giới sẵn sàng và tin cậy khác ngay cả khi nó không bao giờ thấy tải trọng được bảo vệ.

Chính sách cũng nằm ở đây. Một đường kết nạp từ mạng bất ngờ có thể hợp lệ về kỹ thuật và vẫn vi phạm mô hình tin cậy dự kiến. Hãy quyết định liệu đường mới được chấp nhận tự động, yêu cầu xác thực hay bị từ chối.

Bảo đảm bốn: hành vi có giới hạn khi lỗi

Kiểm thử lỗi toàn bộ đường, không chỉ đường chậm. Đường còn sống phải mang phiên mà không tăng bộ nhớ vô hạn, và khôi phục không được phụ thuộc vào bộ hẹn giờ dài hơn mức ứng dụng chịu được. Khi đường hỏng trở lại, nhà cung cấp phải quyết định tái cân bằng hay để luồng nguyên chỗ.

Đặt giới hạn cho đệm, truyền lại và số đường, rồi kiểm chứng dưới mất gói, sắp xếp lại, trùng lặp và lệch độ trễ. Băng thông tổng hợp là con số ít thú vị nhất ở đây; tính liên tục phân phối và giới hạn bộ nhớ mới là hợp đồng.

Giữ trạng thái khôi phục của nhà cung cấp tách biệt khỏi trạng thái mật mã của VPN. Một tầng tin cậy tùy chỉnh thay thế xác thực hoặc mã hóa đã thiết lập không phải đường tắt, và dùng lại số tuần tự giữa các tầng khiến bảo vệ replay và chẩn đoán không đáng tin.

Chấp nhận nhà cung cấp bằng một kế hoạch kiểm thử

Viết bốn bảo đảm thành các kiểm tra đạt hoặc không đạt: một luồng có thứ tự, khôi phục xác định, danh tính phiên ổn định, hành vi lỗi có giới hạn. Chạy từng kiểm tra với một đường bị suy giảm và sau đó với một đường bị loại bỏ.

Một lần truyền tệp thành công qua thay đổi đường không chứng minh vận hành liên tục. Lặp lại truyền trong khi chuyển đường ưu tiên, và kiểm tra cả góc nhìn của nhà cung cấp lẫn bộ đếm của chính VPN. Nếu hai bên không đồng ý về đường nào đã mang dữ liệu, hợp đồng vẫn chưa quan sát được.

Giữ ma trận đã ký với bản triển khai. Nó cho kỹ sư tiếp theo biết hành vi nào đã hứa, tổ hợp đường nào đã kiểm thử và chế độ lỗi nào vẫn chưa được hỗ trợ, mà không cần thêm một vòng đoán từ đèn trạng thái liên kết.