Linux EHOSTUNREACH với OpenVPN: chặng kế tiếp nào đã thất bại?

EHOSTUNREACH thường là quyết định cục bộ không kém gì một thất bại từ xa. Nhân có thể từ chối gói tin vì một tuyến nói đích đến là unreachable, vì chặng kế tiếp Ethernet không bao giờ trả lời, hoặc vì một báo cáo ICMP host-unreachable đến từ xa hơn trên đường. Mỗi nguồn sống trong một bảng hoặc bộ nhớ đệm khác nhau, và mỗi nguồn được sửa ở một chỗ khác. Hãy đọc tuyến đã chọn và trạng thái chặng kế tiếp trước khi chạm vào mật mã hoặc cài lại đường hầm.

Chọn địa chỉ và namespace mà máy khách thực sự dùng

Bắt đầu bằng việc ghim đích đến và namespace mạng đã tạo ra lỗi. Một máy khách VPN có thể chạy trong namespace riêng, và tra cứu từ namespace mặc định sẽ dùng một bảng định tuyến khác với các quy tắc chính sách khác.

Tra cứu phải dùng cùng nguồn, mark và ngữ cảnh bảng như ứng dụng đang lỗi, nếu không nó có thể trả lời một câu hỏi không ai đặt ra. Với một peer IPv4 minh họa, các kiểm tra chỉ đọc là:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Kết quả từ một shell quản trị chỉ chứng minh điều shell đó sẽ làm. Nếu máy khách đặt firewall mark hoặc gắn vào VRF, hãy lặp lại tra cứu với mark tương ứng hoặc bên trong VRF, rồi so sánh tuyến đã chọn và chặng kế tiếp. Địa chỉ đầu tiên cần xác nhận là địa chỉ peer trong hồ sơ, không phải cụm hay dịch vụ mà người dùng nêu tên.

Một tuyến unreachable rõ ràng từ chối gói tin ngay tại máy

Tuyến loại unreachable là một câu trả lời cục bộ có chủ đích. Nó bảo nhân bỏ gói tin và trả EHOSTUNREACH cho người gửi, đó là lý do lỗi xuất hiện tức thì và không có lưu lượng nào rời khỏi máy. Ai đó, hoặc một tự động hóa nào đó, đã đặt tuyến ấy ở đó có chủ đích.

Các loại tuyến không thay thế được cho nhau. blackhole bỏ gói tin mà không báo lỗi cho người gửi, prohibit trả EACCES, còn unreachable trả EHOSTUNREACH. Một trợ lý VPN cài tuyến sink khi kết nối lại do đó có thể tạo ra một loạt lỗi host-unreachable biến mất khi đường hầm lên, trong khi tuyến blackhole sẽ tạo ra các lần hết giờ im lặng thay vào đó.

Hãy tìm loại đó trong mọi bảng trước khi đổ lỗi cho đầu xa. Quy tắc chọn bảng quan trọng ngang với tuyến bên trong nó, và một tuyến thêm vào bảng chính sẽ không giúp ích cho máy khách mà quy tắc chính sách đẩy lưu lượng đi nơi khác.

Một hàng xóm đã chết tạo ra đúng lỗi đó trên Ethernet

Khi tuyến đã chọn dùng một cổng vào on-link, việc gửi cần một địa chỉ tầng liên kết đã phân giải. Nhân gửi ARP hoặc yêu cầu hàng xóm IPv6, và nếu không có trả lời thì gói tin không thể đóng khung. Việc gửi sau đó thất bại với EHOSTUNREACH dù bản thân tuyến vẫn hợp lệ.

Bảng hàng xóm đặt tên cho giai đoạn. INCOMPLETE nghĩa là việc phân giải vẫn đang diễn ra, FAILED nghĩa là lần thử cuối không nhận được trả lời, còn REACHABLE hoặc STALE nghĩa là nhân có một địa chỉ dùng được. Một mục FAILED cho cổng vào VPN là vấn đề gửi cục bộ, không phải bằng chứng về phía xa của đường hầm.

Hãy đọc mục cho chặng kế tiếp thật sự, không phải cho địa chỉ internet xa. Địa chỉ xa thường được đến qua một router, nên nó sẽ không có bản ghi ARP riêng; hỏi xin một bản ghi như vậy là lỗi phân loại khiến người ta đi tìm một mục thiếu lẽ ra không bao giờ tồn tại.

Báo cáo từ xa và lỗi UDP không đồng bộ

EHOSTUNREACH cũng có thể đến từ bên ngoài. Một router không chuyển tiếp được gói tin có thể gửi ICMP host unreachable, và nhân chuyển báo cáo đó cho socket sở hữu luồng. Khi đó tuyến và hàng xóm đều ổn, và thất bại thuộc về một chặng ngoài mạng cục bộ.

UDP khiến việc quy trách nhiệm khó hơn. Một lỗi do lệnh gọi send hoặc receive sau trả về có thể liên quan đến một datagram trước đó, nên địa chỉ và thời điểm của lệnh gọi thất bại có thể không khớp với gói tin đã kích hoạt báo cáo. Một socket UDP đã kết nối nhận lỗi một lần, còn socket chưa kết nối có thể không bao giờ thấy nó.

Đó là lý do thời điểm thuộc về bằng chứng. Ghi lại lỗi xuất hiện khi nào, socket dùng địa chỉ peer nào và đường hầm có vừa kết nối lại không. Một loạt lỗi ngay sau khi đổi tuyến chỉ vào bảng cục bộ; một lỗi đơn lẻ sau vài phút luồng ổn định chỉ vào một báo cáo từ đường đi.

Hãy tách các tầng trước khi thay đổi mật mã

Ba câu hỏi phân loại lỗi. Nhân có chọn một tuyến từ chối đích đến không? Nó có chọn tuyến hợp lệ nhưng không phân giải được chặng kế tiếp không? Hay một báo cáo đến từ ngoài mạng cục bộ? Chỉ trường hợp thứ ba mới có thể liên quan đến đầu xa của đường hầm, và ngay cả khi đó cũng không liên quan đến mã hóa.

Các vấn đề xác thực và thương lượng hiện ra như lỗi riêng của chúng sau khi vận chuyển đến được peer. Đổi một cipher hoặc cài lại máy khách không thể sửa một tuyến unreachable cục bộ, và nó phá hủy bằng chứng về tuyến và hàng xóm mà bạn sẽ cần cho nguyên nhân thật.

Ghi lại đích đến, namespace, bảng đã chọn, chặng kế tiếp, trạng thái hàng xóm và thời điểm lỗi trước thay đổi đầu tiên. Chạy lại đúng tra cứu đó sau khi sửa; một tuyến giờ trỏ vào đường hầm và một mục hàng xóm giờ phân giải được là bằng chứng mạnh hơn một ping thành công tới một địa chỉ không liên quan.