Vì sao các tuyến có chi phí bằng nhau khiến lỗi VPN khó thấy
Khi nhiều đường hầm chia sẻ cùng một chi phí, mỗi luồng có thể chọn một tuyến khác. Một ping thành công không nói gì về đường đi mà ứng dụng của bạn thực sự dùng.
Một người dùng báo rằng ứng dụng nội bộ chạy được từ máy này và hỏng từ máy khác, trong khi ping bạn chạy từ cổng vào đều thành công ở cả hai trường hợp. Với nhiều đường hầm có chi phí bằng nhau, đó không phải là mâu thuẫn. Mỗi luồng được đặt trên bước nhảy kế tiếp của riêng nó, nên phép thử của bạn và phiên của người dùng có thể chỉ đang dùng những đường khác nhau. Phần trình bày dưới đây tái tạo lựa chọn đó trước khi thay đổi bất cứ điều gì.
Một ping, nhiều đường khả dĩ
Khi một tuyến có nhiều hơn một bước nhảy kế tiếp với cùng chi phí, bộ định tuyến phải chọn một cho mỗi gói. Hầu hết các triển khai băm các trường của gói, thường là địa chỉ nguồn và đích cùng với giao thức và cổng, để các phản hồi ở lại cùng một đường. Các ứng dụng khác nhau, hay thậm chí các kết nối khác nhau của cùng một ứng dụng, tạo ra các giá trị băm khác nhau.
Đó là lý do chẩn đoán từ cổng vào chứng minh được rất ít. Phép thử của chính cổng vào có địa chỉ và cổng riêng, và do đó có giá trị băm riêng. Nó có thể rơi vào đường hầm lành trong khi người dùng vẫn rơi vào đường hầm hỏng.
Nền tảng chọn bước nhảy kế tiếp như thế nào
Hãy tái tạo lựa chọn thay vì đoán nó. Hỏi nhân hệ điều hành sẽ dùng tuyến nào cho cùng nguồn và đích như phiên đang hỏng. Tra cứu đó bao gồm các trường mà một tra cứu đích thông thường bỏ qua. Chạy nó cả từ một máy khách đang hoạt động và so sánh hai câu trả lời:
ip route get 10.20.5.7 from 10.20.0.14Các bản phát hành iproute2 mới hơn cũng chấp nhận giao thức và cổng đích, điều này quan trọng khi giá trị băm bao gồm chúng. So sánh kết quả đó với cùng tra cứu từ một máy khách đang hoạt động, và khác biệt chính là bằng chứng bạn còn thiếu.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Theo dõi luồng đang hỏng, không phải bảng định tuyến
Bảng định tuyến liệt kê cả hai đường hầm và theo định nghĩa trông có vẻ đúng. Câu hỏi là mỗi đường hầm làm gì với gói sau khi được chọn. Hãy xác minh rằng cả hai đều mang cùng các tiền tố được bảo vệ, cùng quyền chuyển tiếp và một đường quay về đến cùng máy khách.
Hãy chú ý đến các thiết bị có trạng thái ở giữa. Nếu một yêu cầu đi ra qua đường hầm này và phản hồi quay về qua đường hầm kia, một tường lửa hoặc NAT chưa từng thấy luồng gốc sẽ bỏ nó. Hai đường hầm đều chuyển tiếp lưu lượng đúng cách, và kết nối vẫn hỏng.
Cũng hãy kiểm tra MTU trên từng đường. Một đường có thêm lớp đóng gói làm giảm kích thước khả dụng, và một lần truyền thành công trên đường hầm này sẽ khựng lại trên đường hầm kia đúng ở kích thước mà đường nhỏ hơn bị vỡ.
So sánh từng đường một
Ở nơi thiết kế cho phép bảo trì, hãy đưa một đường hầm ra khỏi dịch vụ và lặp lại công việc của người dùng. Nếu lỗi biến mất, vấn đề thuộc về đường bạn đã bỏ, và bước tiếp theo là so sánh cấu hình của nó với đường bên cạnh thay vì xem lại bảng định tuyến.
Hãy so sánh ứng dụng thật, không phải những ping lặp lại. Ghi lại xem lỗi đi theo một bước nhảy kế tiếp cụ thể, một kích thước gói hay một chuyển tiếp sau khi kết nối lại, vì ba mẫu đó chỉ đến những cách sửa khác nhau.
Cuối cùng, hãy ghi lại vì sao các đường được coi là tương đương và một lỗi phải đưa một trong số chúng ra khỏi dịch vụ như thế nào. Đa tuyến chỉ an toàn khi các đường thực sự hoán đổi được cho nhau, và đó là một khẳng định thiết kế đáng để kiểm tra thay vì giả định.