Kiểm tra kill switch: đo khoảng trống, không chỉ kết nối lại

Một lần kết nối lại xong trong một giây cho bạn biết máy khách nhanh. Nó không cho biết có gì lọt ra trong khi đường hầm tắt. Một lần kết nối lại mất một phút cho bạn biết máy khách chậm, và vẫn không cho biết lưu lượng trực tiếp có được phép trong khoảng trống hay không. Đó là hai phép đo, và một bài kiểm tra kill switch chỉ báo cáo phép đo đầu tiên thì chưa kiểm tra công tắc.

Hai quan sát, hai phán quyết riêng

Câu hỏi về tính sẵn sàng rất đơn giản: đường hầm trở lại dùng được khi nào, và ứng dụng được bảo vệ có cần kết nối mới để đến đó không. Câu hỏi về việc thực thi thì khác: những gói tin nào rời máy từ lúc bảo vệ mất đi đến lúc nó trở lại.

Trả lời chúng bằng các bản ghi riêng. Một dòng nói khoảng trống kéo dài bao nhiêu giây. Một dòng khác nói liệu một yêu cầu không được bảo vệ có thành công trong khoảng trống đó không. Gộp chúng thành một đạt hay trượt duy nhất sẽ che mất trường hợp quan trọng nhất: kết nối lại nhanh mà vẫn rò rỉ.

Dựng một đầu dò có thể đo thời gian

Dùng một yêu cầu vô hại, rẻ và độc lập với kênh điều khiển của chính đường hầm. Vòng lặp bên dưới in dấu thời gian, trạng thái HTTP và thời gian đã trôi qua mỗi giây một lần, và nó thất bại ồn ào thay vì treo:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Đọc mã thoát của curl, không chỉ trạng thái. 28 nghĩa là yêu cầu hết thời gian, đó là hình dạng của một đường bị chặn. 6 nghĩa là phân giải tên thất bại, đây là một phát hiện khác và thường thú vị hơn. 200 với thời gian trôi qua ngắn trong khoảng trống nghĩa là lưu lượng được phép đi ra.

Ghi đầu ra vào một tệp và giữ lại. Lịch sử cuộn của terminal không phải bằng chứng, và phần thú vị thường là ba dòng ở giữa.

Gây ra một lỗi thật, không phải lỗi gọn gàng

Ngắt kết nối từ menu của chính máy khách kiểm tra con đường hợp tác, nơi máy khách có thời gian cài đặt các quy tắc chặn của nó. Thay vào đó hãy giết tiến trình, hoặc cắt liên kết bên dưới, và bạn kiểm tra con đường mà một lỗi thật đi qua.

Mỗi tác nhân luyện một đường mã khác nhau. Sự cố phía máy chủ, mất liên kết cục bộ và sự cố máy khách đều có thể để lại trạng thái khác nhau, và một trong số đó có thể là trường hợp bạn cuối cùng gặp phải. Chạy đầu dò với ít nhất hai tác nhân và dán nhãn kết quả theo tác nhân.

Đọc nhật ký để xem lưu lượng được phép trông như thế nào

Một 200 hoặc một lỗi kết nối nhanh trong khoảng trống là rò rỉ, dù nó chỉ về hướng nào. Hết thời gian suốt khoảng trống là hình dạng mong đợi của một chính sách chặn. Phân giải tên thành công trong khi kết nối thất bại cho thấy bộ phân giải vẫn còn với tới được, đó là một kiểu rò rỉ khác.

Các socket hiện có cần cẩn thận. Một chương trình có thể tiếp tục dùng kết nối đã mở trước khi ngắt, nên lưu lượng trông như đang sống có thể không chứng minh một con đường mới được cho phép. Danh sách socket cho thấy kết nối có cũ hơn sự kiện hay không:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

So sánh thời điểm bắt đầu của socket với dấu thời gian của lần ngắt. Một kết nối cũ hơn sự cố là bằng chứng của việc dùng lại socket, không phải rò rỉ, và báo cáo nó như một lỗi sẽ đưa người tiếp theo đi tìm một lỗi không tồn tại.

Ghi kết quả ở dạng sống sót qua một lần cập nhật

Ghi lại tác nhân, khoảng trống tính bằng giây, liệu có yêu cầu không bị chặn nào thành công, liệu phân giải tên có thành công, và phiên bản máy khách cùng hệ điều hành. Bộ năm sự kiện đó có thể so sánh giữa các bản phát hành, điều mà một đoạn văn xuôi không làm được.

Chạy lại cùng bài kiểm tra sau khi cập nhật máy khách hoặc thay đổi hồ sơ, vì hành vi chặn là chi tiết triển khai và nó dịch chuyển. Mục đích của bản ghi là nhận ra sự dịch chuyển trước khi nó thành sự cố, không phải chứng nhận máy khách một lần.