Site icon ZingServer

Cách tạo proxy IPv6 trên VPS Linux chuyên sâu cho Load Testing

Team ZingServer
Hướng dẫn kỹ thuật tạo Proxy IPv6 trên VPS Linux phục vụ Load Testing chuyên sâu.

Xây dựng hạ tầng Proxy nội bộ doanh nghiệp: Giải pháp tối ưu chi phí và hiệu năng cho QA/DevOps.

Hãy thử hình dung kịch bản này: Đội QA/QC của bạn vừa hoàn thiện một kịch bản stress test API bằng Apache JMeter hoặc Grafana k6. Bạn cấu hình 10.000 virtual users (VU) chạy đồng thời, nhấn Start và chờ đợi hệ thống trả kết quả throughput. Thế nhưng chỉ vỏn vẹn 10 giây sau, console đỏ rực lỗi. 99% request trả về mã 429 Too Many Requests, 403 Forbidden hoặc các kết nối bị đóng cưỡng bức (TCP Reset). Hệ thống đích không hề sập, mà đơn giản là các lớp bảo mật như Cloudflare, AWS WAF, hay API Gateway đã kích hoạt cơ chế Rate-Limiting dựa trên IP nguồn để ngăn chặn DoS.

Đây là một điểm nghẽn (bottleneck) giả mà mọi kỹ sư hạ tầng đều phải đối mặt. Để đánh giá chính xác ngưỡng chịu tải thực tế của ứng dụng, developer bắt buộc phải xoay vòng IP (IP rotation) nhằm giả lập traffic phân tán. Thuê proxy IPv4 thì chi phí quá đắt đỏ, trong khi đó, dải IPv6 Subnet /64 (cung cấp hơn 18 tỷ tỷ địa chỉ IP) đi kèm miễn phí trên các máy chủ Linux lại là một mỏ vàng chưa được khai thác hết.

Việc ứng dụng kỹ thuật tạo proxy IPv6 trên VPS nội bộ sẽ giải quyết trọn vẹn bài toán này. Dưới đây là tài liệu kỹ thuật chuyên sâu, mổ xẻ từng ngóc ngách từ tầng Kernel OS, cấu hình 3proxy, tích hợp tool test, cho đến cách đọc log gỡ lỗi để bạn tự tay xây dựng một hệ thống proxy pool chịu tải hàng vạn request/giây.

Cơ chế xoay vòng IP (IP Rotation) giúp traffic Load Test đi xuyên qua rào cản WAF dễ dàng.

Điều kiện tiên quyết trước khi triển khai hệ thống

Đừng vội vàng gõ lệnh cấu hình khi chưa xác minh hạ tầng mạng ở hai đầu nguồn và đích. Việc thiếu đồng bộ giao thức sẽ khiến toàn bộ pool proxy trở nên vô dụng.

Target server bắt buộc phải có bản ghi AAAA (Dual-stack)

Khi bạn cấu hình proxy với cờ outbound IPv6, tiến trình proxy sẽ định tuyến gói tin qua hạ tầng IPv6 thuần túy. Nếu hệ thống API/Staging đích của bạn chỉ chạy IPv4 (chỉ có bản ghi DNS loại A), tầng network sẽ ngay lập tức trả về lỗi No route to host hoặc Network unreachable.

Giải pháp: Yêu cầu team DevOps cấu hình bản ghi AAAA cho domain đích. Đồng thời, Load Balancer (ALB/NLB) hoặc Nginx Ingress của bạn phải được thiết lập chế độ Dual-stack. Trước khi bắt đầu, hãy đứng từ VPS và chạy lệnh:

curl -6 -I https://api.staging.domain.com

Nếu trả về HTTP 200/404 thay vì lỗi phân giải, bạn đã sẵn sàng.

Lựa chọn VPS và rủi ro MAC spoofing

Thực chiến 5 bước tạo proxy IPv6 trên VPS Linux

Quy trình dưới đây được thiết kế tối ưu hóa sức chịu tải. Một sai lầm nhỏ ở thông số OS cũng có thể khiến VPS sập nguồn (Kernel Panic) khi nhận tải đột ngột.

Bước 1: Tinh chỉnh Kernel Linux và xử lý triệt để Ulimit

Mặc định, TCP stack của Linux không được thiết kế để mở hàng chục ngàn socket đồng thời. Chúng ta cần can thiệp sâu vào kernel parameters. Mở file bằng lệnh sudo nano /etc/sysctl.conf và thêm cấu hình:

