Hai đường hầm IPsec đang hoạt động vẫn cần kế hoạch đường về

Mở một terminal trên máy trạm ở một site và kết nối tới máy chủ ở site kia. Cuộc trò chuyện TCP duy nhất đó giờ phải đi qua bốn cổng thay vì hai, và phần thú vị không phải là liệu nó có chạy được vào một ngày đẹp trời hay không. Phần thú vị là cặp cổng nào đã được hướng đi chọn, cặp nào được câu trả lời chọn, và ai đang giữ trạng thái của luồng trong lúc đó. Không gì trong bảng định tuyến quyết định điều đó thay bạn.

Vẽ bốn cổng trước khi vẽ một tuyến

Một thiết kế kép chủ động với hai tường lửa VPN độc lập mỗi site, một cặp mỗi nhà cung cấp, cho bạn hai đường đi dùng được và ba cách phá chúng. Ghi lại các địa chỉ trước khi cấu hình bất cứ thứ gì: máy khách như được thấy trước và sau mỗi cổng, máy chủ cũng vậy, bước nhảy kế tiếp chiều đi và bước nhảy kế tiếp chiều về.

Bảng đó chính là thiết kế. Mọi thứ sau đó là câu hỏi liệu các thiết bị có đồng ý với bảng hay không.

Đường đi được chọn như thế nào

Một lớp định tuyến đa đường chi phí bằng nhau phân phối luồng lên các bước nhảy kế tiếp bằng cách băm các trường tiêu đề, điều mà RFC 2992 mô tả chi tiết. Lựa chọn đó có thể hoàn toàn không trạng thái: nó không cần bản ghi theo dõi kết nối, chỉ cần một hàm băm ổn định trên các trường không đổi. Giữ tập tuyến và đầu vào băm không đổi, và mọi gói của luồng sẽ chọn cùng một bước nhảy kế tiếp.

Lựa chọn theo từng luồng tránh việc sắp xếp lại mà cân bằng từng gói một sẽ gây ra trên các liên kết có độ trễ khác nhau. Nó không hứa rằng chi phí định tuyến bằng nhau nghĩa là độ trễ đo được bằng nhau, vì không phải vậy. Và khi thành phần tuyến thay đổi, các luồng được ánh xạ lại, nên việc kết nối sống sót trong sự cố là yêu cầu riêng so với việc chọn tuyến.

Điều mà đường về thực sự cần

Ở đây hành trình không còn đối xứng. Một hàm băm chiều đi ổn định không cho bạn biết site xa sẽ làm gì với câu trả lời. Nếu một tường lửa độc lập phải thấy cả hai chiều của kết nối để duy trì trạng thái hữu ích, một tuyến về đi vòng qua nó sẽ để lại lưu lượng không khớp với gì cả. Hai hộp có bộ quy tắc giống nhau không phải là trạng thái chia sẻ.

Xác nhận hành vi hai chiều đã triển khai, hoặc viết chính sách rõ ràng giữ các ranh giới cần thiết nhất quán. Một phỏng đoán ở đây bị phát hiện trong lúc sự cố, bởi những người không thấy vui vẻ gì.

Nơi bản dịch quyết định thay bạn

NAT là đòn bẩy khác, và nó là tùy chọn chứ không bắt buộc. Các danh tính đã dịch theo tuyến có thể đưa câu trả lời trở lại cổng đang giữ trạng thái, đó là một thiết kế hợp lệ. Nhưng chúng thêm ánh xạ, tuyến về và một chủ sở hữu cho trạng thái đó, nên chỉ chấp nhận gánh nặng vì một yêu cầu bạn có thể nói to.

Nếu yêu cầu chỉ là cả hai tuyến đều chở lưu lượng và một trong hai sống sót khi mất nhà cung cấp, thì định tuyến đa đường theo luồng thông thường với định tuyến về nhất quán thường là thiết kế nhỏ hơn.

Đi qua nghiệm thu theo thứ tự

Kiểm thử theo thứ tự này và ghi lại địa chỉ ở từng bước: một kết nối mới trên tuyến A và tuyến trả lời của nó, điều tương tự trên tuyến B, sau đó mất một nhà cung cấp, sau đó khôi phục. Với mỗi kết quả, ghi lại luồng đã thiết lập nào đã di chuyển, luồng nào phải kết nối lại và luồng mới đi đâu sau đó. Hãy viết giá trị kỳ vọng trước, rồi so sánh với bản bắt gói. Hai đường hầm đã thiết lập không chứng minh được gì trong số đó.

Thiết kế hoàn tất khi bảng bạn viết khớp với những gì bản bắt gói cho thấy, không phải khi cả hai đường hầm đều đã lên.