Mục VPN WAN thứ hai thất bại trong khi mục chính vẫn hoạt động

Đường hầm chính vẫn hoạt động, người dùng vẫn làm việc, và mạch ISP thứ hai cứ nằm không dù bạn thay đổi gì. Bạn đã công bố một địa chỉ cho mạch dự phòng, trỏ một tên vào đó, có thể đã thêm một mục dự phòng vào máy khách, và máy khách hoặc không bao giờ thử nó hoặc xác thực rồi sau đó chết. Trong các trường hợp tôi đã lần theo, tính năng chuyển đổi dự phòng thường vẫn ổn; thứ thiếu là một trong năm điều khiến một mục dùng được. Một tên có thể phân giải đến địa chỉ dự phòng trong khi không có gì lắng nghe trên giao diện đó, và một trình lắng nghe có thể nhận kết nối trong khi câu trả lời đi ra qua mục chính. Hãy coi mỗi WAN là một mục riêng với hợp đồng riêng của nó, và sự cố sẽ không còn trông giống lỗi của máy khách.

Mỗi WAN cần hợp đồng mục riêng

Ghi năm trường cho mỗi WAN: tên và địa chỉ công khai, giao vận và cổng, giao diện hoặc ngữ cảnh kết thúc nó, danh tính đối tác mà nó phải trình bày, và nơi câu trả lời đi ra. Hai mạch nghĩa là hai bộ hoàn chỉnh. Nếu bộ thứ hai không có giao diện kết thúc hoặc không có đường trả về, bạn không có mục dự phòng; bạn có một bản ghi DNS mô tả ý định.

Thiết bị và phiên bản của nó cũng phải hỗ trợ cách bố trí này. Một bản ghi DNS không thể mở dịch vụ trên giao diện khác, và trên nhiều nền tảng trình lắng nghe được cấu hình theo địa chỉ chứ không theo thiết bị. IPsec dựa trên giao diện trên ASA gắn bản đồ mật mã và nhóm đường hầm vào giao diện ngoài, nên đường lên thứ hai cần chính sách ở nơi các gói đó thực sự đến. Các thiết kế dựa trên tuyến hoạt động khác đi: trình lắng nghe có thể gắn với mọi địa chỉ hoặc với một địa chỉ được đặt tên, và lựa chọn đó quyết định ISP B có trả lời được hay không.

Kiểm tra xem WAN thứ hai có thực sự trả lời

Kiểm tra từ bên ngoài cả hai mạch, không phải từ một máy sau cổng, và kiểm tra đúng tên mà hồ sơ máy khách sử dụng. Với một trình lắng nghe TLS, kiểm tra nhanh là openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts được chạy từ một máy chủ ngoài mạng của bạn. Bạn muốn một bắt tay hoàn tất có chuỗi khớp với tên trong hồ sơ, không chỉ một cổng TCP chấp nhận kết nối.

RFC 9525 giải thích điều máy khách kiểm tra: danh tính mà nó định đến, so với chứng chỉ mà dịch vụ trình bày. Một mục thứ hai trả về chứng chỉ của mục chính, hoặc một chứng chỉ mặc định không liệt kê tên nào trong hai tên, sẽ trượt bài kiểm tra này dù cổng mở và tường lửa cho phép.

Hai mẫu giải thích hầu hết các lỗi ở đây. Một kết nối bị treo thường có nghĩa là không có trình lắng nghe trên giao diện đó, một quy tắc truy cập chỉ cho phép các mạng con chính, hoặc một thiết bị của nhà mạng trước mạch thứ hai đang bỏ cổng. Một bắt tay kết thúc với danh tính sai thường có nghĩa là một điểm tin cậy khác, một máy chủ ảo mặc định, hoặc cấu hình sao chép từ mục chính mà không điều chỉnh danh tính.

Theo dõi câu trả lời, không chỉ yêu cầu

WAN thứ hai thường hỏng trên đường trở về. Một yêu cầu đến trên ISP B, thiết bị trả lời, và câu trả lời đi ra qua tuyến mặc định trên ISP A với địa chỉ nguồn mà máy khách không bao giờ yêu cầu. Dịch có trạng thái làm tệ hơn: nếu ánh xạ được xây cho giao diện chính, gói trở về sẽ trượt phép dịch hoặc mang một nguồn mà tường lửa của máy khách loại bỏ. Các nhà cung cấp cũng loại bỏ địa chỉ nguồn không thuộc mạch họ đã cấp, đó là lý do điều này trông giống một hố đen một chiều thay vì một lỗi giao thức sạch.

