Site icon ZingServer

Cấu hình Squid Transparent Proxy trên VPS Linux (Xử lý HTTP/HTTPS)

Team ZingServer
Cấu hình Squid Transparent Proxy trên VPS Linux (Xử lý HTTPHTTPS)

Cấu hình Squid Transparent Proxy trên VPS Linux (Xử lý HTTPHTTPS)

Trong quản trị hệ thống, việc kiểm soát tập trung truy cập Internet cho nhiều thiết bị (như máy ảo, container, hoặc toàn bộ mạng văn phòng) là một nhu cầu thiết yếu. Tuy nhiên, việc cấu hình proxy thủ công trên từng máy client là một cơn ác mộng.

Đây là lúc Squid Transparent Proxy (Proxy trong suốt) phát huy sức mạnh. Không giống các phương pháp proxy truyền thống, nó hoạt động “vô hình” ở tầng mạng. Traffic của người dùng bị chặn và chuyển hướng qua Squid một cách tự động mà họ không hề hay biết.

Bài viết này sẽ hướng dẫn bạn cấu hình loại proxy cao cấp này trên VPS Linux.

Phân biệt 3 chế độ hoạt động của Squid

Squid là một công cụ cực kỳ linh hoạt. Để tránh nhầm lẫn, chúng ta cần phân biệt rõ 3 chế độ hoạt động chính của nó:

  1. Forward Proxy (Proxy Xuôi):
  2. Reverse Proxy (Proxy Ngược / Web Accelerator):
  3. Transparent Proxy (Proxy Trong suốt) – Bài viết này:
    • Mục đích: Tự động “bắt” và lọc traffic của client mà không cần client cấu hình.
    • Yêu cầu: Cấu hình phức tạp ở tầng mạng (VPS Gateway) và tường lửa.

Lợi ích khi triển khai Squid Transparent Proxy

Việc cài đặt proxy trong suốt mang lại nhiều lợi ích cho quản trị viên hệ thống:

Cảnh báo: Nhược điểm của Interception Proxy

Dù rất mạnh mẽ, phương pháp này (theo tài liệu chính thức của Squid) có nhiều nhược điểm kỹ thuật nghiêm trọng bạn phải cân nhắc:

Khuyến nghị: Chỉ sử dụng giải pháp này khi bạn hiểu rõ các hạn chế và chấp nhận chúng, hoặc khi việc cấu hình thủ công cho client là bất khả thi.

Chuẩn bị môi trường VPS

Mô hình này giả định VPS Linux của bạn hoạt động như một Gateway (Cổng kết nối).

Bước 1: Cài đặt Squid và kích hoạt IP Forwarding

Bước đầu tiên là cài đặt các gói cần thiết và cho phép kernel Linux chuyển tiếp các gói tin mạng.

Cài đặt Squid

Kích hoạt IP Forwarding (Bắt buộc)

Chúng ta cần cho phép kernel Linux chuyển tiếp các gói tin (packets) từ client ra Internet.

Bước 2: Cấu hình Squid cho chế độ “Intercept” (HTTP)

Bây giờ, chúng ta sẽ cấu hình Squid để nó hiểu và chấp nhận các kết nối bị “bắt” lại.

Lưu file cấu hình và thoát.

Bước 3: Chuyển hướng traffic HTTP (Port 80) bằng tường lửa

Đây là phần “ma thuật” làm nên tính “trong suốt”. Chúng ta sẽ dùng tường lửa để chuyển hướng (REDIRECT) mọi traffic HTTP (port 80) đến cổng 3128 của Squid.

Giả sử card mạng nội bộ (phía client) là eth1.

Dùng Iptables (Cũ – Mặc định trên Ubuntu/Debian)

# Trong bảng NAT (-t nat), thêm quy tắc vào chuỗi PREROUTING
# Bắt traffic TCP (-p tcp) đến cổng 80 (--dport 80) trên card eth1
# Và REDIRECT nó về cổng 3128 của chính VPS
sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

Để lưu quy tắc (Ubuntu), cài iptables-persistent và chạy sudo netfilter-persistent save.

Dùng Firewalld (Mặc định trên CentOS/RHEL)

Lưu ý: Chúng ta dùng --add-redirect, không dùng --add-forward-port. REDIRECT là chuyển hướng cục bộ, chính là thứ chúng ta cần.

# Giả sử card eth1 nằm trong zone "internal"
# Thêm quy tắc chuyển hướng (REDIRECT) vĩnh viễn
sudo firewall-cmd --permanent --zone=internal --add-redirect=port=80:proto=tcp:toport=3128

# Tải lại Firewalld
sudo firewall-cmd --reload

Bạn có thể xem thêm về cách cho phép tất cả lưu lượng truy cập từ một địa chỉ IPv4 thông qua Firewall Centos 7 nếu cần mở port.

