Posted inNetworking

NAT64 và DNS64 với Jool: Tiết kiệm ngân sách bằng cách chuyển sang máy chủ chỉ dùng IPv6

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

Chi phí đắt đỏ khi sống trong thế giới IPv4

Địa chỉ IPv4 không chỉ khan hiếm mà còn rất đắt. Với việc các nhà cung cấp đám mây lớn hiện đang tính phí khoảng 3,50 đến 5,00 USD mỗi tháng cho một IPv4 public duy nhất, một cụm 20 microservices nhỏ có thể đột ngột tốn thêm 1.000 USD mỗi năm chỉ để có đặc quyền sở hữu IP. Chuyển sang môi trường nội bộ chỉ dùng IPv6 không chỉ là để phô diễn kỹ thuật; đó là một bước đi tài chính thông minh.

Tôi đã triển khai mô hình này trong các môi trường production xử lý hàng triệu request. Nó cực kỳ ổn định. Bằng cách kết hợp Jool—một giải pháp triển khai NAT64 ở cấp độ kernel—với BIND9, bạn sẽ tạo ra một gateway minh bạch. Các máy chủ chỉ dùng IPv6 của bạn có thể truy cập các API chỉ hỗ trợ IPv4, cập nhật repository và các dịch vụ bên thứ ba mà thậm chí không nhận ra việc chuyển đổi đang diễn ra.

Lựa chọn “vũ khí” chuyển đổi

Không phải công cụ NAT64 nào cũng giống nhau. Trước khi sao chép bất kỳ câu lệnh nào, bạn cần quyết định loại hình chuyển đổi nào phù hợp với kiến trúc của mình.

NAT64 Stateless và Stateful

Stateless NAT64 (SIIT) là bản đồ 1:1 đơn giản. Mỗi địa chỉ IPv6 sẽ có một IPv4 riêng biệt. Mặc dù cách này nhanh nhưng lại khá vô nghĩa nếu mục tiêu của bạn là tiết kiệm địa chỉ. Nó tiêu tốn IPv4 nhanh tương đương với thiết lập dual-stack.

Stateful NAT64 là thứ mà hầu hết chúng ta thực sự cần. Nó hoạt động giống như NAT truyền thống (NAPT) trong router gia đình. Bạn có thể có 500 máy chủ IPv6 nội bộ dùng chung một địa chỉ IPv4 public. Gateway sẽ theo dõi các kết nối bằng bảng trạng thái (state table). Jool xử lý việc này ngay trong Linux kernel. Điều này giúp tránh được chi phí overhead do chuyển đổi ngữ cảnh (context-switching) của các công cụ ở userspace như TAYGA, giữ cho độ trễ tăng thêm ở mức dưới 1ms.

DNS64 thu hẹp khoảng cách như thế nào

Nếu NAT64 là động cơ thì DNS64 là người dẫn đường. Khi máy chủ của bạn cố gắng truy cập legacy-api.com, nó sẽ yêu cầu bản ghi AAAA. Nếu API đó chỉ hỗ trợ IPv4, máy chủ DNS64 sẽ lấy địa chỉ IPv4 (ví dụ 93.184.216.34) và bọc nó trong một prefix đặc biệt, thường là 64:ff9b::/96. Sau đó, máy chủ của bạn gửi các gói tin đến địa chỉ IPv6 tổng hợp đó, và Jool sẽ thực hiện công việc nặng nhọc là loại bỏ prefix và gửi nó trở lại Internet IPv4.

Đánh đổi: Nó đã sẵn sàng cho Production chưa?

