Trong hành trình xây dựng và duy trì một phòng lab tại gia (home lab) với nhiều ứng dụng mã nguồn mở tự host dưới dạng Docker container, tôi đã gặp phải một thách thức lớn. Nhiều container như trình lập chỉ mục hay tự động hóa tải xuống, cần truy xuất dữ liệu từ Internet, đồng nghĩa với việc địa chỉ IP của tôi có thể bị lộ. Ban đầu, tôi thử giải pháp đặt toàn bộ lưu lượng mạng phía sau một VPN, nhưng điều này lại làm chậm đáng kể nhiều tác vụ và gây xung đột với một số ứng dụng khác.
Đó là lúc tôi phát hiện ra Gluetun, một VPN client chuyên biệt dành cho Docker container, được thiết kế để định tuyến lưu lượng truy cập Internet cho các ứng dụng trên máy chủ gia đình. Gluetun đã thay đổi hoàn toàn cuộc chơi, mang lại khả năng định tuyến lưu lượng cụ thể cho từng container, tăng cường quyền riêng tư và ngăn chặn rò rỉ IP hiệu quả thông qua một đường hầm VPN an toàn. Dù không phải là một VPN đầy đủ với các tùy chọn kết nối vào (inbound connectivity), Gluetun là giải pháp hoàn hảo cho một home lab tự host hoặc phục vụ mục đích phát triển.
Các Docker container phổ biến chạy trong môi trường home lab cá nhân
Tại sao Gluetun là lựa chọn hàng đầu để định tuyến Docker container qua VPN?
Kiểm soát chi tiết, cô lập và bảo vệ 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 truy cập trên mạng gia đình của tôi đã không hoạt động trơn tru như mong đợi. Nhiều ứng dụng cá nhân và công việc không thể truy cập được khi phần mềm hoặc dịch vụ phát hiện kết nối VPN. Cuối cùng, việc sử dụng Gluetun để định tuyến VPN cho các container cụ thể đã giúp tôi dễ dàng sử dụng mà không cần thay đổi cài đặt mạng toàn hệ thống.
Là một VPN client nhẹ dành cho Docker container, Gluetun có khả năng tích hợp cực kỳ đơn giản. Tất cả những gì tôi cần làm là cài đặt nó như một Docker container khác. Không yêu cầu cấu hình bổ sung để sửa đổi bất kỳ quy tắc tường lửa hay thay đổi mạng nào ở cấp độ hệ điều hành.
Theo mặc định, Gluetun hỗ trợ 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. Vì vậy, tôi chỉ cần cung cấp thông tin đăng nhập cho dịch vụ VPN mà tôi sử dụng (Surfshark), và Gluetun sẽ tự động quản lý cài đặt để cấu hình tài khoản bằng giao thức WireGuard hoặc OpenVPN. Khi hoạt động như một VPN client, Gluetun sử dụng cài đặt của nhà cung cấp VPN để tạo một đường hầm an toàn cho tất cả lưu lượng truy cập đi ra từ các container sử dụng mạng của nó. Bằng cách đó, nó sử dụng các nhà cung cấp DNS an toàn hoặc được mã hóa để ngăn chặn rò rỉ DNS từ đường hầm bảo mật.
Nếu kết nối VPN bị gián đoạn, Gluetun sẽ tự động chặn tất cả lưu lượng truy cập 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 trong trường hợp VPN bị ngắt kết nối, điều này có nghĩa là các container được kết nối sẽ không hoạt động trừ khi VPN hoạt động trở lại. Điều này tốt hơn nhiều so với việc sử dụng bất kỳ VPN toàn hệ thống nào mà không có Kill Switch hoặc tường lửa, có thể làm lộ địa chỉ IP của máy chủ.
Định tuyến lưu lượng truy cập an toàn cho các Container nhạy cảm
Tôi sử dụng tệp Docker Compose trong Dockge để triển khai bộ ứng dụng ARR (Sonarr, Radarr, Lidarr, Bazarr) hoạt độ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 của tôi hoặc máy chủ. Đối với các ngăn xếp của mình, tôi đã sử dụng thông tin đăng nhập VPN của Surfshark. 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, từ đó tạo ra một mã chữ và số cụ thể cho tên người dùng và mật khẩu. Tôi sử dụng thông tin này trong cấu hình container của Gluetun.
Tôi khuyên bạn nên sử dụng giao thức WireGuard thay vì OpenVPN để đạt được tốc độ tốt hơn, độ ổn định cao hơn và giảm tải CPU khi sử dụng Gluetun trên một máy tính bảng mạch đơn (SBC) như Raspberry Pi.
Dưới đây là ví dụ về mã thiết lập Gluetun trong một tệp Docker Compose điển hình:
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-stopped
Việc thêm 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 đã bao gồm biến môi trường FIREWALL=on
để 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 theo mặc định. Là một phần của thực hành phòng thủ, tôi đã thêm việc 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à 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-stopped
Bạn có thể thấy 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à cần thiết. Tôi đã chạy lệnh này để kiểm tra:
docker exec radarr curl ifconfig.me
Lệ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 không thể sử dụng Gluetun hiệu quả
Gluetun là một lựa chọn tuyệt vời để định tuyến lưu lượng truy cập đ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 yêu cầu phơi bày trực tiếp các cổng đến (incoming ports) 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.
Tương tự, các ứng dụng và dịch vụ yêu cầu khám phá mạng cục bộ thông qua multicast hoặc broadcast cũng gặp vấn đề. Giống như Home Assistant, nó yêu cầu khám phá các thiết bị trên mạng LAN để tích hợp dễ dàng. 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 đã nhận thấy là việc phơi bày các cổng HTTPS không hoạt động với Gluetun. Do đó, tôi phải chạy một container, chẳng hạn như Nginx Proxy Manager, mà không thông qua mạng của Gluetun. Ngoài ra, 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 phía sau VPN, ngay cả khi nó không chuyển tiếp cổng, đã khắc phục được sự cố vì nó giao tiếp bên ngoài Gluetun, trên mạng của ngăn xếp Docker.
Tủ rack server nhỏ gọn chứa các thiết bị của một home lab
Gluetun đã chứng tỏ là một giải pháp nhẹ nhưng mạnh mẽ, thay đổi cuộc chơi trong việc định tuyến lưu lượng truy cập từ các container. 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ế địa lý và tránh bị cấm IP. Quan trọng nhất, nó không can thiệp vào các tệp hệ thống và có thể chạy trơn tru trên các máy tính bảng mạch đơn (SBC) công suất thấp. Mặc dù vẫn yêu cầu tôi sử dụng tài khoản của nhà cung cấp dịch vụ VPN, nhưng nó đã giải quyết được yêu cầu về đường hầm VPN cho các Docker container cụ thể. Tôi khuyên bạn nên thiết lập Health Checks bằng webhooks để Gluetun thông báo cho bạn bất cứ khi nào VPN bị ngắt kết nối.
Bạn đã trải nghiệm Gluetun chưa? Hãy chia sẻ ý kiến của bạn về giải pháp này bên dưới!