Xuất bản cổng Docker và nguồn VPN: hai điểm khớp bạn bỏ sót

Quy tắc nói hãy cho phép địa chỉ máy chủ VPN tới dịch vụ đã xuất bản, và kết nối vẫn bị ngắt. Kết quả đó là phổ biến, và đó không phải lỗi của Docker. Hai điểm khớp riêng biệt đang sai: nguồn bạn viết có thể không phải nguồn mà máy chủ nhận, và cổng bạn viết có thể không phải cổng mà bộ lọc thấy. Sửa cả hai đòi hỏi phải xem đường đi của gói tin thay vì sơ đồ dịch vụ.

Lầm tưởng: cho phép máy chủ VPN là xong

Một VPN định tuyến có thể giữ nguyên địa chỉ đường hầm của máy khách cho tới tận máy chủ Docker. Một cổng vào thực hiện dịch nguồn có thể thay địa chỉ đó bằng địa chỉ của nó. Cả hai thiết kế đều hợp lệ, và chúng tạo ra các nguồn khác nhau cho cùng một thao tác của người dùng.

Vậy cụm từ IP máy chủ VPN mô tả một giả định, không phải một quan sát. Cho tới khi bạn biết thiết kế nào trong hai đang ở trước mặt, quy tắc vẫn là phỏng đoán.

Nguồn: bể máy khách hay cổng vào đã dịch

Kiểm tra bốn thứ theo thứ tự. Thứ nhất, bể địa chỉ máy khách, ví dụ 10.90.0.0/24. Thứ hai, cổng vào có dịch bể đó trước khi nó tới máy chủ không. Thứ ba, nguồn mà máy chủ thực sự quan sát cho một kết nối mới. Thứ tư, việc xác thực ứng dụng có phân biệt từng người dùng không, vì địa chỉ dịch dùng chung thì không thể.

Nếu bể được giữ nguyên, quy tắc chỉ khớp địa chỉ công cộng của cổng vào sẽ bỏ sót mọi máy khách. Nếu cổng vào dịch có chủ đích, việc cho phép địa chỉ đã dịch sẽ nhận mọi người dùng phía sau nó, điều có thể chấp nhận với một dịch vụ có đăng nhập riêng và không chấp nhận được với bất cứ thứ gì khác.

Cổng: DNAT đổi con số bạn khớp

Trong cách xuất bản cầu Linux thông thường với iptables của Docker, ánh xạ máy chủ từ 8443 sang cổng 443 của container được dịch trước khi bộ lọc chuyển tiếp chạy. Gói tin tới bộ lọc với cổng đích 443. Một quy tắc khớp với 8443 tại điểm đó không bao giờ kích hoạt, dù 8443 là thứ máy khách đã gõ.

Cổng đã xuất bản vẫn tồn tại trong theo dõi kết nối, vì thế đích gốc có thể được khớp ở đó khi bạn thực sự cần.

Quyết định con số nào thể hiện ý định. Khớp cổng container sau DNAT khi quy tắc bảo vệ dịch vụ bên trong container. Khớp đích gốc bằng tùy chọn conntrack khi quy tắc phải mô tả điều máy khách yêu cầu, và chấp nhận chi phí khớp thêm cùng sự cẩn trọng về thứ tự quy tắc đi kèm.

Chuỗi: DOCKER-USER, không phải INPUT

Hướng dẫn iptables của Docker đặt chính sách chuyển tiếp người dùng vào chuỗi DOCKER-USER, chuỗi này được đánh giá trước các quy tắc chuyển tiếp của chính Docker. Một quy tắc sao chép từ dịch vụ trên máy chủ vào chuỗi INPUT sẽ lọc lưu lượng hướng tới máy chủ, không phải lưu lượng được chuyển tiếp vào container. Sai sót đó tạo ra một quy tắc trông đúng và không có tác dụng gì trên đường đi của container.

Giữ dải nguồn, cổng đích hiệu lực, giao thức và giao diện vào cùng trong một quy tắc. Cho phép chỉ dựa trên nguồn cho mọi đích được chuyển tiếp là rộng hơn so với cho phép một dịch vụ đã xuất bản.

Xác minh bằng kết nối mới

Thử cả hai chiều bằng kết nối mới: một máy khách VPN được phép và một nguồn phải tiếp tục bị từ chối. Trạng thái kết nối sẵn có có thể giữ phiên sống sau khi chính sách thay đổi, nên một kết nối cũ không chứng minh được gì về quy tắc mới. Sau đó kiểm tra đường phản hồi, vì container vẫn phải định tuyến ngược về nguồn mà nó thấy.

Thứ tự chuỗi và hành vi dịch cổng phía sau các bước kiểm tra này được ghi lại trong hướng dẫn iptables của Docker. Hãy đọc trước khi sao chép một công thức, và xác nhận Docker đã cài dùng backend nào, vì backend nftables tích hợp chính sách theo cách khác.