Network Address Translation ( NAT ) đã trở thành nền tảng của hạ tầng internet hiện đại, giúp hàng tỷ thiết bị chia sẻ các địa chỉ IPv4 hạn chế. Trong khi hầu hết mọi người hiểu NAT như một ánh xạ đơn giản giữa các địa chỉ IP riêng tư và công cộng, các cuộc thảo luận kỹ thuật gần đây đã tiết lộ một lớp phức tạp ẩn khiến việc triển khai NAT mạnh mẽ trở nên khó khăn hơn nhiều so với vẻ ngoài của nó.
So sánh không gian địa chỉ IPv4 và IPv6
- IPv4: Địa chỉ 32-bit = 4.294.967.296 tổng số địa chỉ (~4,3 tỷ)
- IPv6: Địa chỉ 128-bit = 340.282.366.920.938.463.463.374.607.431.768.211.456 địa chỉ (~340 undecillion)
- Tỷ lệ địa chỉ: IPv6 cung cấp nhiều hơn khoảng 79 octillion lần so với IPv4
Phân mảnh IP tạo ra những thách thức NAT bất ngờ
Độ phức tạp đáng kể nhất trong các hệ thống NAT đến từ việc xử lý phân mảnh IP, đặc biệt là với các gói tin UDP. Khi các datagram UDP vượt quá kích thước gói tin tối đa, chúng sẽ được chia thành nhiều gói tin IP. Tuy nhiên, chỉ có gói tin đầu tiên chứa header UDP với thông tin cổng mà các thiết bị NAT cần để dịch địa chỉ.
Điều này tạo ra một chuỗi các vấn đề. Các thiết bị NAT phải tương quan các gói tin phân mảnh bằng cách sử dụng fragment ID và viết lại địa chỉ IP trên tất cả các mảnh. Tệ hơn nữa, các mảnh có thể đến không theo thứ tự, buộc các hệ thống NAT phải đệm các mảnh sau cho đến khi gói tin đầu tiên với header UDP đến. Yêu cầu đệm này thêm vào chi phí bộ nhớ và độ phức tạp xử lý mà nhiều người không nhận ra là tồn tại.
Vấn đề phân mảnh trở nên đặc biệt khó khăn trong các mạng lớn với nhiều đường dẫn. Các router hiện đại sử dụng flow steering để phân phối lưu lượng truy cập qua các liên kết bằng cách băm chi tiết kết nối từ các header UDP hoặc TCP. Nhưng các gói tin phân mảnh phá vỡ hệ thống này vì các mảnh sau thiếu thông tin header cần thiết để định tuyến nhất quán.
Khía cạnh đơn lẻ này có lẽ chịu trách nhiệm cho một nửa độ phức tạp trong một triển khai NAT mạnh mẽ.
Tác động thực tế vượt ra ngoài mạng gia đình
Trong khi nhiều người liên kết NAT chủ yếu với router gia đình, công nghệ này thấm sâu vào hạ tầng doanh nghiệp và đám mây. Các container Docker dựa rất nhiều vào Linux NAT thông qua các quy tắc iptables để ánh xạ các cổng host tới các dịch vụ container. Mỗi khi các nhà phát triển chạy một lệnh ánh xạ cổng đơn giản, họ đang tận dụng các kỹ thuật thao tác gói tin tương tự được sử dụng bởi các gateway NAT cấp ISP.
Độ phức tạp trở nên còn rõ rệt hơn trong các dịch vụ NAT đám mây được quản lý yêu cầu tính khả dụng cao và sao chép trực tiếp. Các hệ thống này phải xử lý các trường hợp biên phân mảnh trong khi duy trì tính nhất quán giao dịch trên nhiều node.
Các loại NAT và đặc điểm
| Loại NAT | Mô tả | Truy cập từ bên ngoài |
|---|---|---|
| Basic/Static NAT | Chuyển đổi IP theo tỷ lệ một-một | Ánh xạ trực tiếp |
| Port Address Translation (PAT) | Nhiều thiết bị chia sẻ một IP công cộng bằng cách sử dụng các cổng khác nhau | Phân biệt dựa trên cổng |
| Full Cone NAT (NAT 1) | Bất kỳ máy chủ bên ngoài nào cũng có thể gửi gói tin nếu biết IP/cổng công cộng | Kết nối đến không hạn chế |
| Restricted Cone NAT (NAT 2) | Chỉ những máy chủ bên ngoài đã được liên hệ trước đó mới có thể gửi gói tin trở lại | Kết nối đến bị hạn chế theo IP |
| Port Restricted Cone NAT (NAT 3) | Máy chủ bên ngoài phải khớp cả IP và cổng từ giao tiếp đi ra | Hạn chế theo IP+Cổng |
| Symmetric NAT (NAT 4) | Ánh xạ khác nhau cho mỗi đích đến, phá vỡ WebRTC dựa trên STUN | Hạn chế nhất |
Các phương pháp tiếp cận thay thế và cân nhắc tương lai
Một số kỹ sư mạng lập luận rằng UDP nên xử lý phân mảnh ở lớp giao thức thay vì dựa vào phân mảnh cấp IP. Điều này sẽ loại bỏ nhiều phức tạp NAT bằng cách đảm bảo mọi gói tin đều bao gồm thông tin header cần thiết. Tuy nhiên, những người khác chỉ ra rằng khám phá MTU đường dẫn mạnh mẽ đưa ra những thách thức riêng của nó, đặc biệt là trong các mạng có nhiều đường dẫn với các đơn vị truyền tối đa khác nhau.
Các mạng tài chính chứng minh một phương pháp tiếp cận thành công bằng cách cố ý giữ kích thước gói tin UDP dưới ngưỡng phân mảnh và sử dụng số thứ tự lớp ứng dụng để theo dõi gói tin. Điều này hiệu quả di chuyển việc xử lý phân mảnh tới lớp ứng dụng nơi nó có thể được quản lý dự đoán hơn.
Thực tế di chuyển IPv6
Mặc dù khả năng lý thuyết của IPv6 trong việc loại bỏ yêu cầu NAT thông qua không gian địa chỉ khổng lồ của nó, việc áp dụng vẫn chậm. Thống kê áp dụng IPv6 toàn cầu hiện tại cho thấy quá trình chuyển đổi còn xa mới hoàn thành, có nghĩa là độ phức tạp NAT sẽ tồn tại trong nhiều năm tới. Ngay cả các mạng IPv6 đôi khi sử dụng các công nghệ giống NAT như Network Prefix Translation ( NPT ) cho các trường hợp sử dụng cụ thể.
Sự tồn tại của NAT làm nổi bật cách các giải pháp mạng tạm thời thường trở thành các thành phần cố định vĩnh viễn. Ban đầu được đề xuất như một giải pháp ngắn hạn cho tình trạng cạn kiệt địa chỉ IPv4 vào năm 1994, NAT đã phát triển thành một thành phần quan trọng nhưng phức tạp của hạ tầng internet mà các kỹ sư phải hiểu sâu để triển khai một cách đáng tin cậy.
Tham khảo: grokking NAT and packet mangling in linux