# Bật tính năng chuyển tiếp gói tin (IP Forwarding)
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv4.ip_forward = 1

# [QUAN TRỌNG NHẤT] Cho phép ứng dụng bind các IP ảo chưa được gán tĩnh trên interface
net.ipv6.ip_nonlocal_bind = 1

# Bật Proxy NDP để hệ thống thay mặt router phản hồi truy vấn Neighbor Solicitation
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.default.proxy_ndp = 1

# Tối ưu TCP queue, chống cạn kiệt ephemeral ports
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.netdev_max_backlog = 65535

Tham số net.ipv6.ip_nonlocal_bind = 1 là trái tim của hệ thống. Nó cho phép công cụ 3proxy sử dụng bất kỳ IP nào trong dải 18 tỷ tỷ IP ảo mà không cần sysadmin phải add tĩnh (hardcode) từng IP đó vào file config network của hệ điều hành.

Chạy lệnh để apply cấu hình:

sudo sysctl -p

Giải quyết triệt để File Descriptors (Ulimit):

Mỗi socket mạng được Linux xem như một file descriptor. Giới hạn mặc định 1024 file sẽ khiến proxy mất kết nối trong 1 giây đầu tiên của bài load test.

Đầu tiên, sửa file /etc/security/limits.conf:

* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576

Tiếp theo, bắt buộc phải gõ lệnh này trực tiếp vào terminal để cấp quyền ngay lập tức cho session SSH hiện tại (nếu bỏ qua, bạn phải logout và login lại):

ulimit -n 1048576

Bước 2: Setup ndppd (Neighbor Discovery Protocol proxy)

Giao thức NDP thay thế hoàn toàn ARP trong IPv4. Khi bạn gửi traffic từ một IP ảo, ndppd sẽ tự động trả lời truy vấn L2 từ switch của datacenter để định tuyến traffic trả về đúng máy chủ.

Cài đặt daemon:

sudo apt update && sudo apt install ndppd -y

Tạo file cấu hình sudo nano /etc/ndppd.conf (Thay dải subnet và tên card mạng eth0 phù hợp với thông số của bạn qua lệnh ip a):

proxy eth0 {
    rule 2001:0db8:1234:5678::/64 {
        static
    }
}

Kích hoạt và khởi chạy service ngầm:

sudo systemctl enable ndppd
sudo systemctl start ndppd

Bước 3: Build 3proxy và mổ xẻ kịch bản sinh cấu hình

Chúng ta sử dụng 3proxy thay vì Squid vì footprint RAM của 3proxy cực kỳ nhỏ, khả năng ánh xạ port (port mapping) nội bộ ra external IP cực kỳ linh hoạt. Để tránh các lỗi tương thích, hãy build trực tiếp từ source code mới nhất:

sudo apt install build-essential git python3 -y
cd /opt
git clone https://github.com/3proxy/3proxy.git
cd 3proxy
make -f Makefile.Linux
sudo make -f Makefile.Linux install

Sử dụng script Python dưới đây để tự động sinh file cấu hình. Ý tưởng là tạo ra 1.000 port IPv4 nội bộ (từ 30001 đến 31000), mỗi port sẽ định tuyến ra một địa chỉ IPv6 duy nhất. Tạo file /opt/3proxy/gen_config.py:

import ipaddress

# Thay bằng prefix dải /64 của VPS
IPV6_PREFIX = "2001:0db8:1234:5678"  
START_PORT = 30000                   
NUM_PROXIES = 1000                   
PROXY_USER = "qateam"                
PROXY_PASS = "ComplexPass2024!@"         

config = f"""
daemon
maxconn 10000
nserver 8.8.8.8
nserver 2001:4860:4860::8888
nscache 65536
timeouts 1 5 30 60 180 1800 15 60

# Bật module xác thực cơ bản
auth strong
users {PROXY_USER}:CL:{PROXY_PASS}
allow {PROXY_USER}

log /var/log/3proxy.log D
logformat "- +_L%t.%.  %N.%p %E %U %C:%c %R:%r %O %I %h %T"
flush
"""

