Khi các tuyến của tunnel chia tách chồng lấn: tiền tố nào thắng

Hai cấu hình tunnel chia tách, hai tiền tố riêng và một máy chủ mà cả hai đều nhận. Triệu chứng hiếm khi là một lỗi gọn gàng: một dịch vụ chạy vào thứ Hai, hết thời gian chờ sau khi máy khách thứ hai kết nối lại và chạy lại sau khi khởi động lại. Thứ tự bạn kết nối các máy khách không quyết định kết quả, và thứ tự các hàng trong giao diện máy khách cũng vậy. Hãy thực hiện các kiểm tra này theo thứ tự, và dừng ở kiểm tra đầu tiên không đúng, vì những kiểm tra sau chỉ có nghĩa khi những kiểm tra trước là đúng.

1. Ghi lại đích đến và nguồn

Bắt đầu từ địa chỉ chính xác mà yêu cầu thất bại gửi đến, không phải tên máy chủ và không phải tên ứng dụng. Phân giải tên một lần, ghi lại mọi câu trả lời và chọn câu trả lời mà luồng thất bại thực sự dùng. Sau đó ghi lại địa chỉ cục bộ của cùng luồng đó, vì địa chỉ nguồn có thể thay đổi quy tắc chính sách nào khớp và do đó bảng nào được xem.

Một yêu cầu đến một trong nhiều bản ghi A có thể thất bại trong khi địa chỉ anh em thành công, điều này trông giống tunnel không ổn định nhưng thực ra là hai đường khác nhau. Nếu đích là tên có nhiều câu trả lời, hãy thử từng câu trả lời riêng trước khi thay đổi bất cứ điều gì.

2. Hỏi hạt nhân xem nó đã chọn tuyến nào

Đừng đọc bảng tuyến rồi suy ra câu trả lời. Hãy đặt đúng câu hỏi mà ngăn xếp đặt, với cùng địa chỉ nguồn: ip route get 10.20.4.10 from 10.8.0.2 trên Linux, hoặc Find-NetRoute -RemoteIPAddress 10.20.4.10 trong PowerShell. Kết quả nêu tên tuyến thực sự sẽ được dùng, và đó thường không phải tuyến bạn mong đợi khi đọc bảng.

Trong các tuyến khớp nhau, tiền tố cụ thể hơn thường thắng: /24 thắng /16 cho một địa chỉ nằm trong cả hai. Giữa các khớp cùng độ dài, chỉ số thấp hơn thắng, và tuyến được cài trên một liên kết đang xuống sẽ bị bỏ qua. Hai tunnel đẩy cùng /24 với cùng chỉ số là trường hợp khác: hạt nhân giữ cả hai tuyến và chọn giữa chúng, nên kết quả có thể luân phiên thay vì theo thứ tự các máy khách đã kết nối. Đây chính là tình huống tạo ra kiểu thứ-Hai-chạy-thứ-Ba-hỏng, và kết nối lại theo thứ tự khác không thay đổi điều đó.

3. Kiểm tra xem một quy tắc chính sách có chuyển hướng việc tra cứu không

Trước khi bảng tuyến được xem, hạt nhân đi qua các quy tắc chính sách của nó. Một quy tắc có thể gửi lưu lượng từ một nguồn, người dùng hoặc dấu tường lửa nhất định đến một bảng hoàn toàn khác, nên tiền tố thắng trong bảng chính có thể không bao giờ được xem cho luồng đó. ip rule show liệt kê chúng theo thứ tự đánh giá, và ip route show table 100 cho thấy bảng đã chọn thực sự chứa gì.

