Cơn ác mộng mạng lúc 2 giờ sáng
Đó là lúc 2 giờ sáng khi điện thoại của tôi rung lên. Dashboard giám sát hiển thị độ trễ tăng vọt lên 350ms giữa cluster AWS us-east-1 và cơ sở dữ liệu cũ trong trung tâm dữ liệu tại Chicago. Hệ thống VPN hub-and-spoke truyền thống của chúng tôi cuối cùng đã chạm giới hạn 1Gbps. Mọi gói tin đều phải đi qua một gateway trung tâm, giải mã, mã hóa lại, rồi mới vật lộn đi tới đích. Đó là một nút thắt cổ chai điển hình. Một điểm yếu chí mạng (single point of failure). Và đêm đó, đó là vấn đề mà tôi phải giải quyết.
Sự cố đó đã thôi thúc tôi chuyển đổi toàn bộ hạ tầng sang Nebula. Được tạo ra bởi đội ngũ tại Slack, Nebula là một công cụ mạng overlay có khả năng mở rộng, giúp xây dựng một mạng full-mesh VPN. Không giống như các thiết lập truyền thống, Nebula cho phép các node giao tiếp trực tiếp với nhau thông qua kết nối Peer-to-Peer (P2P). Bất kể máy chủ của bạn nằm ở AWS, Azure hay trong một góc phòng kỹ thuật, Nebula sẽ xuyên qua các quy tắc firewall và NAT traversal, khiến mạng multi-cloud có cảm giác như một mạng LAN nội bộ.
Khởi đầu nhanh: Thiết lập và chạy trong 5 phút
Để mạng mesh hoạt động, bạn cần một “Lighthouse”. Đây là một node có IP tĩnh công khai đóng vai trò như một danh bạ điện thoại. Nó giúp các node tìm thấy nhau nhưng không truyền tải lưu lượng dữ liệu của chúng. Sự tách biệt này là lý do tại sao Nebula có khả năng mở rộng cực kỳ hiệu quả.
1. Khởi tạo Certificate Authority (CA)
Nebula sử dụng chứng chỉ cho mọi thứ. Đầu tiên, hãy tải các file binary cho hệ điều hành của bạn. Bạn nên tạo CA trên một máy tính ngoại tuyến, bảo mật—không bao giờ được để trên chính lighthouse.
./nebula-cert ca -name "MyGlobalMesh"Lệnh này sẽ tạo ra ca.crt và ca.key. Hãy bảo vệ file .key đó bằng mọi giá; nó là gốc rễ của sự tin cậy cho toàn bộ mạng của bạn.
2. Cấp chứng chỉ cho các Node
Tiếp theo, chúng ta cần định danh cho các node. Hãy ký một chứng chỉ cho Lighthouse và một cho một worker node tiêu chuẩn.
# Cho Lighthouse (VPN IP: 192.168.100.1)
./nebula-cert sign -name "lighthouse01" -ip "192.168.100.1/24"
# Cho một Worker Node (VPN IP: 192.168.100.2)
./nebula-cert sign -name "worker01" -ip "192.168.100.2/24"3. Các cấu hình thiết yếu
Trên Lighthouse, file config.yaml cần xác định vai trò của nó là một beacon. static_host_map cho các node khác biết nơi tìm thấy nó trên internet công cộng.
pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/lighthouse01.crt
key: /etc/nebula/lighthouse01.key
static_host_map:
"192.168.100.1": ["203.0.113.42:4242"]
lighthouse:
am_lighthouse: true
listen:
host: 0.0.0.0
port: 4242Cấu hình của worker node trông gần như tương tự, nhưng bạn phải đặt am_lighthouse thành false. Bạn cũng cần trỏ nó tới IP VPN của lighthouse để nó biết nơi đăng ký.
4. Khởi chạy mạng Mesh
Khởi chạy file binary trên cả hai máy bằng quyền sudo:
sudo ./nebula -config config.yamlHãy thử ping 192.168.100.1 từ worker. Nó sẽ phản hồi ngay lập tức. Bạn vừa mới vượt qua mớ hỗn độn của VPC peering và security group phức tạp từ nhà cung cấp đám mây.
Tại sao Mesh VPN vượt trội hơn Hub-and-Spoke
Tôi từng quản lý các cluster với OpenVPN. Nó hoạt động tốt với ba máy chủ, nhưng là một thảm họa khi lên tới năm mươi. Nếu gateway trung tâm gặp sự cố, toàn bộ mạng sẽ sụp đổ. Nếu một máy chủ ở Tokyo muốn liên lạc với một máy chủ ở Seoul, lưu lượng có thể phải đi qua gateway ở Virginia trước. Đó là một vòng lặp 200ms cho một kết nối lẽ ra chỉ mất 30ms.
Sức mạnh của P2P Hole Punching
Nebula sử dụng Noise Protocol để thiết lập các đường hầm bảo mật. Khi Node A muốn kết nối tới Node B, nó sẽ hỏi Lighthouse: “Node B ở đâu?”. Lighthouse sẽ chia sẻ IP công khai của Node B. Hai node sau đó thực hiện UDP hole punching để giao tiếp trực tiếp. Khi đường hầm đó được mở, Lighthouse sẽ đứng sang một bên. Dữ liệu của bạn được giữ riêng tư và đi theo con đường ngắn nhất có thể.
Mạng dựa trên định danh (Identity-Based Networking)
Hãy quên việc quản lý firewall bằng địa chỉ IP. Nebula sử dụng định danh được tích hợp sẵn trong chứng chỉ. Bạn có thể gán các nhóm (groups) trong quá trình ký chứng chỉ:
./nebula-cert sign -name "db-prod-01" -ip "192.168.100.50/24" -groups "db,prod"Điều này cho phép bạn viết các quy tắc firewall dễ đọc. Bạn có thể quy định “Cho phép nhóm ‘app’ giao tiếp với nhóm ‘db’ trên cổng 5432” và nó sẽ hoạt động trên toàn cầu, bất kể kiến trúc mạng bên dưới là gì.
Tăng cường bảo mật cho triển khai Production
Chạy Nebula ở quy mô lớn đòi hỏi nhiều hơn là chỉ cấu hình cơ bản. Sau ba năm sử dụng trong môi trường production, đây là những quy tắc không thể thương lượng của tôi để có một thiết lập ổn định.
- Tự động hóa chứng chỉ: Chứng chỉ Nebula cuối cùng cũng sẽ hết hạn. Đừng để việc hết hạn chứng chỉ làm gián đoạn lưu lượng production vào lúc 2 giờ sáng. Sử dụng Ansible hoặc CI/CD pipeline để rotate chứng chỉ ít nhất 30 ngày trước khi chúng hết hạn.
- Tối ưu hóa MTU: Ethernet tiêu chuẩn sử dụng MTU là 1500, nhưng việc đóng gói (encapsulation) sẽ tạo thêm overhead. Nếu bạn thấy các kết nối bị treo bất thường, hãy thử giảm MTU của Nebula xuống 1300 để tránh phân mảnh gói tin trên các đường truyền WAN phức tạp.
- Dự phòng là chìa khóa: Đừng bao giờ phụ thuộc vào một Lighthouse duy nhất. Hãy chạy ít nhất hai cái ở các vùng địa lý khác nhau (ví dụ: một ở AWS, một ở GCP). Nếu một nhà cung cấp gặp sự cố mạng, các node của bạn vẫn có thể tìm thấy nhau thông qua cái còn lại.
- Giám sát Handshake: Bật block
statsđể xuất dữ liệu sang Prometheus. Hãy theo dõi sát sao “handshake_retries”. Số lượng lớn ở đây thường có nghĩa là firewall vật lý đang chặn cổng UDP 4242 ở đâu đó trên đường truyền.
Nebula đã thay đổi hoàn toàn cách tôi nhìn nhận về hạ tầng. Nó biến một tập hợp các máy chủ rời rạc thành một mạng lưới duy nhất, gắn kết và bảo mật. Nó làm cho vị trí vật lý của phần cứng không còn quan trọng. Dù máy chủ của bạn là một rack vật lý ở Singapore hay một VM nhỏ ở London, giờ đây chúng chỉ cách nhau một bước nhảy P2P trực tiếp.
