Ping không phải bằng chứng: hãy kiểm tra đường đi giữa hai site

Đường hầm đang hoạt động, các gateway trả lời lẫn nhau, vậy mà người dùng ở một site vẫn không mở được thư mục chia sẻ ở site kia. Ai đó ping từ gateway, nhận được trả lời và tuyên bố mạng khỏe mạnh. Câu trả lời đó đi giữa hai thiết bị chưa bao giờ là vấn đề. Một bài kiểm tra hữu ích bắt đầu từ máy chủ cần dịch vụ, dùng giao thức mà ứng dụng dùng và tái tạo điều kiện mà nó thất bại. Mọi thứ khác là đèn xanh cho một con đường không ai đi.

Bắt đầu từ client cần dịch vụ

Ghi lại bốn thứ trước khi kiểm tra bất cứ điều gì: địa chỉ client, địa chỉ đích, tên máy chủ và cổng của ứng dụng. Sau đó xác nhận dịch vụ hoạt động cục bộ tại site của nó, từ một máy chủ bên cạnh. Không có đường cơ sở đó, bạn không thể phân biệt đường hầm hỏng với dịch vụ hỏng, và một nửa số phiếu này là trường hợp thứ hai.

Hãy thử tên máy chủ đã ghi trong tài liệu và, nơi dịch vụ cho phép, kiểm tra địa chỉ trực tiếp của cùng cổng đó. Việc tra tên thất bại và địa chỉ đã phân giải không thể tới đưa bạn đi theo các con đường khác nhau. Nếu bạn thay tên máy chủ bằng IP, đừng tắt kiểm tra danh tính HTTPS để nó hoạt động; cảnh báo chứng chỉ là thông tin, không phải trở ngại.

Đi dọc đường tại mỗi biên

Đọc tuyến mà client chọn, rồi tuyến mà gateway chọn cho đích đó, rồi các bộ đếm hoặc một bản bắt gói giới hạn tại mỗi biên. Bạn đang tìm hai sự thật: yêu cầu có tới LAN từ xa không, và có trả lời quay về không. Bộ đếm giao diện bao gồm mọi luồng khác, nên hãy tương quan theo dấu thời gian chính xác và cặp địa chỉ thay vì hình dạng đồ thị. Bản bắt gói ở sai biên tệ hơn không có, vì nó trông như bằng chứng.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Nếu yêu cầu xuất hiện ở biên xa mà không có trả lời phía sau, vấn đề nằm ở phía bên kia: một tường lửa, một tuyến quay về bị thiếu hoặc một máy chủ không chấp nhận nguồn. Nếu yêu cầu không bao giờ xuất hiện, tuyến cục bộ hoặc các selector của đường hầm đã không mang nó đi, và phía bên kia chưa đáng để điều tra.

Dùng giao thức mà ứng dụng dùng

ICMP là một phép dò yếu. Nó có thể bị lọc, bị giới hạn tốc độ hoặc bị xử lý bởi chính sách khác với dịch vụ, khiến cả thành công lẫn thất bại của nó đều mơ hồ. Hãy kiểm tra đúng cổng và, khi có thể, đúng bắt tay giao thức.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Một bắt tay TCP hoàn tất chứng minh khả năng tới và chính sách cho cổng đó. Nó không chứng minh ứng dụng hoạt động: xác thực, tải lên hoặc một lệnh gọi API cụ thể vẫn có thể thất bại. Hãy kiểm tra thao tác mà người dùng thực sự làm, với một tương đương vô hại thay vì gửi lặp lại một giao dịch thật.

Tái tạo điều kiện thất bại

Những lỗi chỉ xuất hiện với truyền tải lớn là vấn đề kích thước, không phải kết nối. Hãy gửi một gói lớn với bit don't-fragment được đặt và xem nó dừng ở đâu. Nếu yêu cầu nhỏ thành công còn yêu cầu lớn bị treo, MTU của đường hầm và việc xử lý MSS tại các gateway là những nghi phạm tiếp theo.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Nếu chỉ một subnet thất bại, hãy xem các selector lưu lượng, quảng bá tuyến và gateway quay về của subnet đó. Nếu chỉ tên máy chủ thất bại, hãy theo DNS, bao gồm việc client dùng resolver nào và liệu góc nhìn từ xa có thấy được từ site đó không. Ba lỗi khác nhau, ba cách sửa khác nhau, và bài kiểm tra ping không phân biệt được lỗi nào.

Sau khi sửa, lặp lại đúng bài kiểm tra đó

Chạy lại đúng client, đích, cổng và tải trọng đó. Sau đó kết nối lại hoặc thử tuyến dự phòng nếu thiết kế có, vì một bản sửa chỉ hoạt động khi phiên bản đường hầm gốc còn sống thì chưa được kiểm tra. Hãy giữ bài kiểm tra gắn với nguồn thật, đích thật và thao tác thật thay vì một chỉ báo xanh trên bảng điều khiển.

Ghi lại bốn giá trị cơ sở và kết quả. Báo cáo tiếp theo về cùng triệu chứng khi đó có thể bắt đầu từ bằng chứng thay vì từ ping.