Khủng hoảng mạng lúc 2 giờ sáng: Tại sao Tunnel lại quan trọng
Đã 2 giờ sáng và các cảnh báo giám sát đang kêu gào. Các node trong cụm database tại data center dự phòng vừa mất đồng bộ vì nhà cung cấp không hỗ trợ kết nối Layer 2 giữa các site. Bạn cần các máy chủ này hoạt động như thể chúng nằm trên cùng một switch nội bộ, nhưng chúng lại bị chia cắt bởi ba router và một kết nối internet công cộng chập chờn. Đây chính là lúc tunneling “cứu nguy”.
Mở rộng mạng qua hạ tầng Layer 3 hiện có là yêu cầu phổ biến đối với Kubernetes, OpenStack và phục hồi sau thảm họa đa site (multi-site disaster recovery). Tôi đã triển khai các tunnel này trong môi trường production xử lý lưu lượng hơn 10Gbps; độ ổn định cực kỳ vững chắc nếu bạn cấu hình đúng. Cho dù bạn đang liên kết hai văn phòng từ xa hay xây dựng một mạng ảo hóa overlay khổng lồ, việc làm chủ GRE và VXLAN là kỹ năng cốt lõi của bất kỳ kỹ sư Linux cao cấp nào.
Hãy coi GRE (Generic Routing Encapsulation) như một “chú ngựa thồ” kiểu cũ đáng tin cậy cho các liên kết Layer 3 điểm-đối-điểm (point-to-point). VXLAN (Virtual Extensible LAN) là người em họ hiện đại hơn. Nó đóng gói các khung Layer 2 Ethernet bên trong các gói tin UDP, về cơ bản biến mạng IP rời rạc của bạn thành một switch ảo khổng lồ.
Chuẩn bị môi trường Linux
Đừng vội lao ngay vào cấu hình. Trước tiên, hãy đảm bảo kernel của bạn đã sẵn sàng để xử lý việc đóng gói (encapsulation). Mặc dù các bản phân phối hiện đại như Ubuntu 22.04 hoặc RHEL 9 thường bật sẵn các module này, bạn sẽ không muốn phát hiện ra mình thiếu một cái giữa lúc khẩn cấp đâu. Bạn sẽ cần bộ công cụ iproute2—nếu bạn vẫn đang dùng ifconfig, đã đến lúc nên từ bỏ nó rồi.
Xác minh các module bằng các lệnh sau:
# Kiểm tra hỗ trợ GRE
sudo modprobe ip_gre
lsmod | grep gre
# Kiểm tra hỗ trợ VXLAN
sudo modprobe vxlan
lsmod | grep vxlanĐể các thay đổi này duy trì sau khi khởi động lại, hãy thêm chúng vào /etc/modules-load.d/tunnels.conf. Việc này chỉ mất mười giây lúc này nhưng sẽ giúp bạn tiết kiệm mười phút lúng túng về sau.
Triển khai GRE Tunnel cho kết nối điểm-đối-điểm
Hãy xem xét một tình huống thực tế. Site A có IP 1.1.1.1 và Site B có IP 2.2.2.2. Chúng ta cần một “sợi cáp” riêng tư giữa chúng, trong đó Site A dùng IP 10.0.0.1 và Site B dùng 10.0.0.2 trên subnet /30.
Tại Site A (1.1.1.1):
# Tạo interface tunnel
sudo ip tunnel add gre01 mode gre remote 2.2.2.2 local 1.1.1.1 ttl 255
# Bật interface
sudo ip link set gre01 up
# Gán địa chỉ IP nội bộ
sudo ip addr add 10.0.0.1/30 dev gre01Tại Site B (2.2.2.2):
# Tạo interface tunnel
sudo ip tunnel add gre01 mode gre remote 1.1.1.1 local 2.2.2.2 ttl 255
# Bật interface
sudo ip link set gre01 up
# Gán địa chỉ IP nội bộ
sudo ip addr add 10.0.0.2/30 dev gre01GRE rất đơn giản, nhưng nó có một hạn chế lớn: nó chỉ xử lý lưu lượng Layer 3. Nó sẽ không truyền các gói tin broadcast hoặc các khung non-IP một cách tự nhiên. Nếu bạn chỉ chạy OSPF hoặc BGP giữa các router, GRE là lựa chọn hoàn hảo. Nhưng nếu ứng dụng của bạn yêu cầu các máy chủ phải “thấy” địa chỉ MAC của nhau để kết nối Layer 2, bạn sẽ cần đến VXLAN.
Mở rộng với VXLAN: Tạo mạng Overlay Layer 2
VXLAN là tiêu chuẩn công nghiệp cho mạng overlay. Nó sử dụng Virtual Network Identifier (VNI) 24-bit, cho phép tạo ra 16 triệu mạng cô lập. Điều này phá vỡ giới hạn 4.096 của các VLAN truyền thống. Chúng ta sẽ cầu nối (bridge) hai máy chủ từ xa để chúng xuất hiện trên cùng một subnet 192.168.100.x.
Tại Host A (1.1.1.1):
# Tạo interface VXLAN
# VNI (id) là 42, sử dụng cổng tiêu chuẩn 4789
sudo ip link add vxlan42 type vxlan id 42 remote 2.2.2.2 local 1.1.1.1 dstport 4789
# Bật interface
sudo ip link set vxlan42 up
# Gán IP trên mạng L2 ảo
sudo ip addr add 192.168.100.1/24 dev vxlan42Tại Host B (2.2.2.2):
sudo ip link add vxlan42 type vxlan id 42 remote 1.1.1.1 local 2.2.2.2 dstport 4789
sudo ip link set vxlan42 up
sudo ip addr add 192.168.100.2/24 dev vxlan42Tại thời điểm này, Host A có thể ping 192.168.100.2. Nếu bạn chạy lệnh arp -a, địa chỉ MAC của máy chủ từ xa sẽ xuất hiện. Bạn đã mở rộng thành công mạng Layer 2 qua ranh giới Layer 3.
Kẻ sát nhân hiệu suất thầm lặng: Phân mảnh MTU
Đây là sai lầm phổ biến nhất: bỏ qua MTU (Maximum Transmission Unit). Một khung Ethernet tiêu chuẩn là 1500 byte. Khi bạn đóng gói khung đó trong header VXLAN 50 byte, nó tăng lên thành 1550 byte. Nếu mạng vật lý của bạn chỉ chấp nhận 1500, gói tin đó sẽ bị phân mảnh hoặc đơn giản là bị loại bỏ.
Đây là lý do tại sao lệnh ping có thể hoạt động, nhưng phiên SSH của bạn bị treo ngay khi bạn chạy một lệnh lớn. Để giữ cho mọi thứ mượt mà, hãy luôn hạ thấp MTU trên các interface tunnel của bạn:
# Cho GRE
sudo ip link set dev gre01 mtu 1476
# Cho VXLAN
sudo ip link set dev vxlan42 mtu 1450Hạ thấp MTU giúp ngăn chặn “cơn ác mộng” hiệu suất do phân mảnh và đảm bảo các quá trình truyền dữ liệu lớn không bị thất bại trong âm thầm.
Xác minh & Giám sát
Việc xác minh không chỉ đơn thuần là ping thành công. Bạn cần đảm bảo việc đóng gói thực sự hoạt động mà không có lỗi.
Bắt đầu bằng cách kiểm tra thống kê interface:
ip -s link show vxlan42Theo dõi các gói tin bị loại bỏ (dropped packets). Nếu lưu lượng không lưu thông, hãy sử dụng tcpdump để kiểm tra đường truyền vật lý. Bạn sẽ thấy các gói tin UDP trên cổng 4789 for VXLAN hoặc protocol 47 cho GRE.
# Giám sát lưu lượng VXLAN trên interface vật lý eth0
sudo tcpdump -i eth0 port 4789 -nNếu bạn thấy các gói tin rời khỏi Host A nhưng không bao giờ tới được Host B, hãy kiểm tra tường lửa. Đảm bảo cổng 4789/UDP đã mở cho VXLAN và giao thức gre được phép trong các security group của bạn. Cấu hình thủ công là nền tảng của bạn. Chắc chắn, trong một cụm 500 node khổng lồ, bạn sẽ sử dụng Ansible hoặc BGP EVPN control plane. Nhưng biết cách tự tay “nối dây” các interface này là điều giúp cứu vãn tình hình khi hệ thống tự động hóa gặp lỗi lúc 3 giờ sáng.
