Kill switch kích hoạt: điều gì xảy ra với phiên TCP đang mở?

Đường hầm sụp, kill switch kích hoạt, và một bản tải đã xong ba phần tư hoặc đứng hình hoặc thất bại ngay lập tức. Hai kết quả này đến từ những lựa chọn thực thi khác nhau, không phải từ các mức bảo vệ khác nhau. Gói bị bỏ sẽ để kết nối chờ, trong khi gói bị từ chối sẽ đóng nó và báo cho ứng dụng. Quyết định hành vi nào bạn muốn là một câu hỏi thiết kế, và kiểm tra nó là một bài tập riêng.

Bỏ, từ chối và đặt lại là khác nhau

Một quy tắc tường lửa bỏ lưu lượng sẽ ném gói đi và không gửi gì trả lại, nên bên gửi tiếp tục gửi lại theo bộ hẹn giờ của chính nó. Một quy tắc từ chối bằng TCP reset đóng kết nối ngay lập tức và ứng dụng thấy lỗi. Hầu hết kill switch đều bỏ, vì việc từ chối sẽ làm lộ chính sách và vì bỏ giống với hành vi của một mạng đã chết.

Chặn không giống với đóng socket. Ứng dụng vẫn giữ một bộ mô tả ở trạng thái đã thiết lập, và chỉ thiếu các gói. Đó là lý do một trang có thể nằm trên vòng xoay hàng phút trong khi hệ điều hành khẳng định kết nối tồn tại. Hãy đọc chính sách thực thi được ghi lại thay vì suy ra từ thông báo của ứng dụng, vì cả hai hành vi đều trông như mạng bị sập.

Ứng dụng làm gì trong khi khoảng gián đoạn kéo dài

TCP gửi lại với độ trễ tăng dần, và ngân sách thử lại mặc định của Linux hết sau khoảng một phần tư giờ, không phải vài giây. Cho đến lúc đó socket không thực sự mở cũng không đóng. Các ứng dụng có keepalive hoặc thời gian chờ yêu cầu riêng thường bỏ cuộc sớm hơn, đó là lý do hai chương trình trên cùng một máy cư xử khác nhau trong một lần gián đoạn.

Khi đường hầm trở lại, socket cục bộ không đổi nhưng đường đi có thể đã đổi. Một địa chỉ nguồn công cộng mới tạo ra một bộ bốn khác ở máy chủ, nên tường lửa có trạng thái ở phía bên kia không còn khớp với phiên. Kết nối đã chết dù máy khách chưa từng thấy lỗi.

Quyết định xem có cần phục hồi hay không

Chọn giữa hai hợp đồng. Hoặc phiên phải sống sót qua một khoảng gián đoạn ngắn, điều này cần địa chỉ hóa ổn định và máy chủ giữ trạng thái của nó, hoặc ứng dụng phải kết nối lại sạch sẽ, điều này cần logic thử lại an toàn để lặp lại. Bất cứ điều gì ở giữa đều tạo ra kết quả tệ nhất: một máy khách gửi lại thứ máy chủ đã ghi nhận, hoặc một máy khách báo thành công cho một phiên mà không ai có thể thấy.

Địa chỉ hóa ổn định là phần người ta quên, vì một lần kết nối lại đáp xuống một địa chỉ công cộng khác sẽ vô hiệu hóa trạng thái phía máy chủ ngay cả khi socket của máy khách trông khỏe mạnh. Hãy ghi lại hợp đồng nào trong hai hợp đồng áp dụng cho từng ứng dụng, vì hiếm khi tất cả đều khớp.

Kiểm tra việc chặn và phục hồi riêng rẽ

Coi bảo vệ chống rò rỉ và sự sống sót của phiên là hai thuộc tính, vì vượt qua cái này không nói gì về cái kia. Một phiên sống sót không phải bằng chứng rằng lưu lượng trực tiếp đã bị chặn, và một phiên chết không phải bằng chứng rằng mọi tuyến trực tiếp đều bị chặn.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Khi quan sát phục hồi, hãy dùng một thao tác kiểm thử vô hại, để một lần gửi trùng không trở thành sự cố. Hãy ghi lại kiểu hỏng mà bạn thực sự thấy: ứng dụng hiển thị gì, socket có sống sót không và khi nào nó tự phục hồi.

Viết hành vi mong đợi bên cạnh quy tắc thực thi và ghi ngày. Người tiếp theo thay đổi quy tắc đó cần biết triển khai đã hứa hợp đồng nào trong hai hợp đồng.