for i in range(1, NUM_PROXIES + 1):
    port = START_PORT + i
    hex_suffix = format(i, 'x')
    ipv6_out = f"{IPV6_PREFIX}::{hex_suffix}"
    
    # Cấu trúc lệnh: proxy [tùy chọn] -p[Port_Lắng_Nghe] -i[IP_Nhận] -e[IP_Xuất]
    config += f"proxy -6 -n -a -p{port} -i0.0.0.0 -e{ipv6_out}\n"

with open("/etc/3proxy/3proxy.cfg", "w") as f:
    f.write(config)

print("Hoàn tất tạo file /etc/3proxy/3proxy.cfg")

Mổ xẻ chuyên sâu tham số 3proxy:

Tạo thư mục và chạy script:

sudo mkdir -p /etc/3proxy
python3 gen_config.py
Luồng xử lý của 3proxy: Chuyển đổi traffic từ port IPv4 sang các địa chỉ IPv6 ảo biệt lập.

Bước 4: Security hardening (UFW & Fail2Ban)

Việc mở 1.000 port ra internet (dù có password) sẽ thu hút các công cụ rà soát mạng. Nếu bị bruteforce (dò mật khẩu) liên tục, CPU của VPS sẽ duy trì ở mức 100%.

1. Chỉ định IP truy cập bằng UFW:

sudo ufw enable
sudo ufw default deny incoming
sudo ufw allow ssh
# Chỉ cho phép IP tĩnh của văn phòng/máy chạy tool test
sudo ufw allow from IP_MAY_TEST to any port 30001:31000 proto tcp
sudo ufw reload

2. [Nâng cao] Chống Bruteforce với Fail2Ban:

Nếu team của bạn làm việc remote và dùng IP động, UFW sẽ gây bất tiện. Thay vào đó, hãy cài Fail2Ban để block các IP gõ sai mật khẩu proxy quá 3 lần.

sudo apt install fail2ban -y

Tạo file filter /etc/fail2ban/filter.d/3proxy.conf:

[Definition]
failregex = ^.* :\d+ .* 00000 00000 0 0 0 0.*$
ignoreregex =

Tạo jail /etc/fail2ban/jail.d/3proxy.conf:

[3proxy]
enabled = true
port = 30001:31000
filter = 3proxy
logpath = /var/log/3proxy.log
maxretry = 3
bantime = 3600

Khởi động lại Fail2Ban để hệ thống proxy của bạn được an toàn:

sudo systemctl restart fail2ban

Bước 5: Khởi động service và kiểm tra định tuyến

Khởi động tiến trình proxy chạy ngầm (nhờ cờ daemon đã khai báo trong config):

/usr/local/bin/3proxy /etc/3proxy/3proxy.cfg

Đứng từ máy chạy test, sử dụng lệnh curl để xác minh gói tin thực sự được định tuyến qua mạng IPv6:

curl -x http://qateam:ComplexPass2024!@:30001 https://ifconfig.co

Nếu output in ra màn hình là một địa chỉ dạng 2001:0db8:..., kiến trúc mạng của bạn đã hoạt động hoàn hảo.

Tích hợp proxy pool vào công cụ load testing

Hạ tầng đã xong, việc tiếp theo là bơm danh sách IP này vào pipeline sinh tải của bạn thông qua các file mẫu dưới đây.

Template cấu hình Apache JMeter

JMeter quản lý proxy pool rất mượt mà thông qua component CSV Data Set Config.

  1. Tạo file proxies.csv tại thư mục chứa file .jmx. Cột duy nhất điền từ 30001 kéo dài đến 31000.
  2. Add CSV Data Set Config vào Thread Group:
    • Filename: proxies.csv
    • Variable Names: proxy_port
    • Recycle on EOF: True (Cho phép quay vòng proxy khi hết list).
  3. Tại HTTP Request Defaults, chuyển sang tab Advanced. Cấu hình phần Proxy:
    • Server Name: <IP_VPS_CUA_BAN>
    • Port: ${proxy_port}
    • Username: qateam
    • Password: ComplexPass2024!@
  4. Java DNS Tweaks: JMeter chạy trên nền tảng Java Virtual Machine (JVM). Mặc định, JVM thường cache DNS hoặc ưu tiên IPv4. Hãy mở file system.properties nằm trong thư mục bin, thêm dòng sau rồi khởi động lại GUI:
java.net.preferIPv4Stack=false
java.net.preferIPv6Addresses=true

Tránh lỗi Self-DDoS trên Grafana k6 bằng xk6-proxy

