Vì sao traceroute chết một chiều qua đường hầm VPN

Kết quả traceroute hoàn tất ở một chiều và in các hàng dấu sao ở chiều kia trông giống chuyển tiếp bất đối xứng, và thường không phải vậy. Mỗi bước nhảy hiển thị cần gói dò đến nơi, một router quyết định trả lời và câu trả lời quay về rồi khớp với gói dò. Đứt bất kỳ mắt xích nào trong số đó và hàng biến thành dấu sao trong khi đường hầm vẫn chở dữ liệu.

Vết là bằng chứng về chẩn đoán trước khi là bằng chứng về vận chuyển. Câu hỏi đáng đặt ra là mắt xích nào trong ba mắt xích đã hỏng, và câu trả lời đến từ các gói tin, không phải từ hình dạng đầu ra.

Dấu sao là câu trả lời thiếu, không phải bước nhảy thiếu

Traceroute đi ra ngoài bằng cách gửi các gói dò có TTL hết hạn ở một router xa hơn mỗi vòng. Router loại bỏ gói dò đã hết hạn đáng lẽ phải trả về thông điệp ICMP Time Exceeded tự nêu tên mình, và công cụ in tên đó. Điều công cụ thực sự chờ là thông điệp đó đến trong một giới hạn thời gian. Nếu router trả lời từ địa chỉ nguồn khác, giới hạn tần suất tạo lỗi hoặc bỏ gói dò mà không nói gì, vòng đó không tạo ra gì in được.

Không kết quả nào trong số đó nói rằng đường đi phía trước bị hỏng. Dấu sao là báo cáo về thư không được trả lời, không phải về con đường trống.

Phương thức gói dò quyết định bạn gặp bộ lọc nào

Phương thức mặc định trên Linux thường là cổng đích UDP số cao, tracert trên Windows gửi tiếng vọng ICMP, và Linux có thể được yêu cầu dùng ICMP hoặc TCP thay thế. Mỗi cách trông như một loại lưu lượng khác đối với tường lửa có trạng thái hoặc nhóm bảo mật trên đám mây. So sánh một vết UDP từ một phía với một vết ICMP từ phía kia là so sánh hai thí nghiệm khác nhau. Cố định phương thức, họ địa chỉ, địa chỉ nguồn và giới hạn thời gian trước khi gọi kết quả là khác biệt.

Để so sánh công bằng, chạy vết từ các máy thực sự chở lưu lượng chứ không phải từ một cổng chuyển tiếp thay chúng. Một vết do router tạo ra dùng địa chỉ nguồn và chính sách đầu ra của chính router, có thể nghiêm hơn bất cứ điều gì máy khách thấy. Ghi lại lệnh chính xác để người sau có thể lặp lại.

Giá trị giới hạn thời gian là nửa còn lại của thí nghiệm, và rất dễ bỏ sót trong ghi chú. Chờ hai giây trên đường tắc nghẽn báo dấu sao trong khi chờ năm giây báo bước nhảy ở cùng chỗ. Giữ giá trị giống nhau trong mọi lần chạy để phép so sánh vẫn nói về mạng.

Đường về là một tuyến riêng

Lỗi ICMP là một gói bình thường có nguồn và đích riêng, và nó cần một tuyến quay lại trình theo dõi. Nếu chính sách đường hầm mang các tiền tố LAN nhưng không mang địa chỉ router đã tạo lỗi, thông điệp đi ra theo một đường không thể đến bạn. Lọc câu trả lời có thể bỏ nó ngay cả khi tuyến tồn tại, vì gói đến từ địa chỉ bất ngờ trên giao diện bất ngờ. Đó là sự không khớp trong mặt phẳng chẩn đoán chứ không phải lỗi ứng dụng.

Mở rộng mọi bộ chọn cho đến khi vết hoàn tất làm bức tranh đẹp hơn và chính sách tệ hơn. Sửa địa chỉ chẩn đoán cụ thể, hoặc chấp nhận dấu sao và thử ứng dụng theo cách khác.

Xác nhận đường hầm bằng một yêu cầu thật

Một cái bắt tay TCP trên cổng riêng của dịch vụ kiểm tra chuyển tiếp, định tuyến quay về và lọc theo chiều quan trọng. Các lệnh dưới đây chạy ở cả hai đầu và so sánh mỗi bên mở được gì. Thay cổng dịch vụ và tên giao diện đường hầm bằng cấu hình của bạn.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Đọc hai lần chạy traceroute trước: nếu lần chạy ICMP hiện các bước nhảy còn lần chạy TCP thì không, khác biệt là phương thức chứ không phải đường đi. Sau đó lấy kết quả curl làm câu trả lời ở mức ứng dụng, vì một trao đổi hoàn tất với mã trạng thái hợp lý nghĩa là cả đường đi lẫn đường về đều hoạt động với lưu lượng thật. Danh sách socket cho biết kết nối có được thiết lập hay không, điều mà không vết nào nói được.

Một đường hầm chở phiên tương tác cả hai chiều trong khi một traceroute in dấu sao là khỏe mạnh và chỉ kém ăn ảnh. Giữ đầu ra lệnh của mỗi bên làm bản ghi, và coi các bước nhảy thiếu là câu hỏi mở về chẩn đoán chứ không phải phán quyết về VPN.