Điểm:1

Đảm bảo lưu lượng Docker cho nút trong Swarm chỉ đi qua kết nối VPN

lá cờ in

Tôi có hai nút trong cụm Docker Swarm. Một trong những nút đó có kết nối máy khách OpenVPN với nhà cung cấp VPN trên giao diện điều chỉnh0. Mục tiêu của tôi là,

  • Bất kỳ dịch vụ nào được gán cho nút này đều sử dụng riêng kết nối VPN
  • Không có rò rỉ (nghĩa là DNS hoặc lưu lượng truy cập khác)
  • Nếu VPN bị ngắt kết nối, tất cả lưu lượng truy cập sẽ bị hủy
  • Cho phép khám phá dịch vụ và kết nối với các vùng chứa khác trong Swarm

Đối với DNS, tôi đã thêm một dns lối vào /etc/docker/daemon.json sử dụng máy chủ DNS của nhà cung cấp VPN chỉ có thể truy cập thông qua VPN.

Dưới đây là các quy tắc iptable tôi đã đưa ra:

iptables -I DOCKER-USER 1 -o tun0 -j CHẤP NHẬN
iptables -I DOCKER-USER 2 -i tun0 -m conntrack --ctstate LIÊN QUAN, THÀNH LẬP -j CHẤP NHẬN
iptables -I DOCKER-USER 3 -j DROP

Kết quả DOCKER-NGƯỜI DÙNG chuỗi trông như thế này:

Chuỗi DOCKER-USER (1 tài liệu tham khảo)
 pkts byte đích prot chọn không tham gia đích nguồn
    0 0 CHẤP NHẬN tất cả -- * tun0 0.0.0.0/0 0.0.0.0/0
    0 0 CHẤP NHẬN tất cả -- tun0 * 0.0.0.0/0 0.0.0.0/0 ctstate LIÊN QUAN, THÀNH LẬP
    0 0 THẢ tất cả -- * * 0.0.0.0/0 0.0.0.0/0

Từ những thử nghiệm cơ bản như chạy nslookupXoăn khi bật và tắt kết nối VPN, các quy tắc này dường như hoạt động, nhưng tôi có rất ít kinh nghiệm với iptables. Đây có phải là cách chính xác để làm điều này?

Điểm:1
lá cờ fr

IPtables là tuyến tính và nó đọc các quy tắc từ trên xuống dưới cho đến khi đạt đến mục tiêu CHẤP NHẬN, TỪ CHỐI hoặc THẢO, rồi dừng đọc các quy tắc. Trong trường hợp của bạn, bạn muốn có iptables -I DOCKER-USER -j DROP là quy tắc cuối cùng trong chuỗi của bạn, nếu không mọi gói tin sẽ bị loại bỏ. Ngoài ra, không cần quy tắc RETURN ở cuối, bởi vì IPtables sẽ ngừng đọc các quy tắc khi đạt đến quy tắc DROP ngay phía trên nó. Các quy tắc IPtables với tun0 trông ổn, nhưng hãy đảm bảo rằng bạn cũng có các quy tắc này:

iptables -t filter -I INPUT 1 -i tun0 -j DOCKER-USER
iptables -t filter -I OUTPUT 2 -o tun0 -j DOCKER-USER

Để thực hành tốt, hãy đảm bảo rằng bạn chấp nhận tất cả lưu lượng truy cập vòng lặp, lưu lượng truy cập này sẽ không bao giờ truy cập internet cũng như không rời khỏi máy:

iptables -t bộ lọc -I INPUT 3 -i tun0 -j CHẤP NHẬN

Hãy xem xét từng yêu cầu của bạn:

  1. Bất kỳ dịch vụ nào được gán cho nút này đều sử dụng riêng kết nối VPN

Bạn sẽ không sử dụng IPtables để làm điều này. Chạy các lệnh này trên máy chủ:

tuyến ip thêm mặc định qua ${LOCAL_VPN_IP} 

Tôi nghĩ OpenVPN thường sử dụng 10.8.0.0/16, vì vậy cổng mặc định có thể là 10.8.0.1 hoặc đại loại như thế. IProute2 (lệnh ip) được tích hợp trong kernel, giống như IPtables.

  1. Không có rò rỉ (nghĩa là DNS hoặc lưu lượng truy cập khác)

Trước tiên, bạn nên chuyển hướng tất cả lưu lượng truy cập qua VPN bằng cách đặt lưu lượng truy cập này vào cấu hình máy chủ của OpenVPN:

đẩy "chuyển hướng cổng tự động"

Điều này làm cho khách hàng đặt tất cả lưu lượng truy cập của họ thông qua VPN, thậm chí cả DNS, v.v. Nếu máy chủ OpenVPN gặp sự cố, internet sẽ ngừng hoạt động trên các máy khách.

  1. Nếu VPN bị ngắt kết nối, tất cả lưu lượng truy cập sẽ bị hủy

Xem bước 2

  1. Cho phép khám phá dịch vụ và kết nối với các vùng chứa khác trong Swarm

Tôi tin rằng OpenVPN thực hiện điều này theo mặc định. Tôi có thể ping/arp từ máy khách này sang máy khách khác trên máy chủ OpenVPN.Bạn chắc chắn sẽ có thể truy cập các dịch vụ trên các máy khách khác.

Tôi hy vọng điều này trả lời câu hỏi của bạn!

lá cờ in
Cảm ơn bạn! Tôi đã chỉnh sửa câu hỏi của mình để rõ ràng hơn. Dưới đây là một số câu hỏi tiếp theo... 1. Quy tắc `INPUT 1` và `OUTPUT 2` định tuyến lưu lượng thông qua chuỗi con DOCKER-USER. Những thứ đó có cần thiết vì Docker tự động quản lý các quy tắc trong chuỗi FORWARD không? 2. Đối với các quy tắc ban đầu của tôi, tôi nên sử dụng RETURN để cho phép nó đi qua các chuỗi con FORWARD khác hay CHẤP NHẬN? 3. Lệnh `ip route` có thừa không? Không phải tất cả lưu lượng truy cập sẽ bị ép qua giao diện `tun0` bất kể dựa trên quy tắc iptables hay sao?
lá cờ fr
1. Có, bạn cũng có thể thêm `iptables -t filter -A FORWARD -j DOCKER-USER`. `INPUT` dành cho lưu lượng truy cập dành cho máy chủ, `OUTPUT` dành cho lưu lượng truy cập bắt nguồn từ máy chủ và `FORWARD` dành cho lưu lượng truy cập không bắt đầu cũng như không kết thúc tại máy chủ. Nói cách khác, `TIẾP TỤC` là những gì bộ định tuyến của bạn thực hiện khi máy tính của bạn kết nối với google.com. 2. `RETURN` không hữu ích trừ khi bạn đang ở trong chuỗi con và muốn quay lại chuỗi ở cấp độ cao hơn. 3. `ip route` không thừa. `iptables` cho phép hoặc không cho phép các gói, nhưng nó không báo cho máy chủ của bạn nơi gửi các gói. `ip route` thì có.
lá cờ in
1. Vì vậy, bạn đang nói rằng tôi có thể sử dụng `iptables -t filter -A FORWARD -j DOCKER-USER` thay vì thêm các quy tắc `INPUT` và `OUTPUT` mà bạn đã đề cập? 2. `DOCKER-USER` là chuỗi con do Docker quản lý của `FORWARD`, vậy `RETURN` có nên được sử dụng để quay lại chuỗi `FORWARD` không? 3. Có lý, tôi sẽ cần xem xét kỹ hơn vấn đề này vì tuyến đường mặc định hiện tại của tôi đi qua IP cục bộ của tôi.
lá cờ fr
1.`INPUT`, `OUTPUT` và `FORWARD` đều phục vụ các chức năng khác nhau, vì vậy bạn cần bao gồm cả 3 nếu bạn muốn VPN quản lý tất cả lưu lượng của mình. 2. Nếu `INPUT`, `OUTPUT` và `FORWARD` đều được gửi tới `DOCKER-USER`, chuỗi `DOCKER-USER` sẽ quản lý tất cả lưu lượng cho cả 3 chuỗi, nghĩa là bạn không cần `RETURN ` bất cứ điều gì đối với chuỗi `FORWARD`, vì chuỗi `FORWARD` sẽ được xử lý theo các quy tắc trong `DOCKER-USER`.
lá cờ in
Bằng cách xâu chuỗi con `DOCKER-USER` thành `INPUT` và `OUTPUT`, điều đó có áp dụng các quy tắc đó cho tất cả lưu lượng truy cập, bao gồm cả máy chủ không? Có vẻ như điều đó sẽ loại bỏ mọi thứ xuống giao diện vật lý của tôi `eth0`, bao gồm cả kết nối với chính VPN, vì nó sẽ không phù hợp với các quy tắc CHẤP NHẬN.
lá cờ in
Đây là tài liệu cho Docker iptables để tham khảo. https://docs.docker.com/network/iptables/ Dòng quan tâm là "Docker cài đặt hai chuỗi iptables tùy chỉnh có tên là DOCKER-USER và DOCKER và nó đảm bảo rằng các gói đến luôn được kiểm tra bởi hai chuỗi này trước."
lá cờ fr
Xin lỗi vì trả lời muộn, tôi có việc bận. Vì vậy, tôi không biết rằng Docker đã tạo ra các chuỗi đó. Điều đó đang được nói, bạn đúng. `DOCKER-USER` dường như chỉ kiểm tra "các gói đến" theo hiểu biết của tôi. Vì vậy, nếu bạn muốn các gói gửi đi chỉ đi qua VPN, bạn sẽ làm điều gì đó như `iptables -t filter -A OUTPUT -o tun0 -j ACCEPT` theo sau là `iptables -t filter -A OUTPUT ! -o tun0 -j DROP` hoặc bạn cũng có thể có `iptables -t filter -A OUTPUT -j DROP` sau quy tắc CHẤP NHẬN.
lá cờ in
Cảm ơn đã theo lên! Tất cả các chuỗi đều có ý nghĩa bây giờ, tôi sẽ thực hiện chúng. Đối với tuyến ip, có vẻ như OpenVPN tự động thực hiện điều đó trong khi khởi động với các `tuyến thêm 0.0.0.0/1 qua REMOVED` và `128.0.0.0/1 qua REMOVED`. Thật không may, tôi không thể xác nhận xem máy chủ OpenVPN có cài đặt `redirect-gateway autolocal` hay không. Bạn có biết một cách để xác nhận điều này?
lá cờ fr
Bạn sẽ đặt `push "redirect-gateway autolocal"` trong tệp cấu hình máy chủ OpenVPN của mình. Bằng cách đó, nó sẽ đẩy cài đặt đó tới máy khách để định tuyến lại tất cả lưu lượng truy cập của họ. Nhưng có vẻ như OpenVPN phải có một số cài đặt như vậy được bật theo mặc định. Các lệnh định tuyến đó sẽ chuyển hướng tất cả lưu lượng truy cập qua VPN.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.