Ứng dụng khách của bạn báo đã kết nối trong khi giao diện vẫn bật và trình duyệt hết thời gian chờ, và không câu nào trong ba câu đó là sai. Đã kết nối mô tả một lớp không liên quan gì đến trang bạn đã yêu cầu. Để quyết định lớp nào đang báo cáo cần một yêu cầu mới và một lần nhìn vào bộ đếm thứ sẽ chứng minh lưu lượng đã di chuyển. Khởi động lại ném bỏ bằng chứng đó và dựng lại những điều kiện bạn đang cố quan sát.

Ba thứ khác nhau được gọi là đã kết nối

Ở dưới cùng, đã kết nối có thể nghĩa là một tiến trình khách đang chạy và giữ một ổ cắm về phía đối tác. Trên đó, nó có thể nghĩa là tồn tại một giao diện có địa chỉ, mà một thiết bị thường trú hoặc một quy trình khôi phục có thể tạo ra mà không có phiên sống phía sau. Ở mức điều khiển, nó có thể nghĩa là một liên kết đã được thương lượng, điều đó không nói gì về việc liệu một gói tin có đi qua bên dưới nó hay không. Mỗi thứ trong số đó chịu được những hỏng hóc mà các thứ khác không chịu được, và ứng dụng khách thường hiển thị thứ mạnh nhất mà nó có thể tuyên bố.

Vì vậy biểu tượng xanh và đường hầm chết tương thích chứ không mâu thuẫn; chúng báo cáo về những đối tượng khác nhau. Đó là toàn bộ lý do khiến lỗi này liên tục bị chẩn đoán sai là lỗi của ứng dụng khách.

Hãy gửi một yêu cầu vô hại đến một đích mà bạn thực sự cần trước khi chạm vào daemon, và giữ khối lưu lượng trực tiếp bắt buộc tại chỗ trong khi bạn làm việc. Khởi động lại xóa mất thứ tự các sự kiện rồi tạo lại chúng đủ gần để che giấu nguyên nhân, vì thế cùng một phiếu yêu cầu quay lại sau một tuần mà không có gì mới trong đó. Một yêu cầu, một lần đọc bộ đếm và tác nhân đã tạo ra lỗi là bằng chứng tối thiểu.

Bộ đếm nào chứng minh các gói tin đã di chuyển

Trong IPsec, liên kết IKE và liên kết CHILD là những đối tượng riêng biệt, và chỉ child mang các bộ đếm trả lời câu hỏi này. Hãy liệt kê child, theo dõi xem các gói tin có tăng ở cả hai chiều không, và so sánh với điều ứng dụng đang cố làm. Một liên kết được cài đặt ở mức không là một phát hiện khác với một liên kết đang tăng trong khi ứng dụng vẫn thất bại; cái đầu nghĩa là lưu lượng không được chọn, cái sau nghĩa là nó đang di chuyển và lỗi nằm xa hơn. Đọc bộ đếm hai lần, cách nhau vài giây, vì một mẫu không thể cho thấy xu hướng.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Bộ đếm bằng không chỉ vào việc chọn lựa: định tuyến, chính sách, không gian tên mà gói tin đi ra, hoặc một giao diện mà ứng dụng khách chưa bao giờ gắn vào. Bộ đếm tăng chỉ ra xa đường hầm, vì thế hãy tiếp tục với chuyển tiếp ở đầu xa, phân giải tên, đường về và dịch vụ đích, theo thứ tự đó. Một giao thức không có đối tượng child riêng phơi bày cùng bằng chứng theo thuật ngữ của chính nó, vì thế hãy dùng những gì nó báo cáo về trạng thái đối tác và số gói tin thay vì mượn từ vựng của IPsec. Hình dạng của lần đọc quan trọng hơn công cụ đã tạo ra nó.

Lỗi nằm ở đâu sau khi các bộ đếm di chuyển

Một cổng kết nối trả lời trên địa chỉ quản trị của chính nó chứng minh cổng đang chạy, không chứng minh rằng có gì đó phía sau phục vụ yêu cầu của bạn, vì thế hãy kiểm tra phía xa chứ không phải chiếc hộp ở giữa. Phân giải tên che giấu hỏng hóc tốt nhất, vì một bộ phân giải không tiếp cận được qua đường hầm sẽ hết thời gian chờ giống hệt một kết nối chết. Hai lần tra cứu tách các trường hợp đó ra, và cả hai đều rẻ. Hãy hỏi bộ phân giải mà đường hầm áp đặt trước, rồi hỏi một bộ phân giải công cộng về cùng tên đó.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Một tên phân giải được qua bộ phân giải công cộng nhưng không qua bộ phân giải của đường hầm nghĩa là đường DNS đã gãy, trong khi một tên phân giải được qua cả hai mà vẫn hết thời gian chờ trong trình duyệt chỉ vào đường về hoặc dịch vụ. Nếu ping theo địa chỉ thành công mà ứng dụng vẫn từ chối, mạng đã giao yêu cầu và dịch vụ đã từ chối nó, đó là một giai đoạn muộn hơn hẳn.

Ghi lại tác nhân, rồi thay đổi một thứ

Ghi lại điều gì xảy ra trước lỗi: một quãng không hoạt động, một thay đổi mạng, một lần gia hạn khóa, một máy tính xách tay được đánh thức, hoặc một hệ thống được khôi phục. Những thứ đó tạo ra các cơ chế khác nhau, và thường chỉ hệ thống được khôi phục tự sửa mình, đó chính là trường hợp không dạy cho bạn điều gì. Khởi động lại loại bỏ thứ tự các sự kiện rồi tạo lại những điều kiện đủ gần để che giấu nguyên nhân. Hãy viết tác nhân xuống trong khi nó còn tái hiện được.

Sau đó hãy làm một sửa chữa có căn cứ và lặp lại yêu cầu ban đầu cùng với tác nhân đã tạo ra lỗi. Không hoạt động là tác nhân dễ tái hiện nhất, nên đó là xác nhận nhanh nhất rằng bản sửa đã xử lý cơ chế chứ không phải triệu chứng.

Điều bạn muốn báo cáo là bằng chứng rằng lưu lượng bạn định gửi đã đến dịch vụ bạn định đến. Một biểu tượng chuyển xanh, một trang trong bộ nhớ đệm tải được và một bộ đếm di chuyển đều chứng minh ít hơn một yêu cầu hoàn tất tới đích đã định. Hãy giữ yêu cầu, lần đọc bộ đếm và tác nhân lại với nhau, để người tiếp theo có thể phân biệt một bản sửa với một sự trùng hợp.

Bài viết liên quan