Xuất bản cổng Docker so với VPN: câu trả lời đi đâu
Một container đã xuất bản trả lời từ địa chỉ của chính nó trước NAT ngược. Hai thiết kế có thể giữ câu trả lời đó trên đường công cộng, với chi phí khác nhau.
Máy chủ vẫn tiếp tục trả lời SSH sau khi một VPN đường hầm đầy đủ được bật, trong khi một dịch vụ được xuất bản bằng Docker trên cùng máy lại im lặng. Không có gì sai với trình lắng nghe: container đang chạy, ánh xạ cổng tồn tại và gói tin vẫn đến. Container khỏe mạnh và yêu cầu thực sự đến được nó. Điều khác biệt là câu trả lời bắt đầu từ đâu khi Linux chọn tuyến của nó, và sự khác biệt đó quyết định thiết kế nào trong hai thiết kế dưới đây mà bạn cần.
Theo dõi bộ tuple qua NAT đích
Lấy một máy chủ tại 192.0.2.10 đang xuất bản TCP 2222 tới một container tại 172.30.240.5:22. Một yêu cầu từ 198.51.100.25 được dịch trước khi đến container, và container trả lời với tư cách chính nó.
WAN request: 198.51.100.25 -> 192.0.2.10:2222
after DNAT: 198.51.100.25 -> 172.30.240.5:22
container reply: 172.30.240.5:22 -> 198.51.100.25
Tại quyết định tuyến của máy chủ, câu trả lời vẫn mang địa chỉ nguồn của container. Việc dịch ngược khôi phục bộ tuple đã xuất bản sau đó, và đó là lý do gói tin trông sai ngay tại thời điểm tuyến được chọn.
Vì sao một quy tắc chỉ cho máy chủ lại bỏ sót nó
Một quy tắc chỉ chọn bảng WAN cho các gói từ 192.0.2.10 bao phủ các daemon của chính máy chủ và bỏ sót hoàn toàn câu trả lời đã chuyển tiếp này. Địa chỉ nguồn trên câu trả lời là 172.30.240.5, không phải máy chủ.
Cách sửa quá mức là định tuyến mọi thứ từ container qua WAN, điều này cũng miễn trừ VPN cho các kết nối đi ra không liên quan của container. Đó là chính sách khác với chính sách được yêu cầu, và thường khiến ai đó bất ngờ về sau.
Khớp sau DNAT là một hook khác
Tài liệu Docker về tường lửa lưu ý rằng lọc người dùng thông thường thấy đích sau DNAT, vì vậy khớp cổng đã xuất bản 2222 trong một quy tắc bình thường không giống với khớp cổng 22 của container. Nếu bộ tuple gốc quan trọng, hãy dùng cơ chế đích gốc được hỗ trợ thay vì đoán cổng nào là hiển thị.
Sự nhầm lẫn hook này tạo ra những quy tắc trông đúng và không bao giờ khớp. Kiểm tra bộ đếm trên chính quy tắc trước khi viết lại chính sách. Một quy tắc không có lần khớp nào cho bạn biết nó đang được đánh giá ở nơi mà gói tin không bao giờ tới.
Thiết kế A: mang quyết định như trạng thái kết nối
Dấu kết nối có thể mang quyết định đầu vào xuyên qua việc dịch, nhưng nó phải được khôi phục vào gói tin trước lần tra tuyến quan trọng. Các bước là:
- Dành riêng một trường dấu và mức ưu tiên quy tắc không xung đột với Docker, VPN hay chủ sở hữu chính sách khác.
- Chỉ xác định kết nối WAN mới dự định tại một điểm trước DNAT nơi có theo dõi kết nối.
- Ghi quyết định vào dấu kết nối, không buộc chính yêu cầu gốc vào bảng WAN.
- Theo hướng trả lời, chỉ khôi phục các bit dấu của bạn vào gói tin trước khi định tuyến.
- Chọn một bảng WAN đầy đủ đủ sớm để một quy tắc VPN không thể thắng trước.
Bảng đó cần các tuyến đã kết nối thật và cổng mặc định. Nó cũng cần hành vi xác định khi thiếu tuyến. Rơi âm thầm vào đường hầm là kết quả tệ nhất, vì cấu hình vẫn trông như đang hoạt động. Thay vào đó hãy thất bại theo hướng đóng và ghi lại.
Thiết kế B: kết thúc trên máy chủ
Một frontend phía máy chủ được cấu hình có chủ đích, như proxy TCP hoặc proxy ngược trước container, giữ câu trả lời bắt nguồn từ địa chỉ máy chủ. Khi đó các quy tắc viết cho máy chủ hoạt động như mong đợi, và container vẫn ở trong mạng riêng của nó.
Cái giá là thêm một bộ phận chuyển động với cấu hình, cách xử lý địa chỉ nguồn và kiểm soát truy cập riêng. Đây thường là ranh giới được hỗ trợ đơn giản hơn, và thường là câu trả lời đúng khi chính sách định tuyến sẽ do một người có thể rời đi duy trì.
Kiểm chứng thay đổi, không phải ý định
Mở một kết nối được cấp quyền mới từ phía công cộng và xác nhận câu trả lời đi ra qua giao diện dự định. Sau đó kiểm tra rằng một yêu cầu không liên quan do container khởi tạo vẫn đi theo VPN.
Đừng xóa bảng kết nối của máy để kiểm tra một quy tắc: các mục hiện có giữ ánh xạ trước đó, và việc xóa phá hỏng mọi thứ khác trên máy chủ. Xuất bản một cổng xác định khả năng tiếp cận. Nó không xác định đường đi của câu trả lời. Hãy ghi lại thiết kế đã chọn kèm tên các bảng, để người tiếp theo không phải khám phá lại trong một sự cố.