Dùng Nftables (Hiện đại – Mặc định trên RHEL 8+, Ubuntu 22.04+)

nftables là công cụ thay thế iptables.

# 1. Tạo bảng 'nat'
sudo nft add table ip nat

# 2. Thêm chuỗi 'prerouting' (hook vào trước khi định tuyến)
sudo nft -- add chain ip nat prerouting { type nat hook prerouting priority -100 \; }

# 3. Thêm quy tắc redirect
sudo nft add rule ip nat prerouting iifname "eth1" tcp dport 80 redirect to :3128

Khởi động và kiểm tra (HTTP)

Bước 4: Thử thách HTTPS và làm rõ thuật ngữ SslBump

Bạn sẽ nhận ra rằng các trang HTTPS (như Google, Facebook) sẽ không hoạt động. Traffic HTTPS (port 443) được mã hóa và không thể REDIRECT đến cổng 3128 (HTTP) được.

Để xử lý HTTPS, Squid cung cấp một tính năng (feature) gọi là SslBump.

Quan trọng: SslBump có nhiều chế độ (mode) hoạt động:

  1. Chế độ MITM (Man-in-the-Middle): Chế độ cũ (client-first). Squid giải mã, đọc nội dung, rồi mã hóa lại. Chế độ này KHÔNG trong suốt vì yêu cầu tất cả client phải cài đặt chứng chỉ CA “giả” của Squid.
  2. Chế độ “Peek and Splice” (Lén nhìn và nối): Chế độ mới (peek-n-splice) mà chúng ta sẽ dùng.

“Peek and Splice” hoạt động:

  1. Squid “nhìn trộm” (peek) gói tin SNI chưa bị mã hóa để biết client muốn đi đâu (ví dụ: google.com).
  2. Sau đó, Squid “nối” (splice) kết nối thẳng đến google.com.
  3. Client nhận được chứng chỉ “xịn” của Google và không hề hay biết Squid vừa làm trung gian. Đây mới là “trong suốt” thực sự.

Bước 5: Cấu hình Squid cho ‘Peek and Splice’ (HTTPS)

Chúng ta cần một cổng riêng (ví dụ 3129) để xử lý HTTPS.

Tạo chứng chỉ SSL tự ký (Self-Signed)

Squid cần một chứng chỉ (dù là tự ký) để có thể thực hiện thao tác “peek” gói tin SSL.

# Tạo thư mục chứa cert
sudo mkdir -p /etc/squid/ssl
cd /etc/squid/ssl

# Tạo key và cert tự ký, có hiệu lực 10 năm
sudo openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
-keyout squid.key -out squid.crt

Bạn sẽ được hỏi một số thông tin, có thể nhập tự do.

Khởi tạo Database SSL của Squid

Squid cần một thư mục database để quản lý các chứng chỉ động.

# Xóa database cũ (nếu có)
sudo rm -rf /var/spool/squid/ssl_db

# Tìm đường dẫn chính xác của helper (trên Ubuntu)
# (Trên CentOS 7 thường là /usr/lib64/squid/)
sudo /usr/lib/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 4MB

# Cấp quyền cho thư mục database
# Trên Ubuntu
sudo chown -R proxy:proxy /var/spool/squid/ssl_db
# Trên CentOS (bỏ dấu # nếu dùng CentOS)
# sudo chown -R squid:squid /var/spool/squid/ssl_db

Lưu ý: Nếu không tìm thấy security_file_certgen, hãy dùng find / -name security_file_certgen để tìm.

Cập nhật squid.conf cho “Peek and Splice”

Mở lại file cấu hình: sudo nano /etc/squid/squid.conf

Lưu file cấu hình và thoát. Hãy đảm bảo http_access deny CONNECT !SSL_ports nằm trước http_access allow localnet.

Bước 6: Cập nhật Tường lửa cho Port 443

Bây giờ, chúng ta chuyển hướng traffic HTTPS (port 443) đến cổng 3129 mới của Squid.

Dùng Iptables (Ubuntu/Debian)

# Thêm quy tắc mới cho port 443 (trên card eth1), trỏ về 3129
sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3129

# Lưu lại
sudo netfilter-persistent save

Dùng Firewalld (CentOS/RHEL)

# Thêm quy tắc chuyển hướng (REDIRECT) vĩnh viễn cho port 443
sudo firewall-cmd --permanent --zone=internal --add-redirect=port=443:proto=tcp:toport=3129

# Tải lại
sudo firewall-cmd --reload

Dùng Nftables (Hiện đại)

# Thêm quy tắc redirect cho port 443 (vào bảng 'nat' đã tạo ở Bước 3.3)
sudo nft add rule ip nat prerouting iifname "eth1" tcp dport 443 redirect to :3129

Xử lý SELinux (Chỉ dành cho CentOS/RHEL)