Kiểm tra quyết định định tuyến cho lưu lượng có nguồn từ mục thứ hai. Câu trả lời phải đi ra qua giao diện mà yêu cầu đến, hoặc ít nhất mang một địa chỉ mà phía xa chấp nhận là thuộc đường đó. Trên các nền tảng định tuyến theo chính sách, điều đó nghĩa là một quy tắc gắn với giao diện vào hoặc nguồn đã dịch, cộng với một câu lệnh dịch gắn với mỗi giao diện ngoài. Bắt gói trên cả hai giao diện cùng lúc khi máy khách kết nối; một SYN đến trên ISP B với SYN-ACK đi ra trên ISP A giải quyết câu hỏi trong một lần chạy.

Cho máy khách một cách để biết về mục thứ hai

Chuyển đổi dự phòng là quyết định phía máy khách, và mỗi họ máy khách học về các lựa chọn thay thế theo cách khác nhau. Trên ASA, danh sách máy chủ dự phòng được gửi qua các thuộc tính webvpn của chính sách nhóm, trong khi các máy khách khác mong đợi một danh sách trong hồ sơ hoặc một hồ sơ thứ hai thủ công do người dùng chọn. Hướng dẫn chính sách kết nối của Cisco mô tả cả thông tin dự phòng do máy khách cấu hình và do cổng cung cấp, và những chi tiết riêng của giao thức đó không nên được khái quát cho mọi máy khách hoặc chế độ đường hầm. Xác nhận cơ chế nào mà máy khách đã triển khai thực hiện trước khi xây mục thứ hai quanh cái sai.

Dù cơ chế nào, máy khách phải phân giải được tên thay thế trước khi mất đường chính. Chính sự phụ thuộc đó là thứ mọi người bỏ qua: nếu tên dự phòng được trả lời bởi một trình phân giải chỉ tiếp cận được qua đường hầm vừa hỏng, dự phòng thậm chí không thể bắt đầu. Công bố tên thứ hai trong một trình phân giải trả lời cục bộ hoặc qua internet. Hãy mong đợi một lần xác thực mới và một phiên ứng dụng mới sau khi chuyển, vì chuyển đổi dự phòng phía máy khách không phải chuyển đổi có trạng thái và các phiên dài không sống sót qua nó.

Một địa chỉ trên hai nhà cung cấp là một sản phẩm khác

Giữ một địa chỉ công khai tiếp cận được qua cả hai mạch là một dịch vụ định tuyến, không phải một ô đánh dấu trong VPN. Nó cần không gian địa chỉ mà cả hai nhà cung cấp sẵn sàng mang, được công bố theo cách mạng của họ chấp nhận, và đó là điều mà đa kết nối với không gian độc lập nhà cung cấp và BGP mang lại. Gán địa chỉ của ISP A cho giao diện của ISP B không đưa bạn đến đó; gói tin đến một mạng chưa bao giờ công bố tiền tố đó và bị loại bỏ ở phía trên.

Bạn không cần gì trong số này để công bố hai mục. Nếu máy khách giữ được hai tên và chuyển đổi giữa chúng, hai mục độc lập là đủ, và bạn tránh được số AS, thỏa thuận peering và một tiền tố phải được chấp nhận ở mọi nơi. Chỉ cân nhắc tùy chọn địa chỉ di động khi bạn thực sự cần một điểm vào ổn định mà máy khách không thể bị cấu hình lại để thay thế, hoặc khi chuyển đổi dự phòng dựa trên DNS với độ trễ TTL quá chậm cho sự cố bạn đang thiết kế.

Cần kiểm tra gì tiếp theo

Làm việc từ trong ra ngoài từ mục đang hỏng theo thứ tự này: địa chỉ thứ hai có trả lời từ bên ngoài không, nó có trình bày danh tính mà máy khách mong đợi không, câu trả lời có đi ra theo đường mà yêu cầu đã vào không, và máy khách có biết tên trước khi cần không. Ở đâu câu trả lời là không, hãy sửa lớp đó và kiểm tra lại với hồ sơ đã triển khai chứ không phải máy chủ thử nghiệm, vì một bắt tay từ phòng thí nghiệm chứng minh ít hơn một kết nối hoàn tất từ máy khách thật.

Giữ một bản ghi ngắn cho mỗi WAN, với địa chỉ, cổng, giao diện kết thúc, tên chứng chỉ, đường trả về và quy tắc dịch, và kiểm tra lại mỗi khi một mạch, một thiết bị NAT hoặc một phiên bản máy khách thay đổi. Những đường dự phòng không dùng âm thầm mục ruỗng: không có gì cảnh báo về mục mà không ai dùng cho đến ngày mọi người phụ thuộc vào nó.