Công tắc ngắt cho sidecar VPN: chặn lưu lượng khi nó thoát

Một container ứng dụng chia sẻ không gian tên mạng của container VPN không có giao diện riêng, nên dễ cho rằng nó không thể gửi gì khi đường hầm hỏng. Giả định đó sai ở chế độ hỏng quan trọng. Nếu tiến trình VPN chết trong khi không gian tên vẫn còn, ứng dụng giữ các socket và không gian tên giữ các tuyến đường, và lưu lượng tiếp tục trên đường dẫn vẫn được cài. Một kill switch thực sự là chính sách lọc rõ ràng cộng với các kiểm thử vòng đời của runtime, không phải một phụ thuộc khởi động.

Vì sao chia sẻ không gian tên không phải kill switch

Chia sẻ một không gian tên nghĩa là ứng dụng dùng giao diện, địa chỉ và bảng tuyến của container VPN. Nó loại bỏ đường đi độc lập của ứng dụng ra mạng khi không gian tên dùng chung còn nguyên vẹn, và nó không nói gì về việc không gian tên đó sẽ làm gì khi đường hầm biến mất.

Các điều kiện phụ thuộc của Compose có thể trì hoãn khởi động ứng dụng cho đến khi một phụ thuộc khỏe mạnh. Điều đó chỉ bao một thời điểm và không bao lần hỏng về sau, nên nó là một công cụ sắp xếp thứ tự khởi động chứ không phải tường lửa chiều ra liên tục.

Điều gì thực sự xảy ra khi container thoát

Phân biệt ba sự kiện. Tiến trình VPN bên trong container có thể chết trong khi container vẫn chạy. Container có thể dừng hoặc bị xóa, điều đó phá hủy không gian tên. Container có thể được tạo lại, điều đó dựng một không gian tên mới và các quy tắc mới.

Trong trường hợp thứ nhất không gian tên vẫn tồn tại, tuyến mặc định có thể vẫn trỏ tới giao diện vật lý, và ứng dụng vẫn gửi trực tiếp. Trong trường hợp thứ hai ứng dụng phụ thuộc thường mất kết nối hoàn toàn, vì không gian tên của nó đã biến mất. Trong trường hợp thứ ba ứng dụng có thể kết nối lại với một không gian tên mới trước khi đường hầm sẵn sàng. Mỗi trường hợp cần một kiểm thử khác nhau, và một thiết kế chỉ bao ngắt kết nối có trật tự sẽ bao trường hợp ít thú vị nhất.

Xây dựng chính sách chiều ra rõ ràng

Viết chính sách bên trong không gian tên dùng chung để nó áp dụng cho các gói của ứng dụng. Hình thức là từ chối mặc định với các ngoại lệ hẹp: loopback, giao diện đường hầm, và địa chỉ cùng cổng điểm cuối cụ thể mà vận chuyển đường hầm cần.

Ngoại lệ điểm cuối phải có trước khi đường hầm dựng lên, nếu không máy khách VPN không thể tới máy chủ của nó. Đó là lý do bộ quy tắc cho phép rõ ràng vận chuyển bên ngoài thay vì cho phép giao diện vật lý nói chung. Thêm cả quy tắc IPv6 nếu không gian tên có kết nối IPv6, vì chính sách chỉ IPv4 để hở họ địa chỉ kia.

DNS cũng thuộc chính sách. Nếu ứng dụng phân giải tên qua một bộ phân giải chỉ tiếp cận được bên trong đường hầm, quy tắc từ chối sẽ phá vỡ phân giải khi đường hầm xuống, và đó là hành vi đúng cho kill switch. Hãy quyết định có chủ ý xem đó có phải điều bạn muốn.

Kiểm thử vòng đời, không chỉ ngắt kết nối

Gửi một yêu cầu mới vô hại khi đường hầm khỏe mạnh, rồi giết tiến trình VPN và gửi một yêu cầu khác. Lặp lại sau khi container dừng, sau khi khởi động lại và sau khi tạo lại. Một yêu cầu mới quan trọng vì kết nối đang có có thể sống sót qua thay đổi quy tắc chặn các kết nối mới.

Đừng dựa vào kiểm tra sức khỏe hay tra cứu IP thoát làm cơ chế chặn. Kiểm tra quan sát trạng thái và báo cáo nó; chính sách kiểm soát lưu lượng. Cả hai thuộc cùng một triển khai, và chúng không thay thế nhau.

Ghi lại các quy tắc để kiểm thử sống qua một lần cập nhật

Viết kết quả mong đợi cho từng trường hợp hỏng vào tài liệu triển khai, cùng với các quy tắc thực thi nó. Bản ghi đó cho phép chạy cùng kiểm thử sau khi cập nhật image hoặc nâng cấp runtime, khi hành vi không gian tên hoặc tuyến mặc định có thể thay đổi mà không ai sửa tệp compose.

Giữ đường đi bên ngoài cần thiết của điểm cuối VPN tách khỏi chiều ra ứng dụng không giới hạn, và giữ DNS cùng IPv6 trong phạm vi dự kiến. Nếu chính sách cho phép toàn bộ giao diện vật lý vì tiện lợi, kill switch đã biến mất. Tài liệu mạng của Docker mô tả cách bố trí không gian tên dùng chung mà chính sách dựa trên, và đó là tham chiếu cần kiểm tra khi hành vi của runtime bị nghi ngờ.