SELinux sẽ chặn Squid kết nối vào các cổng 3128, 3129. Chúng ta cần cho phép nó.

# Cài đặt công cụ 'semanage'
sudo yum install -y policycoreutils-python-utils

# "Dạy" SELinux rằng 2 cổng này là cổng của Squid
sudo semanage port -a -t squid_port_t -p tcp 3128
sudo semanage port -a -t squid_port_t -p tcp 3129

Khởi động lại và kiểm tra (HTTPS)

Bảng so sánh cấu hình (Ubuntu vs. CentOS vs. Nftables)

Tính năng Ubuntu (22.04) CentOS 7 Nftables (Hiện đại)
User chạy Squid proxy squid Tùy distro
Path SSL Helper /usr/lib/squid/... /usr/lib64/squid/... Tùy distro
Tường lửa (Cũ) iptables firewalld nft (thay thế cả hai)
Redirect HTTP ... -j REDIRECT --to-port 3128 ... --add-redirect=port=80:proto=tcp:toport=3128 ... redirect to :3128
Redirect HTTPS ... -j REDIRECT --to-port 3129 ... --add-redirect=port=443:proto=tcp:toport=3129 ... redirect to :3129
Vấn đề SELinux Không Bắt buộc (Phải chạy semanage port ...) Bắt buộc (Nếu bật)

Gỡ lỗi (Troubleshooting)

Câu hỏi thường gặp (FAQ)

1. Squid Transparent Proxy là gì?

Đây là một máy chủ proxy tự động chặn và chuyển hướng traffic mạng (như truy cập web) mà không đòi hỏi bất kỳ cấu hình nào từ phía máy người dùng (client). Người dùng thậm chí không biết họ đang truy cập Internet thông qua proxy.

2. Tại sao tôi không cần cài đặt chứng chỉ CA trên máy client?

Vì chúng ta sử dụng chế độ “Peek and Splice”. Ở chế độ này, Squid chỉ “nhìn trộm” (peek) địa chỉ website mà client muốn đến (ví dụ: google.com), sau đó “nối” (splice) kết nối thẳng tới máy chủ Google. Trình duyệt của bạn nhận được chứng chỉ “xịn” trực tiếp từ Google, do đó không có cảnh báo bảo mật và không cần cài CA.

3. Cấu hình này có hỗ trợ WebSocket (WS) hoặc SPDY không?

Không. Đây là một trong những nhược điểm lớn nhất của phương pháp Interception Proxy. Nó sẽ làm hỏng các kết nối sử dụng WebSocket (thường dùng trong chat trực tiếp, game) và các giao thức nâng cao khác.

4. Tôi có thể yêu cầu User/Password (xác thực) với proxy này không?

Không. Vì trình duyệt của client không biết nó đang nói chuyện với proxy (nó nghĩ đang nói chuyện với web server gốc), nó sẽ không bao giờ gửi thông tin xác thực proxy.

5. Lệnh intercept và transparent trong squid.conf khác gì nhau?

Chúng về cơ bản là giống nhau. transparent là chỉ thị cũ dùng trong Squid 3.x. intercept là chỉ thị hiện đại, được khuyến nghị sử dụng cho các phiên bản Squid mới khi cấu hình proxy trong suốt.

6. Tại sao tôi bị lỗi “Timeout” (Hết giờ) khi truy cập web?

Đây là lỗi phổ biến nhất và thường do 3 nguyên nhân:

7. Lỗi Permission Denied (Từ chối truy cập) khi Squid khởi động?

Lỗi này rất phổ biến trên CentOS/RHEL. Đó là do SELinux đang chặn Squid truy cập vào các cổng 3128, 3129. Bạn bắt buộc phải chạy lệnh semanage port (như ở Bước 6.4) để cho phép các cổng này.

Kết luận

Chúc mừng! Bạn vừa hoàn thành một trong những cấu hình phức tạp nhưng mạnh mẽ nhất của Squid. Bằng cách kết hợp intercept của Squid, REDIRECT của tường lửa, và chế độ Peek and Splice của SslBump, bạn đã xây dựng thành công một Squid Transparent Proxy thực thụ.

Hệ thống này cho phép bạn kiểm soát traffic mạng mà không cần can thiệp từ phía người dùng. Tuy nhiên, hãy luôn ghi nhớ các nhược điểm (như không tương thích WebSocket) trước khi triển khai trong môi trường production.

Để chạy một proxy hiệu suất cao, ổn định, bạn cần một nền tảng VPS mạnh mẽ. Hãy tham khảo các gói VPS Linux tốc độ cao của ZingServer để triển khai hệ thống gateway của riêng bạn ngay hôm nay! Bạn có thể tham khảo tối ưu VPS Ubuntu 24.04 với Checklist 11+ bước quan trọng để bắt đầu.

Tài liệu tham khảo

Exit mobile version