Xây dựng VPN Site-to-Site bằng pfSense: Khi hai chi nhánh cách nhau hàng trăm kilomet nhưng hoạt động như một mạng LAN

Mở đầu

Trong nhiều doanh nghiệp, việc kết nối giữa trụ sở chính và nhà máy là một nhu cầu gần như bắt buộc. File Server, NAS, ERP, Camera, VMware, Active Directory… đều cần được truy cập an toàn giữa các địa điểm khác nhau.

Giải pháp truyền thống là thuê kênh riêng (MPLS), nhưng chi phí cao và thiếu linh hoạt. Ngày nay, với một đường truyền Internet ổn định và một firewall mạnh như pfSense, doanh nghiệp hoàn toàn có thể xây dựng một hệ thống VPN Site-to-Site vừa an toàn, vừa tiết kiệm chi phí.

Trong bài viết này, mình chia sẻ lại quá trình triển khai thực tế kết nối hai chi nhánh bằng OpenVPN Site-to-Site trên pfSense CE 2.8.1.

Đây không phải là bài viết lý thuyết. Toàn bộ nội dung được đúc kết từ quá trình triển khai, kiểm thử và đưa vào vận hành.


Mục tiêu của dự án

Mục tiêu đặt ra ngay từ đầu rất rõ ràng:

  • Kết nối hai hệ thống mạng LAN qua Internet.
  • Không thay đổi hạ tầng Internet hiện có.
  • Không ảnh hưởng đến người dùng đang làm việc.
  • Đảm bảo tốc độ và độ ổn định.
  • Sẵn sàng cho việc đồng bộ dữ liệu NAS giữa hai chi nhánh.
  • Chi phí thấp nhưng dễ bảo trì.

Mô hình triển khai

INTERNET
|
+-- CTY2
| DrayTek 2927
| |
| pfSense CE 2.8.1
| OpenVPN Server
| |
| LAN 192.168.1.0/24
|
+-- HLA
DrayTek 2925
|
pfSense CE 2.8.1
OpenVPN Client
|
LAN 172.16.0.0/16

OpenVPN Tunnel: 10.250.250.0/24

Thiết bị sử dụng

Thiết bịCTY2HLA
FirewallpfSense CE 2.8.1pfSense CE 2.8.1
RouterDrayTek 2927DrayTek 2925
HypervisorProxmox VEVMware ESXi
VPNOpenVPN Site-to-SiteOpenVPN Client
Tunnel10.250.250.0/2410.250.250.0/24

Những gì diễn ra không giống tài liệu…

Điều thú vị là VPN kết nối ngay từ lần cấu hình đầu tiên.

Trạng thái trên pfSense hiển thị:

  • Client Connected
  • Tunnel UP
  • Ping giữa hai đầu Tunnel thành công

Tưởng như mọi thứ đã hoàn tất.

Nhưng…

Máy tính tại CTY2 không ping được sang HLA.

Máy tại HLA cũng không ping ngược lại.

Lúc này rất nhiều người sẽ nghĩ:

  • Firewall sai?
  • OpenVPN lỗi?
  • Route chưa đúng?
  • NAT có vấn đề?

Thực tế… không phải.


Thủ phạm thật sự

Sau nhiều lần kiểm tra Route Table, Packet Capture và tcpdump, nguyên nhân được xác định rất nhanh:

Gateway mặc định của máy người dùng không đi qua pfSense.

Ví dụ:

Windows tại CTY2

Gateway: 192.168.1.1

Trong khi VPN nằm trên

192.168.1.2

Windows luôn gửi lưu lượng về Router Internet.

Không bao giờ gửi qua pfSense.

VPN vẫn hoạt động.

Nhưng máy người dùng không hề đi vào VPN.


Giải pháp đơn giản hơn rất nhiều

Thay vì:

  • đổi Gateway toàn công ty
  • thay Router
  • sửa VLAN
  • sửa NAT

Mình chỉ thêm Static Route.

CTY2

route -p add 172.16.0.0 mask 255.255.0.0 192.168.1.2

HLA

route -p add 192.168.1.0 mask 255.255.255.0 172.16.28.1

Ngay lập tức:

✅ Ping thành công.

✅ Truy cập NAS.

✅ Truy cập VMware.

✅ Không đổi Gateway.

✅ Không ảnh hưởng Internet.


Điều mình thích nhất

Toàn bộ người dùng vẫn sử dụng Internet như trước.

Không ai biết phía sau vừa có thêm một VPN Site-to-Site.

Không phải đổi DNS.

Không phải đổi ISP.

Không phải đổi Gateway.

Chỉ những lưu lượng đi tới mạng nội bộ mới được chuyển qua VPN.

Đó chính là điều mình mong muốn khi thiết kế hạ tầng doanh nghiệp.


Backup là bước không thể bỏ qua

Sau khi hệ thống chạy ổn định, việc đầu tiên mình làm không phải tối ưu.

Mà là…

Backup toàn bộ cấu hình pfSense.

Một file XML chỉ vài MB.

Nhưng có thể giúp khôi phục toàn bộ Firewall trong vài phút nếu xảy ra sự cố.


Bài học rút ra

Sau nhiều năm triển khai hạ tầng CNTT, mình nhận ra một điều:

Một hệ thống tốt không phải là hệ thống có cấu hình phức tạp nhất.

Mà là hệ thống:

  • Dễ hiểu.
  • Dễ bảo trì.
  • Dễ khôi phục.
  • Ít thay đổi nhất.

Trong dự án này, thay vì thay đổi toàn bộ kiến trúc mạng, chỉ cần thêm hai dòng Static Route là mọi thứ hoạt động đúng như mong muốn.

Đó mới là giá trị của người thiết kế hệ thống.


Kết luận

pfSense không chỉ là một Firewall mã nguồn mở.

Nếu được triển khai đúng cách, nó hoàn toàn có thể trở thành trung tâm kết nối giữa nhiều chi nhánh với chi phí thấp nhưng vẫn đảm bảo:

  • VPN bảo mật.
  • Hiệu năng ổn định.
  • Dễ mở rộng.
  • Dễ sao lưu.
  • Dễ bảo trì.

Điều quan trọng nhất mình học được từ dự án này không phải là cách cấu hình OpenVPN.

Mà là một nguyên tắc rất đơn giản:

Khi hệ thống đã chạy ổn định, đừng thay đổi chỉ vì muốn nó “hoàn hảo hơn”.

Trong môi trường doanh nghiệp, ổn định luôn quan trọng hơn phức tạp.


Lời kết

Nếu bạn cũng đang triển khai hạ tầng cho doanh nghiệp và gặp những tình huống tương tự, hy vọng bài viết này sẽ giúp bạn tiết kiệm được nhiều thời gian thử nghiệm. Trong các bài tiếp theo trên nhanthang.com, mình sẽ tiếp tục chia sẻ những kinh nghiệm thực tế về pfSense, VMware, Proxmox, Synology NAS, Windows Server và các giải pháp hạ tầng doanh nghiệp mà mình đã trực tiếp triển khai và vận hành. Chúng ta cùng học từ những dự án thật, những vấn đề thật và những giải pháp đã được kiểm chứng.