Tháng 11 năm ngoái, sự cố đứt cáp quang từ nhà cung cấp upstream đã làm gián đoạn đường truyền chính giữa Austin và Chicago vào lúc 2:14 sáng. Hai mươi kỹ sư đang thực hiện đợt migration PostgreSQL xuyên đêm bỗng nhiên mất hoàn toàn quyền truy cập. Tệ hơn nữa, các tunnel IPsec tĩnh vẫn nằm bất động trong khi các kỹ sư phải cuống cuồng truy cập vào cả ba gateway để sửa thủ công bảng định tuyến. Sự cố kéo dài bốn tiếng đó đã khiến chúng tôi thiệt hại khoảng 18.000 USD do thời gian ngừng trệ triển khai. Điều này cũng thúc đẩy đội ngũ hạ tầng của chúng tôi từ bỏ hoàn toàn các tuyến định tuyến tĩnh.
WireGuard kết hợp rất mượt mà với FRRouting (FRR) chạy Open Shortest Path First (OSPF). Bộ đôi này tự động phát hiện các liên kết liền kề, giám sát trạng thái kết nối bằng cơ chế heartbeat chu kỳ dưới một giây và tái định tuyến lưu lượng mà không cần can thiệp thủ công. Chúng tôi đang vận hành chính xác kiến trúc này trên toàn bộ hệ thống hybrid kết hợp giữa AWS và hạ tầng máy chủ vật lý colocation. Hiện tại, quá trình failover diễn ra trơn tru chỉ trong chưa đầy bốn giây mà không làm rớt bất kỳ gói tin nào trên các phiên TCP đang hoạt động.
Bắt đầu Nhanh: Thiết lập Tối giản giữa Hai Site trong Chưa đầy 10 Phút
Mô hình cơ bản này kết nối hai gateway chạy Ubuntu 24.04 (Site A: Trụ sở Austin và Site B: Chi nhánh Chicago) qua một tunnel điểm-điểm (point-to-point) được mã hóa cùng cơ chế trao đổi route OSPF.
1. Mô hình Mạng và Quy hoạch Địa chỉ IP
- Site A (Trụ sở): Public WAN
203.0.113.10, Local LAN10.10.0.0/24, Tunnel IP10.255.255.1/30 - Site B (Chi nhánh): Public WAN
198.51.100.20, Local LAN10.20.0.0/24, Tunnel IP10.255.255.2/30 - Hệ điều hành: Ubuntu 22.04 hoặc 24.04 LTS (kernel 5.15 trở lên)
2. Cấu hình các Tunnel WireGuard
Đầu tiên, cài đặt WireGuard và tạo cặp khóa mã hóa trên cả hai máy chủ:
sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
Tại Site A (Trụ sở), lưu cấu hình sau vào /etc/wireguard/wg0.conf. Lưu ý tùy chọn Table = off: thiết lập này ngăn wg-quick tự ý ghi đè default gateway của hệ thống khi xử lý các định nghĩa dải mạng đại diện của peer.
[Interface]
PrivateKey = <Site_A_PrivateKey>
Address = 10.255.255.1/30
ListenPort = 51820
Table = off
MTU = 1420
[Peer]
PublicKey = <Site_B_PublicKey>
Endpoint = 198.51.100.20:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 15
Tại Site B (Chi nhánh), thiết lập cấu hình tương ứng trong /etc/wireguard/wg0.conf:
[Interface]
PrivateKey = <Site_B_PrivateKey>
Address = 10.255.255.2/30
ListenPort = 51820
Table = off
MTU = 1420
[Peer]
PublicKey = <Site_A_PublicKey>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 15
Bật tính năng chuyển tiếp gói tin (packet forwarding) trong kernel và kích hoạt các tunnel:
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-router.conf
sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0
3. Khởi chạy OSPF trên FRRouting
Cài đặt bộ phần mềm FRR và kích hoạt daemon định tuyến OSPF:
sudo apt install -y frr frr-pythontools
sudo sed -i 's/ospfd=no/ospfd=yes/' /etc/frr/daemons
sudo systemctl restart frr
Mở shell tích hợp của FRR trên Site A bằng lệnh sudo vtysh, sau đó nhập các dòng lệnh cấu hình sau:
configure terminal
interface wg0
ip ospf network point-to-point
ip ospf area 0
exit
router ospf
ospf router-id 10.255.255.1
network 10.10.0.0/24 area 0
exit
do write
exit
Bây giờ, áp dụng cấu hình tương ứng trên Site B thông qua dấu nhắc sudo vtysh của site đó:
configure terminal
interface wg0
ip ospf network point-to-point
ip ospf area 0
exit
router ospf
ospf router-id 10.255.255.2
network 10.20.0.0/24 area 0
exit
do write
exit
Kiểm tra thiết lập quan hệ láng giềng (neighbor) trực tiếp từ terminal:
sudo vtysh -c "show ip ospf neighbor"
Trạng thái neighbor sẽ chuyển từ Init sang Full/ - chỉ trong vòng chưa đầy ba giây. Zebra sẽ ngay lập tức nạp subnet từ xa (10.20.0.0/24) vào bảng định tuyến kernel của Linux.
Phân Tích Chuyên Sâu: Tại Sao WireGuard Gây Xung Đột Với Định Tuyến Động Truyền Thống
WireGuard không hoạt động giống như một interface TUN hoặc GRE ảo tiêu chuẩn. Nó vận hành như một cơ chế Định tuyến Khóa mã hóa (Cryptokey Routing). Các gói tin gửi đi bắt buộc phải khớp với một subnet được khai báo tường minh trong AllowedIPs trước khi WireGuard tiến hành mã hóa và chuyển tiếp đến peer.
Vấn Đề Gói Tin Multicast
OSPF phụ thuộc rất lớn vào lưu lượng multicast cục bộ trên liên kết (link-local) gửi tới địa chỉ 224.0.0.5 (All OSPF Routers) và 224.0.0.6 (Designated Routers). Nhiều kỹ sư cố gắng giới hạn AllowedIPs ở các subnet cố định như 10.255.255.2/32, 10.20.0.0/24. Khi đó, WireGuard sẽ âm thầm hủy (drop) toàn bộ các gói tin multicast.
Quá trình bắt tay mã hóa (handshake) vẫn thành công. Bộ đếm gói tin trong wg show vẫn tăng đều đặn. Thế nhưng, các neighbor OSPF không bao giờ được thiết lập. Việc cấu hình AllowedIPs = 0.0.0.0/0 kết hợp với Table = off sẽ giải quyết triệt để rào cản này. Thiết lập này cho phép các gói tin multicast vượt qua bước kiểm tra mã hóa, đồng thời bàn giao toàn bộ quyết định định tuyến thực tế cho FRR.
Tại Sao Chế Độ Point-to-Point Là Bắt Buộc
Theo mặc định, OSPF sử dụng cơ chế mạng broadcast trên các interface không phải cổng serial. Trong chế độ broadcast, OSPF sẽ bầu chọn một Designated Router (DR) và Backup Designated Router (BDR). Khi triển khai trên các tunnel VPN, quá trình bầu chọn này làm phát sinh thêm 40 giây trễ không cần thiết. Hơn nữa, bất kỳ biến động trễ (jitter) nào cũng có thể khiến quá trình bầu chọn bị chập chờn (flapping).
Thiết lập ip ospf network point-to-point báo cho OSPF biết rằng chỉ có đúng hai node chia sẻ liên kết này. Nhờ đó, nó bỏ qua hoàn toàn bước bầu chọn DR/BDR. Quan hệ láng giềng được hình thành ngay lập tức, và thời gian phục hồi giảm mạnh từ 40 giây xuống mức dưới một giây.
Mô Hình Lưới Đa Chi Nhánh Nâng Cao Với Failover Dựa Trên Chi Phí
Môi trường production luôn đòi hỏi tính dự phòng đường truyền. Hãy xem xét mô hình mạng tam giác kết nối giữa Trụ sở Austin, Chi nhánh 1 Chicago và Chi nhánh 2 Denver. Austin xử lý lưu lượng lớn qua đường truyền cáp quang 1 Gbps. Một tunnel băng thông rộng phụ 200 Mbps kết nối trực tiếp giữa Chicago và Denver để dự phòng khẩn cấp.
+-----------------------+
| Austin (Trụ sở chính)|
| 10.10.0.0/24 |
+-----------------------+
/ \
wg0 (Cost 10) wg1 (Cost 10)
/ \
+-------------------+ wg2 (Cost 50) +-------------------+
| Chicago (Chi nhánh)|=================| Denver (Chi nhánh) |
| 10.20.0.0/24 | | 10.30.0.0/24 |
+-------------------+ +-------------------+
Tinh Chỉnh Timer và Metric Cost
Chúng tôi gán metric thấp hơn cho các đường truyền cáp quang chính và metric cao hơn cho tunnel kết nối chéo giữa hai chi nhánh. Chúng tôi cũng giảm khoảng thời gian hello và dead interval nhằm phát hiện sự cố nhanh hơn.
Trên gateway tại Chicago, cấu hình các thông số interface trong vtysh:
configure terminal
interface wg0
description Uplink-ve-Austin-HQ
ip ospf cost 10
ip ospf dead-interval 4
ip ospf hello-interval 1
exit
interface wg2
description Du-phong-chi-nhanh-den-Denver
ip ospf cost 50
ip ospf dead-interval 4
ip ospf hello-interval 1
exit
do write
Với chu kỳ hello là 1 giây và dead timer là 4 giây, FRR sẽ phát hiện liên kết bị ngắt chỉ sau bốn lần mất tín hiệu heartbeat. Nếu Austin mất kết nối, FRR sẽ lập tức tính toán lại các tuyến theo thuật toán Shortest Path First (SPF). Lưu lượng sẽ được chuyển hướng qua wg2 sang Denver trong vòng 4,2 giây, tránh làm đứt đoạn các phiên TCP của những câu truy vấn cơ sở dữ liệu kéo dài.
Tối Ưu Vận Hành Cho Production và Xử Lý Sự Cố
1. Chống Phân Mảnh Gói Tin DBD Bằng Kích Thước MTU An Toàn
Quá trình đóng gói dữ liệu trong WireGuard làm tăng thêm 60 byte overhead trên IPv4 (20 byte IP header + 8 byte UDP header + 32 byte WireGuard header) và 80 byte trên IPv6. Khi WAN MTU của bạn là 1500, việc đặt MTU 1500 trên wg0 sẽ buộc các gói tin phải phân mảnh.
Các gói tin OSPF Database Description (DBD) kích thước lớn sẽ bị phân mảnh trong quá trình đồng bộ hóa. Rất nhiều firewall trung gian trên đám mây sẽ chặn thẳng tay các gói tin UDP bị phân mảnh. Khi sự cố này xảy ra, các OSPF neighbor sẽ bị treo vô thời hạn ở trạng thái ExStart hoặc Exchange. Hãy thiết lập rõ ràng MTU cho tunnel ở mức 1420 trong phần [Interface] để đảm bảo lưu lượng luôn đi qua trơn tru trên mọi nhà mạng upstream.
2. Duy Trì Kết Nối Phiên NAT Luôn Mở
Các gateway đặt phía sau AWS NAT Gateway hoặc tường lửa doanh nghiệp nội bộ thường tự động hủy phiên ánh xạ UDP không hoạt động sau 30 đến 60 giây. Hãy thêm PersistentKeepalive = 15 vào định nghĩa cấu hình của tất cả các remote peer. Thiết lập này sẽ gửi các gói tin mã hóa rỗng sau mỗi 15 giây, giúp cổng firewall có trạng thái luôn mở 24/7.
3. Ba Bước Xử Lý Sự Cố Tuần Tự
Khi nhận được cảnh báo định tuyến tự động kích hoạt, hãy kiểm tra lần lượt các tầng mạng theo đúng trình tự sau:
# 1. Kiểm tra lớp truyền tải mã hóa và thời gian handshake gần nhất
sudo wg show wg0 latest-handshakes
# 2. Kiểm tra quan hệ láng giềng định tuyến và máy trạng thái
sudo vtysh -c "show ip ospf neighbor"
# 3. Kiểm tra các route được nạp vào bảng định tuyến kernel
ip route show proto ospf
Nếu thời gian handshake đã quá 120 giây, hãy kiểm tra trước khả năng kết nối tới cổng UDP 51820. Nếu handshake diễn ra gần đây nhưng neighbor vẫn bị kẹt ở trạng thái ExStart, hãy kiểm tra xem giá trị MTU giữa hai đầu đã đồng nhất hay chưa. Khi trạng thái neighbor hiển thị Full/ -, hãy chạy ip route show proto ospf để xác nhận rằng daemon zebra đã cập nhật đầy đủ các route vào bảng định tuyến Linux kernel của bạn.