Trong Grafana k6, một sai lầm nghiêm trọng là dùng bash script sinh ra hàng trăm tiến trình ngầm (Ví dụ: HTTP_PROXY=... k6 run script.js &). Mỗi tiến trình này khởi tạo một bộ biên dịch JavaScript (Goja runtime) độc lập. Nếu bạn chạy 500 process, máy chủ test sẽ lập tức cạn kiệt hàng chục GB RAM, gây ra hiện tượng tự đánh sập chính mình (Self-DDoS). Bản thân engine k6 mặc định không hỗ trợ luân chuyển nhiều proxy qua lại trong cùng một kịch bản JS.

Giải pháp chuyên sâu: Bạn phải biên dịch lại binary k6 và nhúng thêm module xk6-proxy của cộng đồng (Module can thiệp trực tiếp vào Transport Layer của Golang).

Biên dịch k6 (Yêu cầu cài sẵn Golang):

go install go.k6.io/xk6/cmd/xk6@latest
xk6 build --with github.com/grafana/xk6-proxy

Sử dụng file binary ./k6 vừa tạo, áp dụng đoạn script template sau để xoay vòng proxy an toàn trên một single-process:

import http from 'k6/http';
import { check, sleep } from 'k6';
// Import module xk6-proxy đã build
import { setProxy } from 'k6/x/proxy'; 

// Khởi tạo danh sách proxy URL (Bạn có thể load từ external file JSON)
const proxyList = [
    'http://qateam:ComplexPass2024!@@198.51.100.1:30001',
    'http://qateam:ComplexPass2024!@@198.51.100.1:30002',
    // ... Thêm đến 31000
];

export const options = {
    vus: 1000, 
    duration: '5m',
};

export default function () {
    // Thuật toán chia proxy đều đặn (Round-robin) dựa trên ID ảo
    const proxyUrl = proxyList[__VU % proxyList.length];
    
    // Gán proxy vào request context của k6
    setProxy(proxyUrl);

    const res = http.get('https://api.staging.domain.com/v1/users');
    
    check(res, {
        'status is 200': (r) => r.status === 200,
    });
    sleep(1);
}

3 cạm bẫy kỹ thuật thực chiến

Lý thuyết trơn tru là một chuyện, nhưng việc đẩy tải vào các hệ thống lớn đòi hỏi sysadmin phải am hiểu luật chơi của các nhà cung cấp dịch vụ mạng.

  1. Cơ chế Request Grouping của WAF: Việc tạo ra 1.000 IP ảo từ một dải Subnet /64 không có nghĩa bạn sẽ vượt qua được các thuật toán đánh giá lưu lượng của Cloudflare hay AWS WAF. Nhằm tối ưu hiệu suất, các WAF cấp doanh nghiệp tự động áp dụng cơ chế Request Grouping. Họ nhóm toàn bộ lưu lượng đến từ dải /64 lại và coi đó là 1 địa chỉ IPv4 tương đương khi tính toán Rate-Limit. Giải pháp: Để load test chính xác trên môi trường có WAF, hãy yêu cầu Data Center định tuyến cho bạn một dải mạng cấp cao hơn (subnet /48 tương đương 65.536 dải /64). Khi đó, việc xoay vòng proxy mới thực sự hiệu quả trước các quy tắc đếm IP.
  2. Điểm nghẽn Packet Per Second (PPS): Trong load testing, mọi người thường chú ý đến băng thông tổng (Mbps) mà bỏ qua giới hạn PPS. Một yêu cầu HTTP GET nhỏ xíu chỉ tốn vài kilobyte, nhưng quá trình thiết lập và ngắt kết nối (TCP 3-way handshake) lại yêu cầu trao đổi rất nhiều gói tin (packet). Khi lượng VU tăng đột biến, card mạng ảo trên VPS cloud có cấu hình thấp sẽ đụng trần cấu hình PPS giới hạn của nhà mạng, dẫn tới việc tự động loại bỏ gói tin (Drop packet). Hiện tượng này biểu hiện bằng việc CPU VPS rất thấp (chỉ 20%) nhưng tool test lại liên tục báo Connection Timeout.
  3. Giao thức bị hạ cấp (Protocol Downgrade): Nếu cấu hình TLS của proxy hoặc target server không tương thích, quá trình bắt tay SSL sẽ thất bại hoặc mất quá nhiều thời gian, làm sai lệch metric đo lường Response Time. Luôn kiểm tra cipher suites hỗ trợ ở cả hai đầu.
