Ping từ cổng IPsec dùng một địa chỉ nguồn khác

Ping sang phía xa từ cổng IPsec, không nhận được trả lời và kết luận đường hầm hỏng, trong khi mọi khối lượng công việc sau cổng vẫn truyền lưu lượng bình thường. Hai kết quả đó không mâu thuẫn. Ping khởi chạy trên cổng là gói có nguồn cục bộ, và cổng chọn địa chỉ nguồn từ bảng định tuyến của chính nó. Lựa chọn đó có thể khác với các địa chỉ mà lưu lượng thật của site dùng, điều này thay đổi chính sách nào khớp và đường về nào áp dụng. Hãy quyết định phép thử phải chứng minh điều gì trước khi đọc bất cứ điều gì từ kết quả.

Ba câu hỏi khác nhau mà ping có thể trả lời

Câu hỏi thứ nhất là phía xa có thể tiếp cận được từ máy này hay không. Thứ hai là các selector của đường hầm hoặc chính sách dựa trên tuyến có chấp nhận lưu lượng từ một nguồn nhất định hay không. Thứ ba là lưu lượng được chuyển tiếp từ một khối lượng công việc sau cổng có hoạt động từ đầu đến cuối hay không. Một lệnh không thể trả lời cả ba, và địa chỉ nguồn là thứ phân biệt chúng.

Chọn câu hỏi trước. Nếu không, một ping thất bại sẽ trở thành bằng chứng cho giả thuyết bạn đã có.

Vì sao cổng chọn một địa chỉ bạn không ngờ

Khi bạn ping một đích, ngăn xếp cục bộ chọn nguồn từ tuyến khớp với nó. Trên đường hầm dựa trên tuyến, đó có thể là địa chỉ liên kết của giao diện đường hầm, mà trong nhiều thiết kế site là cặp 169.254.x.x được chọn cho bước nhảy điểm-tới-điểm. Những địa chỉ đó tồn tại để liên kết hoạt động; chúng không được quảng bá như mạng nguồn ứng dụng ở phía xa.

Vì vậy phía xa có thể nhận được yêu cầu echo từ một địa chỉ mà nó không có tuyến về, hoặc từ một địa chỉ không selector nào khớp. Đường hầm có thể khỏe mạnh mà ping vẫn thất bại, và đó chính là âm tính giả mà bài viết này bàn tới.

Chọn nguồn một cách có chủ đích

Trên một cổng Linux được kiểm soát, chọn nguồn đã được gán cục bộ: ping -c 4 -I 10.30.0.1 10.40.0.20. Các địa chỉ ở đây chỉ là ví dụ, nên hãy thay bằng địa chỉ bên trong thật của cổng và một đích xa thật, rồi xác nhận nguồn bạn chọn thuộc thiết bị này và được chính sách của site chấp nhận.

Đừng mượn địa chỉ của một khối lượng công việc cho phép thử. Giả làm một máy không được gán cho cổng tạo ra kết quả không ai tái lập được, và trên một số ngăn xếp nó thất bại theo cách trông như lỗi đường hầm.

Đọc đường về, không chỉ yêu cầu

Kiểm tra nguồn nào thực sự đến đích xa, kể cả mọi phép dịch có chủ đích trên đường. Sau đó kiểm tra tuyến về của phía xa tới nguồn đó và các selector hoặc chính sách cho phép nó. Một yêu cầu đến với nguồn bất ngờ là vấn đề định tuyến và chính sách, không phải mật mã.

Ở đây bắt gói cũng giúp nhiều hơn một lần ping nữa: nó cho thấy nguồn mà phía xa đã thấy, và đó là địa chỉ mà trả lời của nó phải tới.

Sau đó kiểm tra khối lượng công việc

Phép thử quyết định là ping từ một máy bình thường sau cổng tới một máy bình thường sau cổng xa. Nó rèn luyện vai trò chuyển tiếp của cổng, nguồn ứng dụng thật và đường về thật, đó là luồng mà người dùng quan tâm.

Giữ các kết quả riêng trong ghi chú của bạn: khả năng tiếp cận từ cổng, sự chấp nhận của chính sách cho nguồn được chọn, và lưu lượng được chuyển tiếp. Một ping được ghim thành công là bằng chứng hữu ích rằng đường hầm có mang thứ gì đó; nó không phải bằng chứng rằng mọi luồng được chuyển tiếp đều hoạt động. Và một nguồn cổng được chọn tự động mà không tiếp cận được không phải bằng chứng rằng đường hầm của site đã chết.

Đừng thêm một tuyến bao quát cho 169.254.0.0/16 chỉ để có một câu trả lời chẩn đoán. Điều đó đánh đổi một phép thử gây nhầm lẫn lấy một quyết định định tuyến vĩnh viễn, và người tiếp theo thừa hưởng nó mà không có ngữ cảnh.