Bảo mật kết nối chi nhánh mà không tốn ‘chi phí bản quyền đắt đỏ’
Việc kết nối nhiều văn phòng thường khiến các đội ngũ hạ tầng tìm đến các thiết bị phần cứng độc quyền đắt tiền. Mặc dù các thiết bị của Cisco hay Fortinet rất ổn định, nhưng phí bản quyền cho các tính năng truyền tải dữ liệu cao có thể dễ dàng vượt quá 2.000 USD mỗi năm cho mỗi node.
Năm ngoái, tôi đã chuyển đổi hạ tầng cốt lõi của mình sang Site-to-Site VPN dựa trên StrongSwan. Chạy trên các node Ubuntu tiêu chuẩn, hệ thống này hiện đang xử lý 850 Mbps lưu lượng sao lưu cơ sở dữ liệu liên tục và lưu lượng VoIP giữa trung tâm dữ liệu chính và ba chi nhánh khu vực. Chúng tôi chưa gặp phải bất kỳ một phút thời gian chết ngoài dự kiến nào kể từ khi chuyển đổi.
StrongSwan là tiêu chuẩn công nghiệp cho IPsec trên Linux. Bằng cách sử dụng giao thức IKEv2 (Internet Key Exchange phiên bản 2), nó cung cấp mức độ phục hồi mà các thiết lập IKEv1 cũ đơn giản là không thể sánh được. Nó phục hồi sau khi mất kết nối ISP tạm thời trong vài mili giây và xử lý NAT traversal mà không cần các giải pháp thay thế phức tạp. Nếu bạn đang quản lý các máy chủ Linux và cần kết nối các mạng con qua internet công cộng, phương pháp này cung cấp một đường truyền cấp độ chuyên nghiệp mà không bị phụ thuộc vào nhà cung cấp (vendor lock-in).
Điều kiện tiên quyết và Sơ đồ mạng
Để thực hiện theo hướng dẫn này, bạn sẽ cần hai thực thể Linux—lý tưởng nhất là Ubuntu 22.04 hoặc Debian 12. Đối với một tunnel thực tế xử lý trên 500 Mbps, tôi khuyên dùng ít nhất 2 vCPU và 4GB RAM. Ví dụ của chúng ta sử dụng sơ đồ sau:
- Site A (Trụ sở chính):
- IP công cộng:
1.2.3.4 - Mạng con nội bộ (Private Subnet):
192.168.10.0/24
- IP công cộng:
- Site B (Chi nhánh):
- IP công cộng:
5.6.7.8 - Mạng con nội bộ (Private Subnet):
192.168.20.0/24
- IP công cộng:
Trước tiên, hãy xác minh rằng tính năng IP forwarding đã được kích hoạt. Nếu không có tính năng này, máy chủ của bạn sẽ nhận được các gói tin đã mã hóa nhưng sẽ không biết cách chuyển chúng vào mạng nội bộ. Kiểm tra trạng thái hiện tại bằng lệnh sysctl net.ipv4.ip_forward. Nếu kết quả trả về là 0, hãy kích hoạt nó vĩnh viễn.
# Kích hoạt chuyển tiếp IPv4 ngay lập tức
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Bước 1: Cài đặt bộ công cụ StrongSwan
Việc cài đặt phần mềm lên hệ thống chỉ mất chưa đầy hai phút. Chúng ta sẽ cài đặt gói StrongSwan cốt lõi cùng với backend charon-systemd. Điều này cho phép chúng ta sử dụng swanctl, một công cụ cấu hình hiện đại, dễ đọc và có tính mô-đun cao hơn nhiều so với các tệp ipsec.conf cũ trong các bài hướng dẫn trước đây.
sudo apt update
sudo apt install strongswan libcharon-extra-plugins libcharon-extauth-plugins strongswan-swanctl
Dịch vụ sẽ tự động khởi chạy sau khi cài đặt. Tuy nhiên, tôi thường để các tunnel ở trạng thái tắt cho đến khi cấu hình được xác thực đầy đủ để tránh làm tràn nhật ký (log) bằng các nỗ lực bắt tay thất bại.
Bước 2: Xây dựng cấu hình Tunnel
Chúng ta sẽ bắt đầu với Site A. Cấu hình cho Site B sẽ là một bản sao đối xứng về mặt logic. Tạo một tệp mới trong thư mục swanctl để định nghĩa phiên IKEv2 và bộ chọn lưu lượng (traffic selectors) của bạn.
# Tạo cấu hình trên Site A
sudo nano /etc/swanctl/conf.d/hq-to-branch.conf
Dán đoạn mã sau vào tệp. Chúng ta sử dụng Pre-Shared Key (PSK) ở đây để đơn giản hóa, mặc dù chứng chỉ RSA sẽ tốt hơn cho các triển khai quy mô lớn với nhiều điểm cuối.
connections {
hq-to-branch {
remote_addrs = 5.6.7.8
local_addrs = 1.2.3.4
local {
auth = psk
id = 1.2.3.4
}
remote {
auth = psk
id = 5.6.7.8
}
children {
net-to-net {
local_ts = 192.168.10.0/24
remote_ts = 192.168.20.0/24
esp_proposals = aes256-sha256-modp2048
start_action = trap
}
}
version = 2
proposals = aes256-sha256-modp2048
}
}
Hãy chú ý đến các proposal: Chuỗi aes256-sha256-modp2048 là cái bắt tay mã hóa của bạn. Cả hai phía phải thống nhất chính xác chuỗi này. Thiết lập start_action = trap là cực kỳ quan trọng đối với môi trường thực tế; nó yêu cầu nhân Linux tự động kích hoạt VPN ngay khi một máy chủ nội bộ cố gắng ping đến mạng con từ xa.
Bảo mật khóa chia sẻ (Shared Secret)
Lưu trữ PSK của bạn trong một tệp bí mật riêng biệt. Tránh sử dụng các mật khẩu đơn giản; một chuỗi ngẫu nhiên 64 ký tự là mức tối thiểu cho các môi trường vận hành thực tế.
sudo nano /etc/swanctl/conf.d/secrets.conf
secrets {
ike-hq-branch {
id-1 = 1.2.3.4
id-2 = 5.6.7.8
secret = "V3ry_Str0ng_R4ndom_K3y_Th4t_Is_Unique"
}
}
Bây giờ, hãy lặp lại việc này trên Site B. Đơn giản chỉ cần hoán đổi địa chỉ IP local, remote và các mạng con. Khóa bí mật (secret) phải giống hệt nhau trên cả hai máy chủ.
Bước 3: Quy tắc tường lửa và ‘kẻ sát nhân thầm lặng’ MSS
Nhiều quản trị viên gặp rắc rối ở đây. Bạn phải mở các cổng UDP 500 và 4500 trên giao diện công cộng. Hơn nữa, bạn cần yêu cầu tường lửa nội bộ tin tưởng lưu lượng đến từ mạng con từ xa.
# Mở các cổng IKE và NAT-T
sudo ufw allow 500/udp
sudo ufw allow 4500/udp
# Cho phép mạng con của chi nhánh từ xa kết nối đến các dịch vụ nội bộ
sudo ufw allow from 192.168.20.0/24 to any
Có một cái bẫy tiềm ẩn: phân mảnh MTU. IPsec thêm tiêu đề (header) vào mỗi gói tin, điều này có thể đẩy chúng vượt quá giới hạn MTU 1500 byte tiêu chuẩn. Điều này thường dẫn đến việc các phiên SSH bị treo hoặc các trang web không tải được. Khắc phục điều này bằng cách giới hạn (clamping) Maximum Segment Size (MSS) thông qua iptables.
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
Bước 4: Giám sát và Kiểm tra
Sau khi các tệp đã được lưu, hãy tải lại cấu hình. swanctl cung cấp phản hồi tốt hơn nhiều so với việc khởi động lại dịch vụ thông thường.
sudo swanctl --load-all
Để xem tunnel có đang hoạt động hay không, hãy chạy lệnh --list-sas. Nó sẽ hiển thị cho bạn các liên kết bảo mật (security associations), thuật toán mã hóa và—quan trọng nhất—bộ đếm byte cho dữ liệu được truyền đi.
sudo swanctl --list-sas
Một kết quả tunnel hoạt động tốt sẽ trông như thế này:
hq-to-branch: #1, ESTABLISHED, IKEv2
local '1.2.3.4' @ 1.2.3.4[500]
remote '5.6.7.8' @ 5.6.7.8[500]
AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
net-to-net: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
local 192.168.10.0/24
remote 192.168.20.0/24
If you do not see the “ESTABLISHED” line, check the logs in real-time with journalctl -f -u strongswan. This will point out exactly where the negotiation is failing, whether it’s due to a key mismatch or a blocked port. In my experience, 90% of failures are due to firewall oversight or errors in typing the remote IP address.
A few words on stability
After six months of heavy use, the self-healing capability of IKEv2 is the standout feature. When our ISP performs maintenance at 3 AM, StrongSwan’s Dead Peer Detection (DPD) feature detects the issue and re-establishes the tunnel as soon as the line is clear. You have full control over your encryption layer, no hidden license fees, and the ability to scale bandwidth simply by resizing the virtual server. This is a big win for any lean IT operation.

