DNAT trong container VPN: chuyển tiếp, không phải INPUT

Yêu cầu đến với địa chỉ IP đường hầm và rời cùng container với địa chỉ của một dịch vụ lân cận. Giữa hai thời điểm đó, DNAT đã viết lại đích, và gói tin không còn là đầu vào của container VPN nữa. Giờ nó là lưu lượng được chuyển tiếp, do một quy tắc khác phán xét. Sự thay đổi đó giải thích vì sao một quy tắc tường lửa trông đúng với địa chỉ đường hầm lại không có tác dụng với kết nối đã được dịch.

Theo dõi gói tin sau khi dịch

Lấy một nhóm khách hàng 10.90.0.0/24 và địa chỉ đường hầm 10.90.0.1. Hai container nằm trên cùng một bridge: 192.0.2.2 chạy VPN và 192.0.2.3 chạy ứng dụng. Một khách hàng kết nối tới 10.90.0.1:8080, và quy tắc DNAT trong không gian tên của container VPN viết lại nó thành địa chỉ và cổng thật của ứng dụng. Sau đó một tuyến đường gửi gói tin qua bridge. Những địa chỉ đó chỉ là ví dụ, không phải công thức triển khai.

Cổng mà ứng dụng thực sự lắng nghe có thể khác với bất kỳ cổng nào được công bố trên máy chủ. Hãy đọc trình lắng nghe bên trong container thay vì giả định cả hai con số khớp nhau.

Quyền nằm trên đường chuyển tiếp

Container VPN cần chuyển tiếp IP và một quyết định chuyển tiếp giới hạn trong nhóm khách hàng, địa chỉ ứng dụng và cổng dự định. Các phản hồi đã thiết lập cần quyền riêng của chúng. Một quy tắc khớp với địa chỉ đường hầm gốc sẽ không khớp sau DNAT, vì đích đã thay đổi. Quyền INPUT là móc sai cho lưu lượng không còn hướng tới máy chủ này.

Giữ phạm vi hẹp: một dải nguồn, một đích, một dịch vụ. Một quy tắc chuyển tiếp dễ dãi thì dễ viết hơn và khó bảo vệ hơn nhiều về sau.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Các chuỗi của Docker không phải chuỗi của container bạn

Các quy tắc bên trong không gian tên của container không phải quy tắc của máy chủ Docker. Khi lưu lượng đi từ giao diện đường hầm sang bridge, tường lửa của bridge trên máy chủ có thể đưa ra quyết định khác. Với backend iptables của Docker, các chuỗi chuyển tiếp được tài liệu hóa và các điểm khớp sau DNAT là nơi quyết định đó xuất hiện.

Tài liệu tham chiếu tường lửa của Docker mô tả các chuỗi đó và việc khớp sau DNAT. Đừng sửa một chấp nhận bị thiếu bằng cách tắt quản lý tường lửa của Docker hoặc làm mọi chuỗi dễ dãi, vì điều đó gỡ bỏ ranh giới bạn đang cố dùng.

Biến đường quay về thành lựa chọn có chủ đích

Nếu địa chỉ nguồn được giữ lại, ứng dụng thấy 10.90.0.x và phải định tuyến phản hồi quay lại qua container VPN. Nếu không, gateway Docker thông thường sẽ gửi chúng tới máy chủ, nơi không sở hữu đường hầm. Giải pháp thay thế là dịch nguồn phạm vi hẹp tại container VPN, giúp phản hồi đơn giản hơn nhưng giấu khách hàng khỏi ứng dụng. Hãy chọn có chủ đích và ghi lại bạn đã chọn cách nào.

Thử một kết nối mới được phép từ một khách hàng thông thường, rồi xác nhận các cổng không liên quan vẫn đóng. Khi một gói tin biến mất, hãy kiểm tra không gian tên VPN, không gian tên ứng dụng và nhật ký của chính ứng dụng. Ping tới gateway của bridge không phải là bài kiểm tra chấp nhận cho dịch vụ.

Giữ các quy tắc trong cấu hình khởi động được hỗ trợ của container, vì các chỉnh sửa tương tác biến mất khi nó được tạo lại. Công bố cổng trên máy chủ là một đường phơi bày khác và không cần thiết chỉ vì dịch vụ có thể truy cập qua đường hầm.