Cập nhật cổng VPN thất bại: hãy đọc giai đoạn trước khi mở đường ra
Một lần cập nhật thất bại nêu tên một giai đoạn, không phải một cổng bị thiếu. Hãy ghép thông báo với chủ sở hữu của nó, đọc đường đi của proxy, rồi chủ động quyết định chính sách bảo trì.
Từ chối cài đặt các bản cập nhật bảo mật chỉ cách việc trở thành vấn đề của người khác một tuần tồi tệ, và một cổng cho phép máy khách đi vào là nơi dễ nhất để hình thành thói quen đó. Nguyên nhân thường gặp không phải là thiếu tuyến đường mà là thiếu quyết định: không ai nói máy chủ tự nó phải tiếp cận kho lưu trữ như thế nào khi việc chuyển tiếp máy khách được cố ý thu hẹp. Quyết định đó phải được đưa ra một cách rõ ràng, và nó phải hẹp hơn việc tắt chính sách ra ngoài trong một buổi chiều.
Bốn giai đoạn, bốn chủ sở hữu khác nhau
Một lỗi cập nhật là một giai đoạn có tên, dù thông báo có nói ra hay không, và mỗi giai đoạn thuộc về một chủ sở hữu khác. Một cái tên không phân giải được là câu hỏi của bộ phân giải. Một kết nối hết thời gian là câu hỏi của tầng vận chuyển, proxy hoặc đầu xa. Một lỗi nhận dạng TLS là câu hỏi về lòng tin, và siêu dữ liệu kho lưu trữ bị từ chối là câu hỏi về chữ ký. Bốn giai đoạn, bốn chủ sở hữu, và một quy tắc cổng chỉ trả lời một trong số đó.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
Ping và phân giải tên là hai phép thử mà người ta nghĩ tới đầu tiên, và cả hai đều trả lời những câu hỏi không ai đặt ra. Một phản hồi echo dùng giao thức khác với kết nối tới kho lưu trữ, và một truy vấn thành công dừng ở phân giải tên mà không thử việc tải về. Cả hai đều có thể đạt trong khi giao dịch thực sự thất bại, và cả hai đều có thể thất bại vì lý do không liên quan đến đường đi.
Đọc con đường mà trình quản lý thực sự đi
Hãy kiểm tra các URI nguồn đã cấu hình và cách bố trí proxy thực tế thay vì giả định một trong hai. Một quy tắc viết cho HTTP thường không phải là cách sửa khi kho lưu trữ nói HTTPS, và một tổ chức bắt buộc dùng proxy đã chọn con đường đó. Các trình quản lý gói tuân theo biến môi trường và cấu hình riêng của chúng, và các thiết lập riêng cho máy chủ có thể ghi đè thiết lập chung. Điều trình duyệt tương tác làm không nhất thiết là điều trình quản lý làm.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyTài liệu vận chuyển của APT mô tả thiết lập nào áp dụng cho sơ đồ URI nào và cách viết các lựa chọn riêng cho máy chủ. Hãy giữ đầu ra của lệnh cùng với phiếu sự việc, vì nó phân biệt vấn đề proxy với một tuyến đường bị thiếu nhanh hơn bất kỳ số lượng kết quả ping nào. Hãy ghi lại đích đến, cổng và giao thức chính xác mà trình quản lý thử, và để thay đổi tường lửa dựa trên bản ghi đó thay vì một địa chỉ gương phỏng đoán sẽ lỗi thời trong vài tháng.
Chọn một chính sách bảo trì, không phải một ngoại lệ
Ba chính sách là có thể bảo vệ được: bảo trì qua đường hầm, bảo trì qua một proxy cập nhật được quản lý, hoặc bảo trì qua một tuyến trực tiếp được cấp quyền hẹp. Mỗi chính sách ngụ ý một cách bố trí bộ phân giải phù hợp với nó. Điều không thể bảo vệ được là một ngoại lệ lặng lẽ trở thành đường dự phòng không giới hạn mỗi khi đường hầm sập.
Hãy ghi lại chính sách đã chọn cùng với chủ sở hữu, vì người vận hành tiếp theo sẽ tìm thấy quy tắc chứ không phải lý do đằng sau nó. Hãy áp dụng quyền qua tường lửa hiện có và chủ sở hữu mạng thay vì xả sạch quy tắc hoặc thêm một trình quản lý chính sách thứ hai cho một máy chủ. Bao phủ các họ địa chỉ và điểm cuối dịch vụ mà nguồn thật sử dụng, và xem lại danh sách khi kho lưu trữ di chuyển.
Xác minh mà không làm suy yếu lòng tin
Vận chuyển thành công không phải là sự cho phép nới lỏng xác minh: xác thực kho lưu trữ và danh tính máy chủ TLS là hai kiểm tra riêng biệt, và tắt bất kỳ kiểm tra nào sẽ làm một lỗi biến mất trong khi thay đổi điều máy chủ sẽ chấp nhận. Một proxy chặn giữa là quyết định tin cậy của chủ sở hữu mạng chứ không phải lý do để tắt kiểm tra cục bộ, và thông tin đăng nhập của kho lưu trữ không thuộc về chẩn đoán chia sẻ, vì một bản ghi chi tiết là nơi dễ nhất để làm lộ chúng.
Hãy chấp nhận thay đổi bằng một lần tải siêu dữ liệu có kiểm soát, sau đó là một giao dịch gói đã được phê duyệt, rồi thử điều gì xảy ra khi đường hầm sập. Một con đường bảo trì lặng lẽ mở rộng trong lúc có sự cố còn tệ hơn một con đường thất bại theo hướng đóng, và kết quả phải là một con đường cập nhật có chủ sở hữu được nêu tên và phạm vi giới hạn.