Cơ chế của WAF: 18 tỷ tỷ IPv6 trong dải /64 chỉ được hệ thống phân tích tương đương với 1 IP duy nhất.

Troubleshooting: Đọc log và bắt bệnh hệ thống

Giám sát tài nguyên theo thời gian thực và am hiểu log OS là kỹ năng cốt lõi của kỹ sư hạ tầng. Mở song song một terminal và sử dụng các công cụ sau:

Phân tích log của 3proxy:

Truy cập /var/log/3proxy.log.

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

1. Tại sao nên dùng IPv6 thay vì IPv4 cho Load Testing?

Tiết kiệm đáng kể chi phí hạ tầng. Dải IPv6 /64 cung cấp tới 18 tỷ tỷ IP, cho phép bạn giả lập hàng vạn người dùng thật với các IP riêng biệt để thực hiện quá trình kiểm thử chịu tải.

2. Máy chủ đích (Target Server) chỉ có IPv4, tôi có dùng được hệ thống này không?

KHÔNG. Request từ proxy đi ra bằng IPv6 nên server đích bắt buộc phải nhận được IPv6. Bạn có thể tham khảo thêm cách cấu hình IPv6 cho VPS (Dual-stack) để giải quyết bài toán chi phí IP cho server đích.

3. Tỷ lệ ánh xạ (mapping) bao nhiêu proxy là đủ cho 10.000 VU?

Khuyến nghị tỷ lệ 1:1 hoặc tối thiểu 1:2 (5.000 IP cho 10.000 VU). Điều này giúp mỗi IP chỉ gửi khoảng 1-2 request/giây, mô phỏng chính xác lưu lượng truy cập thực tế.

4. Tại sao tôi đã sửa limits.conf nhưng vẫn bị lỗi Too many open files?

Do file cấu hình chỉ có tác dụng khi bạn đăng nhập mới. Cách xử lý: Gõ trực tiếp lệnh dưới đây vào terminal đang chạy trước khi khởi động 3proxy để áp dụng ngay lập tức:

ulimit -n 1048576

5. Cần lưu ý gì quan trọng khi tạo proxy IPv6 trên VPS?

Hãy cẩn thận với cơ chế gộp dải (Request Grouping) của Cloudflare (hệ thống có thể đánh giá lưu lượng theo dải /64). Ngoài ra, hãy chọn các gói VPS Linux có băng thông mạng tốt để đảm bảo thông số PPS (Packet Per Second) không bị nghẽn khi cấu hình tải lớn.

6. Tôi có thể dùng hệ thống này để thu thập dữ liệu (data extraction) hoặc kiểm thử diện rộng không?

Được, nhưng cần lưu ý. IP từ VPS là IP Datacenter nên dễ bị các hệ thống tường lửa nhận diện. Nếu cần phân tán lưu lượng tự nhiên hơn cho việc kiểm thử, bạn có thể tham khảo thêm về các giải pháp Residential Proxy và cách chúng khác biệt so với Datacenter Proxy.

7. Tại sao nên tự build Proxy trên VPS thay vì mua dịch vụ Cloud Load Test?

Đội ngũ kỹ thuật có thể tự chủ 100% hạ tầng, bảo mật dữ liệu nội bộ và tiết kiệm chi phí vận hành mỗi tháng khi mở rộng hệ thống lên mức hàng triệu request so với việc trả phí theo lưu lượng cho bên thứ ba.

Kết luận

Việc làm chủ kỹ thuật tạo proxy IPv6 trên VPS giải quyết bài toán chi phí và giới hạn thiết kế của IPv4 truyền thống. Thông qua việc tinh chỉnh cặn kẽ Linux Kernel, tận dụng module xk6-proxy để tối ưu RAM, và hiểu sâu về cơ chế định tuyến của WAF, đội ngũ developer và QA có thể tự tin thiết lập các môi trường mô phỏng siêu chịu tải ngay trong hạ tầng nội bộ.

Mọi giới hạn kỹ thuật giờ đây có thể được kiểm soát. Hạ tầng dự án của bạn liệu có trụ vững trước bài test giới hạn 10.000 concurrent users thực sự? Đừng phỏng đoán bằng lý thuyết. Hãy áp dụng ngay những mã lệnh trên, cấu hình lưu lượng vào hệ thống và tự mình phân tích điểm bão hòa.

Tài liệu tham khảo

Exit mobile version