Không có gì trong mạng máy tính là miễn phí. Trước khi di chuyển, hãy cân nhắc các ưu và nhược điểm này dựa trên kinh nghiệm thực tế của tôi.

  • Ưu điểm:
    • Tiết kiệm IPv4: Chạy toàn bộ trung tâm dữ liệu chỉ với một vài địa chỉ IPv4.
    • Đơn giản hóa quản lý: Không còn tình trạng trùng lặp subnet IPv4 nội bộ (việc cạn kiệt 10.0.0.0/8 là có thật). Bạn chỉ cần quản lý một bộ quy tắc tường lửa duy nhất.
    • Sẵn sàng cho tương lai: Bạn đã sống trong tương lai rồi. Khi một dịch vụ cuối cùng chuyển sang chỉ dùng IPv6, bạn không cần thay đổi bất cứ điều gì.
  • Nhược điểm:
    • Điểm nghẽn (Bottleneck): Gateway NAT64 của bạn là một điểm gây lỗi duy nhất (single point of failure). Nếu nó gặp sự cố, cả cụm máy chủ sẽ mất kết nối. High Availability (HA) qua Keepalived hoặc VRRP là bắt buộc.
    • Vấn đề về Payload: Một số giao thức cũ như FTP hoặc SIP nhúng địa chỉ IP bên trong gói dữ liệu. Những giao thức này sẽ bị lỗi nếu không có các bộ hỗ trợ (helpers) cụ thể.
    • Ghi log: Log trên web server tại đích IPv4 sẽ chỉ nhìn thấy IP của gateway chứ không phải của từng máy chủ nội bộ.

Hướng dẫn triển khai

Tôi khuyên bạn nên sử dụng một instance Ubuntu 24.04 riêng biệt cho gateway. Nó cần một IPv4 public và một prefix IPv6 được định tuyến.

1. Cài đặt các thành phần thiết yếu

Jool nằm trong kernel, vì vậy chúng ta cần DKMS để giữ cho nó luôn được cập nhật khi hệ điều hành cập nhật kernel mới.

sudo apt update
sudo apt install -y dkms make gcc linux-headers-$(uname -r) bind9 jool-dkms jool-tools

Xác nhận module đang hoạt động:

sudo modprobe jool
lsmod | grep jool

2. Cấu hình DNS64 (BIND9)

Chúng ta cần BIND “nói dối” các client bằng cách tổng hợp các bản ghi AAAA. Chỉnh sửa /etc/bind/named.conf.options:

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-query { any; };

    # Phép màu diễn ra ở đây
    dns64 64:ff9b::/96 {
        clients { any; };
    };

    dnssec-validation auto;
    listen-on-v6 { any; };
};

Khởi động lại dịch vụ: sudo systemctl restart bind9.

3. Khởi động công cụ NAT64

Đầu tiên, hãy bật tính năng forwarding trong kernel để các gói tin có thể di chuyển giữa các interface.

sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo sysctl -w net.ipv4.conf.all.forwarding=1

Bây giờ, hãy chỉ định cho Jool prefix nào cần theo dõi và địa chỉ IPv4 nào sẽ được sử dụng cho thế giới bên ngoài. Thay thế 1.2.3.4 bằng IP public thực tế của bạn.

# Tạo instance
sudo jool instance add "default" --netfilter --pool6 64:ff9b::/96

# Ánh xạ vào IP public của bạn
sudo jool pool4 add "default" 1.2.3.4 --udp --tcp --icmp

4. Thời khắc của sự thật

Truy cập vào client chỉ dùng IPv6 của bạn. Cập nhật DNS trỏ đến địa chỉ IPv6 của gateway. Sau đó, thử truy cập vào một đích đến chỉ hỗ trợ IPv4:

# Ping DNS của Google qua NAT64 prefix
ping 64:ff9b::8.8.8.8

# Kiểm tra khả năng tổng hợp của DNS64
curl -I http://ipv4only.arpa

Nếu bạn thấy mã 200 OK, bạn đã “đào hầm” xuyên qua Internet cũ thành công. Thật tuyệt vời khi thấy một máy chủ chỉ dùng IPv6 tải các bản cập nhật từ một repo chỉ hỗ trợ IPv4 với tốc độ đường truyền tối đa.

Kết luận

Đừng để những thiết lập này biến mất khi khởi động lại máy. Hãy đảm bảo bạn đưa các lệnh jool vào một systemd unit hoặc sử dụng /etc/jool/jool.conf. Chuyển sang kiến trúc chỉ dùng IPv6 không chỉ là để bắt kịp xu hướng. Đó là về việc xây dựng một hạ tầng tinh gọn hơn, rẻ hơn và dễ mở rộng hơn mà không gây áp lực lớn về chi phí khi bạn phát triển.

Share:
Tags: