Trong hành trình tự host các ứng dụng mã nguồn mở dưới dạng container trong hệ thống home lab của mình, Docker đã chứng tỏ sự hiệu quả vượt trội. Nó cho phép thử nghiệm vô số ứng dụng và dịch vụ mà không làm ảnh hưởng đến cấu hình cơ bản của Raspberry Pi. Tuy nhiên, một số container, đặc biệt là những ứng dụng thu thập dữ liệu từ Internet, có nguy cơ làm lộ địa chỉ IP thật của tôi. Việc sử dụng một VPN cho toàn bộ lưu lượng mạng ban đầu có vẻ là một giải pháp, nhưng thực tế lại gây chậm trễ đáng kể cho nhiều tác vụ.
Đây là lúc Gluetun trở thành yếu tố thay đổi cuộc chơi. Gluetun là một client VPN chuyên biệt dành cho các Docker container, giúp tôi định tuyến lưu lượng truy cập đi của các ứng dụng cụ thể trên máy chủ nhà mình. Nó giải quyết triệt để vấn đề về quyền riêng tư và ngăn chặn rò rỉ IP thông qua một đường hầm VPN an toàn mà không làm giảm hiệu suất chung của mạng. Vì lý do đó, tôi tin rằng Gluetun là phương pháp tốt nhất để định tuyến tất cả lưu lượng đi từ các Docker container, đặc biệt phù hợp cho các hệ thống home lab tự host hoặc mục đích phát triển.
Các Docker container phổ biến cho home lab và server tại gia
Tại sao Gluetun là lựa chọn tối ưu để định tuyến Docker Container qua VPN?
Kiểm soát chi tiết, cô lập và bảo mật quyền riêng tư cho từng container
Việc sử dụng VPN để bảo vệ toàn bộ lưu lượng trên mạng gia đình không mang lại hiệu quả như mong đợi. Nhiều dịch vụ cá nhân và công việc không hoạt động khi phát hiện kết nối VPN. Cuối cùng, Gluetun với khả năng định tuyến VPN riêng biệt cho từng container đã giúp tôi dễ dàng sử dụng mà không cần thay đổi cài đặt mạng. Là một client VPN nhẹ dành cho Docker container, việc tích hợp Gluetun vô cùng đơn giản: chỉ cần cài đặt nó như một container Docker thông thường, không cần thêm cấu hình phức tạp như sửa đổi quy tắc tường lửa hay các cài đặt mạng khác ở cấp độ hệ điều hành.
Gluetun hỗ trợ mặc định nhiều nhà cung cấp VPN lớn như Private Internet Access, Surfshark, NordVPN, ExpressVPN, Mullvad và nhiều nhà cung cấp khác. Do đó, tôi chỉ cần cung cấp thông tin đăng nhập của dịch vụ VPN mình đang sử dụng (Surfshark), và Gluetun sẽ tự động quản lý cài đặt để cấu hình tài khoản qua giao thức WireGuard hoặc OpenVPN. Khi hoạt động như một client VPN, Gluetun sử dụng các cài đặt của nhà cung cấp để tạo một đường hầm an toàn cho tất cả lưu lượng đi từ các container sử dụng mạng của nó. Điều này cũng giúp tận dụng các nhà cung cấp DNS an toàn hoặc mã hóa để ngăn chặn rò rỉ DNS từ đường hầm bảo mật.
Trong trường hợp kết nối VPN bị gián đoạn, Gluetun sẽ tự động chặn tất cả lưu lượng từ các container đã cấu hình để ngăn chặn rò rỉ IP. Gluetun sử dụng iptables để thực thi tính năng kill switch này, đảm bảo rằng các container được kết nối sẽ không hoạt động trừ khi VPN được kích hoạt. Điều này vượt trội hơn nhiều so với việc sử dụng các VPN toàn hệ thống mà không có kill switch hoặc tường lửa, vốn có thể làm lộ địa chỉ IP của máy chủ.
Hướng dẫn xử lý lưu lượng đi của container nhạy cảm một cách an toàn với Gluetun
Định tuyến lưu lượng đi an toàn qua đường hầm VPN
Tôi thường sử dụng các tệp Docker Compose trong Dockge để triển khai nhóm ứng dụng ARR cùng với Gluetun. Theo mặc định, các container này sẽ sử dụng ngăn xếp mạng của Gluetun và không có quyền truy cập vào IP thực hoặc máy chủ của tôi. Đối với các ngăn xếp ứng dụng của mình, tôi đã dùng thông tin đăng nhập của Surfshark VPN. Tôi đăng nhập vào tài khoản Surfshark VPN và kích hoạt tùy chọn thiết lập thủ công, sau đó hệ thống sẽ tạo ra một mã chữ và số cụ thể cho tên người dùng và mật khẩu. Hãy sử dụng thông tin này trong cấu hình container của Gluetun.
Khi sử dụng Gluetun trên các bo mạch máy tính đơn (SBC) như Raspberry Pi, tôi khuyến nghị sử dụng giao thức WireGuard thay vì OpenVPN để đạt được tốc độ, độ ổn định tốt hơn và giảm tải CPU.
Dưới đây là cấu hình Gluetun điển hình trong tệp Docker Compose:
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
cap_add:
- NET_ADMIN
environment:
- VPN_SERVICE_PROVIDER=surfshark
- OPENVPN_USER=username
- OPENVPN_PASSWORD=password
- FIREWALL=on
- TZ=Asia/Kolkata
volumes:
- ./gluetun:/gluetun
ports:
- 8080:8080 # qBittorrent web UI
- 8989:8989 # Sonarr
- 7878:7878 # Radarr
- 8686:8686 # Lidarr
- 6767:6767 # Bazarr
restart: unless-stoppedThêm đoạn mã này vào đầu một ngăn xếp mới đảm bảo rằng Gluetun được cài đặt trước tiên. Sau đó, tôi thêm chế độ mạng để các container còn lại sử dụng mạng của Gluetun. Ngoài ra, tôi cũng đưa biến môi trường FIREWALL vào để chặn hoàn toàn truy cập Internet khi kết nối VPN bị ngắt. Về mặt kỹ thuật, tường lửa được bật mặc định, nhưng tôi vẫn thêm nó vào như một biện pháp phòng thủ khi sử dụng cùng một tệp compose trên các môi trường khác nhau. Dưới đây là đoạn mã cho một container sử dụng mạng của Gluetun:
sonarr:
image: lscr.io/linuxserver/sonarr
container_name: sonarr
network_mode: service:gluetun
depends_on:
- gluetun
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Kolkata
volumes:
- ./sonarr:/config
- ./downloads:/downloads
- ./media/tv:/tv
restart: unless-stoppedLưu ý rằng tôi đã chỉ định biến network_mode để sử dụng dịch vụ Gluetun. Sau khi triển khai toàn bộ ngăn xếp ứng dụng ARR, việc kiểm tra xem các container có thực sự sử dụng mạng của Gluetun cho lưu lượng đi của chúng hay không là rất cần thiết. Tôi đã chạy lệnh sau để kiểm tra:
docker exec radarr curl ifconfig.meLệnh này đã hiển thị địa chỉ IP được gán bởi nhà cung cấp dịch vụ VPN mà tôi đã sử dụng trong thiết lập của Gluetun. Điều đó có nghĩa là tất cả các container đều sử dụng đường hầm VPN do Gluetun thiết lập.
Những trường hợp Docker Container không tương thích với Gluetun
Các ngoại lệ cần lưu ý
Mặc dù Gluetun là lựa chọn tốt nhất để định tuyến lưu lượng đi, nhưng nó không hoạt động với tất cả các ứng dụng và dịch vụ dựa trên container đòi hỏi phải mở cổng đến (inbound ports) trực tiếp ra mạng LAN. Ví dụ, các ứng dụng torrent như qBittorrent, Transmission hoặc Deluge yêu cầu mở các cổng đến cụ thể cho TCP và UDP.
Ngoài ra, các ứng dụng và dịch vụ cần khám phá mạng cục bộ thông qua multicast hoặc broadcast cũng gặp vấn đề. Chẳng hạn, Home Assistant đòi hỏi khả năng khám phá thiết bị trên mạng LAN để dễ dàng tích hợp. Tương tự, Pi-hole và Unbound sẽ gây xung đột DNS với các quy tắc DNS và tường lửa của Gluetun.
Một hạn chế lớn mà tôi đã học được là việc mở cổng HTTPS không hoạt động với Gluetun. Vì vậy, tôi phải chạy một container như Nginx Proxy Manager mà không thông qua mạng của Gluetun. Hơn nữa, tôi không thể truy cập các ứng dụng bằng IP của VPN vì Surfshark không hỗ trợ chuyển tiếp cổng (port forwarding). Tuy nhiên, việc thiết lập một reverse proxy không nằm sau VPN, ngay cả khi nó không chuyển tiếp cổng, đã khắc phục được vấn đề vì nó giao tiếp bên ngoài Gluetun, qua mạng của Docker stack.
Hệ thống home lab với các server và thiết bị mạng trong tủ rack
Gluetun đã chứng tỏ mình là một giải pháp nhẹ nhưng mạnh mẽ, mang lại khả năng định tuyến lưu lượng linh hoạt cho các container. Nhờ nó, tôi có thể tiếp tục sử dụng các container chọn lọc để vượt qua các hạn chế về địa lý và tránh bị cấm IP. Quan trọng hơn, Gluetun không can thiệp vào các tệp hệ thống và có thể chạy mượt mà trên cả các bo mạch máy tính đơn (SBC) có công suất thấp. Mặc dù vẫn yêu cầu một tài khoản từ nhà cung cấp dịch vụ VPN, nhưng Gluetun đã giải quyết triệt để nhu cầu về đường hầm VPN cho các Docker container cụ thể. Tôi đặc biệt khuyên bạn nên thiết lập Health Checks bằng webhooks để Gluetun có thể thông báo cho bạn bất cứ khi nào kết nối VPN bị ngắt.