Chuyển hướng ICMP so với các tuyến VPN của bạn: điều gì thực sự thay đổi

Một luồng lẽ ra phải đi qua đường hầm lại chọn một chặng kế tiếp khác, và ai đó tìm thấy một chuyển hướng ICMP trong bản bắt gói. Đó là giả thuyết, không phải chẩn đoán. Chuyển hướng là gợi ý của bộ định tuyến về một chặng kế tiếp tốt hơn, và việc máy chủ có hành động theo hay không phụ thuộc vào các thiết lập khác nhau theo nền tảng, theo giao diện và theo họ địa chỉ.

Chuyển hướng là một gợi ý từ bộ định tuyến

Chuyển hướng ICMP IPv4 có kiểu thông điệp riêng và một tập điều kiện hẹp: bộ định tuyến chuyển gói ra khỏi đúng giao diện mà nó đi vào, và biết trên cùng liên kết đó một chặng kế tiếp gần đích hơn. Sau đó nó bảo bên gửi dùng trực tiếp chặng đó. Thông điệp nêu tên cổng mới và kèm một phần gói gốc để bên gửi có thể khớp nó với một luồng. Đây là thông điệp lịch sự về cấu trúc liên kết cục bộ, và nó giả định bên gửi dùng chung liên kết với cổng được đề xuất.

Bên gửi có quyền bỏ qua nó. Giao thức không buộc máy chủ phải đổi bảng của mình, và một chuyển hướng bắt được chỉ chứng minh rằng một bộ định tuyến đã gửi nó.

Hầu hết các cuộc điều tra chuyển hướng sai chính ở sự phân biệt này.

IPv4 và IPv6 phân phối nó khác nhau

IPv6 có cơ chế tương tự nằm trong phần phát hiện láng giềng chứ không phải trong ICMPv4, với định dạng thông điệp và quy tắc kiểm tra khác. Các khái niệm vần nhau, các gói thì không. Một bộ lọc bắt gói viết cho kiểu ICMP 5 sẽ không hiển thị gì trên mạng IPv6, và điều đó đôi khi bị đọc thành bằng chứng rằng không có chuyển hướng nào xảy ra.

Các nút chính sách cũng tách riêng, nên máy chủ có thể chấp nhận chuyển hướng IPv4 và bỏ qua IPv6, hoặc ngược lại.

Hãy kiểm tra cả hai họ nếu luồng đang xét có thể dùng một trong hai.

Chấp nhận là chính sách của máy chủ, không phải sự thật của mạng

Trên Linux, việc chấp nhận chuyển hướng được kiểm soát theo từng giao diện và trên toàn cục, và giá trị mặc định khác nhau giữa vai trò máy chủ và vai trò bộ định tuyến. Một giao diện đường hầm chấp nhận chuyển hướng là thiết kế lạ, vì trong đường hầm điểm-điểm không có chặng kế tiếp thay thế nào có ý nghĩa trên cùng liên kết. Vì vậy thiết lập này đáng đọc chứ không nên giả định.

Các thiết lập chuyển hướng an toàn còn hạn chế thêm những cổng nào được tin.

Nếu bạn đang siết chặt một máy chủ, đó là những nút cần xem lại, và chúng cũng là lý do hai máy trong cùng mạng có thể hành xử khác nhau. Hãy đổi chúng như chính sách, không phải như lối tắt gỡ lỗi.

Điều chuyển hướng không thể giải thích

Các tuyến cụ thể, quy tắc định tuyến theo chính sách và giao diện cục bộ giải thích phần lớn đường đi bất ngờ mà không cần bất kỳ chuyển hướng nào. Một tiền tố cụ thể hơn, một quy tắc khớp với địa chỉ nguồn, hoặc một mặc định thứ hai trong bảng khác mỗi thứ trong số đó sẽ lấn át tuyến bạn mong đợi. Hãy kiểm tra chúng trước, vì chúng mang tính xác định và nhìn thấy được.

Bản bắt gói cũ là cái bẫy khác, vì một máy khách đã đổi mạng có cổng cục bộ khác.

Một chuyển hướng cũ từ lần kết nối trước không giải thích gì về đường đi hiện tại, nên hãy ghi lại giao diện nào đang nhận lưu lượng điều khiển.

Kiểm tra tuyến trước khi đổ lỗi cho đường hầm

Hỏi nhân hệ điều hành xem nó sẽ dùng tuyến nào cho đích, rồi so với bảng mà bạn dự định. Nếu câu trả lời khớp với bảng, không chuyển hướng nào đã thay đổi điều gì và cuộc điều tra thuộc nơi khác. Nếu không khớp, trước khi cho rằng đường hầm có lỗi, hãy tìm một chuyển hướng đã lưu trong bộ nhớ đệm, một quy tắc chính sách hoặc một bảng thứ hai. Việc tra tuyến là sự thật nền tảng, còn mọi thứ khác là câu chuyện về cách nó trở nên như vậy.

Chuyển hướng không bao giờ được là lý do khiến một đường đi được bảo vệ âm thầm thành không được bảo vệ, nên chính sách chấp nhận thuộc về phần đánh giá thiết kế. Định nghĩa trong RFC 792 vẫn là tài liệu tham chiếu cho những gì thông điệp IPv4 được phép nói.

Hãy ghi kết quả tra tuyến và dấu thời gian của bản bắt gói cùng nhau, và người tiếp theo có thể tái tạo kết luận của bạn.