Ở đây có hai cái bẫy. Một quy tắc trỏ đến bảng rỗng tạo ra một tra cứu rơi xuống quy tắc tiếp theo, nên quy tắc trông như không làm gì. Cái còn lại là chính con số ưu tiên: các quy tắc được đọc theo thứ tự tăng dần, và các giá trị tích hợp là 0 local, 32766 main và 32767 default. Một quy tắc có số dưới 32767 được xem trước quy tắc mặc định bắt tất cả. Một quy tắc có số trên 32767 nằm sau nó và chỉ đạt tới khi không bảng nào trước đó trả lời, điều mà một tuyến mặc định bình thường trong main ngăn lại, nên trên thực tế nó không bao giờ được đạt tới và âm thầm không làm gì trong khi trông như đã được cài. Nếu máy khách đã viết một quy tắc và một tuyến, hãy kiểm tra cả hai, và kiểm tra lại sau khi kết nối lại, vì một cấu hình bị ghi lại có thể thêm quy tắc thứ hai với ưu tiên khác.

4. Tách hòa tuyến khỏi một kế hoạch địa chỉ bị trùng

Đôi khi tiền tố hoàn toàn không phải vấn đề. Hai site đều dùng 192.168.1.0/24 nghĩa là cùng một địa chỉ định danh hai máy chủ khác nhau, và không tuyến nào phân biệt được chúng. Một tuyến máy chủ đến một trong hai câu trả lời chỉ hoạt động cho đến khi site kia trả lời cho cùng tên đó, và sau đó ngoại lệ âm thầm trở thành chính lỗi.

Dấu hiệu là địa chỉ đích giống nhau trên cả hai đường và chỉ chủ sở hữu dự định là khác. Đây là quyết định về kế hoạch địa chỉ, không phải tinh chỉnh định tuyến: đánh số lại một bên, đặt một bên sau một cổng chuyển đổi, hoặc đến site thứ hai qua một proxy tự phân giải tên của nó. Hạ thấp một tuyến mặc định hoặc chồng các ngoại lệ máy chủ chỉ di chuyển va chạm đi chỗ khác.

5. Xác nhận rằng trình phân giải đồng ý với tuyến

Một tên phân giải thành địa chỉ riêng sai tạo ra mọi triệu chứng của xung đột định tuyến và không một nguyên nhân nào của nó. So sánh câu trả lời mà máy chủ nhận được với địa chỉ mà đích thực sự dùng, và kiểm tra trình phân giải nào đã trả lời. Nếu tunnel đẩy một trình phân giải, máy khách nên cài nó cho các luồng dùng tunnel; nếu không, máy chủ tiếp tục hỏi trình phân giải cục bộ, có thể trả lời từ miền tìm kiếm hoặc bản ghi đã lưu đệm.

Hỏi trực tiếp trình phân giải và ghi lại máy chủ đã trả lời. Một câu trả lời lưu đệm với TTL ngắn cũng có thể giải thích vì sao yêu cầu đầu tiên sau khi kết nối lại hành xử khác với yêu cầu thứ năm.

6. Kết nối lại, kiểm tra trạng thái đã áp dụng, rồi kiểm thử cả hai luồng

Sau khi sửa, hãy kết nối lại và kiểm tra xem máy khách thực sự đã cài gì thay vì tin vào trình soạn cấu hình. Đọc lại các quy tắc, các bảng và câu trả lời ip route get thu được. Một máy khách thứ hai có thể cài lại tuyến của chính nó khi kết nối và tạo lại xung đột, vì vậy việc kiểm tra trạng thái phải diễn ra sau khi máy khách cuối cùng kết nối, không phải trước đó.

Kiểm thử hai luồng, không phải một: yêu cầu từng thất bại, và một tài nguyên đáng lẽ dùng tunnel kia. Chuyển toàn bộ lưu lượng riêng sang một kết nối sẽ làm bài kiểm thử đầu tiên qua trong khi phá bài thứ hai, và chỉ một bài kiểm thử ghép đôi mới bắt được điều đó. Ghi lại từng ngoại lệ bạn giữ, kèm đích và lý do, để người tiếp theo phân biệt được một tuyến máy chủ cố ý với một tuyến còn sót.