Nói chút về lịch sử ra đời của NAT

Định nghĩa về cơ bản, thì NAT (Network Address Translation) là thuật ngữ chỉ về kỹ thuật thay đổi (hay chuyển đổi) địa chỉ mạng - thường là giá trị ở lớp 3 - và (tuỳ chọn) có thể thay đổi cả thành phần có liên quan lên 1 hoặc 1 loạt các gói tin khi trung chuyển qua 1 thiết bị (có chức năng) định tuyến, nhằm thực hiện một ý đồ định tuyến khác hoặc giải quyết xung đột khi giao tiếp mạng.

Có nhiều kiểu NAT (được phân loại bởi nhà sản xuất), tuy có khác nhau về giá trị được chọn để thay đổi (địa chỉ nguồn, đích, hoặc cả hai), thay đổi cổng hoặc thông số nào đó của lớp 3 bên trên, nhưng cơ bản đều là phải làm thay đổi địa chỉ trên header của gói tin trực tiếp - mà không thêm gì vào gói tin đó cả - khác kỹ thuật thay đổi địa chỉ bằng cách thêm header khác vào thì gọi là tunnel hoặc packet wrapper, không phải NAT. Việc thay đổi đó làm tính chất định tuyến của gói tin bị thay đổi (nếu là thay đổi địa chỉ đích đến) hoặc tính chất của định tuyến gói tin trả lời bị thay đổi (tức ảnh hưởng định tuyến ở chiều ngược lại).

NAT được áp dụng nhiều nhất với bộ giao thức TCP/IP version 4, cụ thể là tác động lên tầng IP (tương đương lớp 3 - mô hình OSI - dĩ nhiên).

NAT ra đời không quá trễ khi Internet bùng nổ, nhưng nó không có ngay khi ARPANET có, tôi nghĩ kỹ thuật áp dụng thực tế đầu tiên chắc tầm năm 1995-1997. Năm đó, bắt đầu bùng nổ Internet, dầu cho câu chuyện về số lượng địa chỉ IPv4 không phải thiếu, nhưng việc cấp/cho thuê 1 lớp địa chỉ mạng (subnet) cho thuê bao, định tuyến lớp đó thì khá phức tạp, tốn kém và chỉ dành cho doanh nghiệp lớn. Tôi sẽ có tình huống cho việc thuê subnet thay vì NAT ở dưới.

sau khi tìm kiếm lại trên Internet, ở Quora có 1 câu hỏi như thế, thì câu trả lời kỹ thuật NAT có sớm hơn chút (1994), và nó được triển khai đầu tiên trên PIX (trước khi Cisco mua hãng đó).

Phân tích sâu hơn chút về kỹ thuật

Tôi đưa ra ở đây 2 mô hình đơn giản nhất - vẽ vội bằng tay - về 2 tình huống: 1 máy PC sử dụng Internet trên 1 kênh dial-up, và tình huống 2, cũng kênh đó, chia cho nhiều máy sử dụng bằng kỹ thuật NAT (cái này nó phổ biến, dành cho gia đình).

1. Khi một PC kết nối Internet

Máy PC của bạn cắm trực tiếp vào modem quay số (nối cổng COM hay trực tiếp), rồi bạn chạy chương trình dial-up (một tính năng của OS - giả sử là Windows 98 đi) - hỗ trợ giao thức thường là PPP (point-to-point protocol), bạn nhập đủ thông tin như số điện thoại, tên và mật khẩu, bấm nút dial thì chương trình sẽ giao tiếp với modem ra lệnh quay số tới 1 số điện thoại định trước của ISP để kết nối, số này gắn vào 1 máy chủ gọi là access server (AS) phía ISP và nó hành xử như một thiết bị định tuyến. Sau khi quay xong, xác thực kiểm tra, thì phiên PPP được thiết lập, AS sẽ gán 1 địa chỉ IP lựa chọn ngẫu nhiên hoặc cố định - và là public IP trong pool họ lập kế hoạch trước cho phiên PPP của bạn, thiết lập định tuyến đến IP đó tương ứng cho phiên, kết nối đã thông.

Phía máy PC của bạn lúc này được chương trình dial-up thiết lập 1 giao tiếp (interface) mạng ảo với 1 địa chỉ IP AS gán đó (gọi là My-IP nhé), 1 định tuyến qua giao tiếp đó (thường là định tuyến mặc định - mọi thứ ra Internet qua đây nhé), và thường là thường được gắn thêm thông số gọi là DNS Server (là 1, 2 địa chỉ IP). Tất cả các thông số này đều thông qua PPP trao đổi với AS và chương trình dial-up sẽ thiết lập trên máy của bạn tự động.

tôi lấy dial-up quay số làm ví dụ, vì hoài cổ 1 chút, thời còn dùng nó là cách vào Internet duy nhất thì thực sự là nó hoạt động như thế. Còn sau này dùng ADSL, FTTH thì thực ra ISP cũng thường triển khai cái đó, nhưng lớp 2 - modem đó - không dùng cổng COM giao tiếp mà là Ethernet, và PPP chạy trên Ethernet là PPPoE, AS giờ có tên là BRAS: broadband access server. Và quan trọng hơn, ISP không tính tiền theo thời lượng số phút mà bạn quay số rồi giữ phiên PPP nữa cho khi ngắt, họ thường tính theo số byte bạn truyền nhận trên kênh PPP đó, cộng dồn lại theo tháng, tính tiền.

OK, giờ bạn dùng PC đã quay xong, muốn vào Web, ví dụ vào http://vietfi.net đọc bài chẳng hạn. Mở trình duyệt lên, gõ vào cái địa chỉ này ở thanh địa chỉ. Yup, trang web blog này hiện ra sau vài giây.

Thực sự điều gì xảy ra ở bên dưới? Thứ tự các việc nó như sau:

• Trình duyệt phân tích cái địa chỉ nhập vào, nó tách ra 2 phần: http và vietfi.net, phần sau gọi là 1 tên máy (hostname).
• Trình duyệt, căn cứ vào thông tin DNS khi thiết lập, có được 1 (hoặc 2 địa chỉ) DNS Resolver (hoặc DNS server, nhưng chính xác nên gọi là resolver). Trình duyệt nó lập ra 1 phiên UDP (bind) nguồn để trống (OS sẽ tự chọn - dĩ nhiên nó sẽ chọn cái My-IP rồi, còn cái nào đâu?), đích địa chỉ là DNS đó (và port là 53 - port của DNS).
• Ở phiên UDP này trình duyệt sẽ tạo ra 1-vài yêu cầu phân giải tên hostname ở trên thành địa chỉ, theo trình tự gửi yêu cầu đi/chờ nhận. Gửi xuống OS để gửi đi, OS cho gói ra phiên PPP. DNS resolver nhận, tra bảng tên - địa chỉ và hỏi các đối tác khác, nó ra được trả lời gửi lại. Sau 1 loạt gửi/nhận trình duyệt có được 1 địa chỉ IP (hoặc vài, nếu chủ site muốn) tương ứng với cái tên vietfi.net trong hệ thống DNS. OK giờ có địa chỉ IP rồi thì ta chơi tiếp thôi.

Nói chung quá trình DNS dài dòng này (2 bước bên trên) được giải quyết bởi 1 hàm có tên GetHostByName trong lập trình hệ thống (lập trình Socket). Gọi nó, tham số vào là cái tên, thường nó sẽ trả về cho trình duyệt 1 danh sách địa chỉ, trình duyệt lấy ra 1 cái xài, nếu không có cái nào về thì báo câu "Host not found" hoặc đại loại thế, nếu DNS xa quá, hay có gì trục trặc, nghẽn thì kêu trình duyệt nó quay quay đồng hồ báo chờ nó.

• Tiếp tục, có địa chỉ rồi, dựa vào chuỗi http, trình duyệt biết đây là giao thức HTTP (yep, thực ra vietfi.net dùng https nhưng thôi để đơn giản - ta để là http đi, thời đó https cũng ít lắm). Giao thức HTTP thì sao? ok, thông tin là có được port chuẩn (80) và giao thức là TCP. (Lưu ý: bên trên nhắc đến DNS, có cả TCP và UDP cùng port đích 53, nhưng thường là UDP).
• Trình duyệt mở 1 phiên TCP (cũng bind), lần này địa chỉ đích là địa chỉ của Vietfi chọn lấy ở bước trên, nguồn bỏ trống. Khác chút, TCP phải call hàm connect. OS bắt đầu làm cái việc bắt tay 3 bước của TCP, nếu không ok vì lý do nào đó thì trả về lỗi và trình duyệt báo cáo lỗi này lên màn hình (ví dụ connect failed, connection refuse...).
• Giả sử phiên TCP là OK đi, Trình duyệt biết nó phải nói chuyện bằng HTTP, cần lấy nội dung, nó gửi yêu cầu: GET / HTTP/1.1n...., rồi chờ, 1 tí sau, VietFi HTTP Server, lấy cái nội dung file mặc định ở gốc (/ - sau cái GET), trả về. Với bắt đầu là HTTP 200 Okn ... gì gì đó, đến nội dung, trình duyệt đọc nội dung này (thường là 1 file HTML hoàn chỉnh) và xử lý nó, có lấy thêm gì khác thì theo HTML chỉ định lặp lại việc GET trên (ui cũng không cần bắt tay TCP lại đâu, dùng lại phiên cũ ok rồi, do tôi cố tình đặt là HTTP/1.1 = phiên bản 1.1 hỗ trợ tái sử dụng phiên TCP).
• Chúng ta đang nói về NAT, định tuyến mạng, thì quan tâm hơn đến layer 3 (TCP là layer 4 rồi). Điều gì xảy ra ở đó, gói tin chứa GET và gói tin về HTTP 200 ra sao? coi hình sau chút, capture gói ở giao tiếp mạng của PC đó.

• Ok, ta thấy đó, các gói từ máy PC gửi đi, (bắt đầu bằng gói SYN - cờ S), có địa chỉ nguồn bên là My-IP (bôi đỏ), và địa chỉ đích là địa chỉ VietFi. Còn các thứ khác bên trên TCP, port nguồn ngẫu nhiên chọn X nào đó, port đích 80. Khi server VietFi nhận được, trả lời, nó tạo ra các gói tin trong đó đảo đích thành nguồn, nguồn thành đích, gửi trả lại cho PC: địa chỉ nguồn VietFi, đích My-IP, TCP thì port nguồn 80, port đích X. VietFi server lấy thông tin ở đâu để tái tạo ra gói trả lời ngược lại? chính là nhòm vào header các lớp của gói dữ liệu từ PC mà nó nhận được đấy.
• Việc đảo ngược đích/nguồn và trả kết quả về, DNS cũng tương tự, khác chút vì DNS dùng UDP nên nó không có bắt tay, cơ bản DNS server cũng phải nhòm vào header (địa chỉ, port) để tạo ra gói trả lời.

OK vậy là địa chỉ My-IP đặt là nguồn trong gói tin gửi từ PC, khi nhận bởi server có ảnh hưởng tới server làm việc, là việc trả lời lại bằng các gói đảo ngược thông tin địa chỉ. Mọi thứ đơn giản quá đúng không? Đơn giản như chúng ta nhận thư trả lời bằng cái lấy from điền vào to. Chúng ta sẽ xem tiếp tình huống NAT nhé.

2. Nhiều PC nhà bạn chia sẻ 1 kết nối Internet

Hình trên mở rộng chút, giờ ta có 1 PC (Win98), có kết nối Internet giống tình huống 1, nghĩa là dial-up PPP bắt tay, địa chỉ cũng My-IP do ISP cấp, DNS... Cái khác, PC này có thêm 1 giao tiếp mạng LAN (chuẩn ethernet đi), trên giao tiếp này bạn đặt địa chỉ IP cho nó, gọi là GW IP (tôi cố tình không cho giá trị vào vì sẽ có 3 tình huống phụ). PC được bật chế độ định tuyến, giữa mạng riêng (1 subnet) và mạng Internet (định tuyến mặc định).

Dù trên đây là PC làm gateway (GW), Những router thời nay vai trò nó cũng thế thôi, cách đây gần 20 năm thì PC quay số chia sẻ Internet kiểu này nó phổ biến lắm nha. PC chạy Windows 98 hay Cisco Router 1800, cơ bản vai trò là như nhau.

Trong mạng riêng ta có 3 PC khác, địa chỉ lần lượt đặt là I1, I2, I3. 3 bạn cùng sử dụng (cho thuê theo giờ nha), DNS cũng đặt giống máy GW, nhưng định tuyến mặc định là qua GW (nghĩa là gửi gì tới Internet qua GW giùm). I1, I2, I3 là giá trị gì tùy tính huống dưới.

Tình huống 2a: NAT với My-IP

Ở tình huống này, ta đặt IP GW=192.168.0.1/24 (thực ra với Windows bật chia sẻ lên nó sẽ tự đặt giá trị này). Lúc này, I1, I2, I3 giả sử được dịch vụ DHCP chạy trên GW gán 3 địa chỉ: 192.168.0.11/24, 192.168.0.12/24, 192.168.0.13/24. /24 chỉ dấu là GW nối cùng mạng với I1, I2, I3 không cần qua trung gian. Các Ix máy đó cũng được đặt địa chỉ DNS giống PC do ISP gán khi quay PPP xong.

Ta giả sử máy GW (là PC) mở trình duyệt ra vào VietFi.net? điều gì khác biệt với tình huống 1 hay không? không bạn ạ. Tuy có chút rắc rối vì lúc này trên GW, OS nó có tới 2 địa chỉ 1 là My-IP (public, Internet), và GW kia. Tuy nhiên để lựa chọn giao tiếp VietFi.net thì nó vẫn chọn My-IP mỗi hành động bind. Tuy nhiên ta hãy giả sửa 1 việc, port nguồn gắn cho gói tin ngẫu nhiên cho DNS và HTTP mà OS trên GW chọn là 12345 đi.

Giờ, anh bạn dùng I1 truy cập cũng mở trình duyệt vào VietFi.net. Một trình tự tương tự xảy ra:

• Vài yêu cầu DNS được gửi tới DNS server, để lấy được địa chỉ IP VietFi.net từ cái tên đó. Ta tạm giả sử không rắc rối gì, IP đã được lấy.
• Giờ trình duyệt trên I1 bind 1 phiên TCP, nó sẽ gắn địa chỉ đích là VietFi, địa chỉ nguồn là trống để OS chọn, port đích 80 port nguồn cũng rỗng. OS bắt đầu chọn:

1. địa chỉ nguồn sẽ là gì? đương nhiên là I1 (=192.168.0.11) rồi, do I1 có mỗi địa chỉ đó trên giao tiếp LAN của nó thôi. 
2. port nguồn là gì? ngẫu nhiên mà, ta giả sử OS chọn 10001 đi.

• Khi gọi connect, quá trình bắt tay TCP bắt đầu, gói SYN được gửi tới GW với nguồn là I1, port nguồn 10001, đích VietFi, port đích 80.
• Gói SYN tới giao tiếp LAN của GW, với nguồn=I1, đích = Vietfi (ta tạm bỏ qua sự phức tạp vì dù địa chỉ VietFi ko phải địa chỉ nào của GW nhưng GW nhận và xử nó, vì GW là thiết bị định tuyến, khác biệt chỗ này). GW nhận gói, nó đọc giá trị địa chỉ đích đối chiếu bảng định tuyến, ops, là Internet, nghĩa là sẽ tổng ra giao tiếp Internet, ok việc lựa chọn đường đi xong.
• GW gửi ra, trước khi gửi, do NAT rule (1 rule là ra Internet thì mọi gói sẽ đổi nguồn thành My-IP mới hợp lệ), nó sẽ thay đổi thông tin gói mà I1 gửi: đổi địa chỉ nguồn thành My-IP, đổi port nếu xung đột (sẽ nói sau). port 10001 không xung đột. Dĩ nhiên đổi rồi nó phải làm thêm vài chỗ nhỏ nữa: giảm TTL, tính lại IP header checksum.
• Gói SYN đã bị đổi gửi tới VietFi. Lúc này, nó có nguồn My-IP, port nguồn 10001, đích VietFi, port đích 80. Tương tự tình huống 1, VietFi trả về 1 gói SYN/ACK có thông đảo ngược để đủ bước 2 bắt tay TCP.
• gói SYN/ACK về đến My-IP của GW. Ops, GW làm gì với gói này? địa chỉ đích đúng là nó nhưng bản thân nó ko mở phiên TCP nào có bộ thông tin port đích là 10001 cả. OK, thực ra trước khi đổi nguồn và gửi gói đi, GW ghi lại rằng có 1 phiên NAT từ I1 có port 1001 nguồn My-IP trong 1 bảng gọi là state table. Tra bảng này, do đã thêm thông tin lúc đổi ban đầu, GW suy ra luôn gói đó là của I1, port 1001, thế là nó đổi lại: nguồn VietFi, port nguồn 80 (giống như mọi gói trả lời khác), đích đổi là I1, port đích 10001, đổi xong nó gửi tới I1, I1 nhận được và xử lý, nó chả biết gì GW đã thay đổi nguồn đích 1 lần rồi, như bình thường cứ như thể I1 là của ISP cấp ấy. Đây là quá trình ngược với quá trình thay đổi NAT ban đầu, mà GW bắt buộc phải làm với mọi gói tin bị đổi/giải việc đổi. Nếu không lưu state table, không đổi ngược thì sao? Thì gói trả lời sẽ bị bỏ đi do GW có biết gói đó trả lời cho I1, I2, hay I3 đâu?
• Quá trình như trên sẽ tiếp diễn đến khi xong hết phiên TCP, với mọi gói tin không kể là SYN, SYN/ACK hay ACK, Data, DNS chạy UDP cũng thế.
• Nếu các máy I2, I3 cũng vào VietFi.net? mọi việc cũng tương tự thôi.

Sau khi phân tích, ở đây ta có thêm 1 cái mới: NAT state table = bảng lưu trữ các phiên bị đổi địa chỉ, mỗi phiên trong bảng này tương ứng 1 phiên TCP hoặc UDP mà các máy Ix chạy. Ôi thế sao không làm 1 rule đổi ngược lại cố định (ví dụ cứ port nguồn 10001 đổi ngược qua I1 luôn?, khỏi làm bảng thêm bớt tra cứu làm chi? Ẹc, cái này là không thể, tức là GW không thể biết được I1 sẽ chọn port nguồn nào (do ngẫu nhiên) mà làm rule? chả nhẽ làm hết 65k port luôn? Vậy state table là bắt buộc phải có và ở các thời điểm tạo phiên/ngưng phiên NAT thì phải thêm/bớt vào đây, còn mỗi gói tin nhận được thì phải tra cái bảng này (ok nhận từ LAN để NAT gửi đi Internet cũng tra luôn, lý do ở ví dụ kế tiếp).

Ta sẽ xem xét thêm vai trò của state table ở ví dụ sau:

• Giả sử GW đang truy cập VietFi.net với 1 phiên có port nguồn là 12345, ngẫu nhiên làm sao I1 khi vào VietFi.net cũng được OS gắn port nguồn cùng là 12345.
• Cùng lúc, GW gửi cho VietFi 1 gói nguồn My-IP nguồn port 12345, và nó cũng nhận đc từ I1 gói nguồn I1, nguồn port 12345, lẽ thường thì nó sẽ đổi nguồn từ I1 => My-IP, giữ port nguồn không đổi (thông số port nằm ở lớp 4 - TCP nhé, nghĩa là không thay đổi TCP header). Chờ tí, không ổn, như thế phiên của GW sẽ lẫn với phiên của I1 vì thông số nguồn/đích (4 giá trị) giống nhau mà? Nếu VietFi trả gói trả lời về thì biết cái nào của ai? phần mã xử lý NAT trên GW đủ thông minh để phân biệt sự xung đột giữa phiên nội bộ GW và phiên NAT được yêu cầu. Gặp cái này nó sẽ đổi thế nào? ok NAT sẽ bị đổi luôn cả port nguồn, ví dụ nó đổi qua 1 port khác là 12346, tránh 12345 mà GW dùng kia đi, khỏi xung đột. Nó cũng ghi lại thông tin này vào state table.
• Lúc này các gói gửi đi VietFi và trả về có 2 port, 1 port đích là 12345, 1 là 12346, GW nhận nó sẽ biết 12345 là GW, còn nhận gói trả lời có port 12346, tra bảng state nó biết là phiên NAT và phải đổi port khi trả về cho I1, nó đặt lại port đích là 12345, có gì đâu! Không lẫn với phiên của GW nhé.
• Điều tương tự sẽ xảy ra, nếu cả I1 và I2 cùng gửi đi và trùng nhau, GW sẽ chọn và đổi cả port cho 1 trong 2, hoặc cả 2, sao cho không xung đột.

Hình vẽ trên với màn hình bên trái là bắt gói ở card mạng bên trong, màn hình bên phải là ở Internet (ppp0 là giao tiếp quay số), ta thấy địa chỉ IP đã bị đổi và khi gửi trả lại lại đổi lại (bôi đỏ), tương tự port nguồn cũng thế (bôi vàng).

Bạn có thể thắc mắc tại sao nó lại thay đổi port của phiên NAT mới tạo, mà không thay đổi của phiên TCP từ GW. Lý do rất đơn giản: nếu thay của GW thì khi về phải trả lại giá trị cũ (đổi), cái này sẽ vi phạm cách hoạt động của việc tạo phiên tại GW là không được đổi cái gì cả, nhất là gây ảnh hưởng tới phiên đã có của GW. Khi tạo phiên mới ngẫu nhiên nó sẽ tránh các port đang bị dùng cho NAT trong state table ra. Nói chung state table là chỗ 2 bên dùng chung nhau, dù với nội bộ GW thì chả phải đổi cái gì cả nhưng vẫn phải tham chiếu nó, tránh xung đột.

Cái kỹ thuật NAT với 1 rule cố định ở 1 chiều ra Internet (hoặc cả vào), có tác động state table, chiều ngược lại tra bảng đó, khi tạo phiên phải kiểm tra tránh xung đột, thay đổi cả thông tin ở layer 4 của gói tin, thì thường được gọi Dynamic NAT, hoặc Masquerade. Đây là kiểu kỹ thuật đắt đỏ và có hiệu quả xử lý thấp nhất (do GW phải làm quá nhiều việc nặng nhọc cho mỗi gói tin), tuy nhiên nó lại được dùng rộng rãi nhất bởi nó áp dụng cho hộ gia đình chúng ta. Bạn đừng nghĩ nó không nặng nề bởi state table mà có đến 100 ngàn dòng (= 100 ngàn phiên, 1 mạng LAN có 5.000 PC thừa sức vượt con số đó), tra bảng đó tìm chỗ trống là mệt bở hơi tai đấy, nhất là nó phải áp dụng với mọi gói tin gửi trả lại. Chưa kể việc đổi thông tin của TCP header phải tính lại checksum của phần đó và của payload, vô số các việc liên quan.

Ok, vậy giữ nguyên mô hình chia sẻ cùng kênh dial-up đó, ta xét thêm tình huống phụ thứ hai.

Tình huống 2b: một subnet do ISP cấp

Giờ giả sử mạng riêng chúng ta có 2 thứ, có thể mua bằng tiền từ ISP:

1. địa chỉ My-IP=14.23.56.123 có giá trị cố định do AS gán bất kể quay số lúc nào.
2. ISP cấp, hay định tuyến địa chỉ mạng 15.23.56.0/24 cho thuê bao của ta, tức mọi gói tin có địa chỉ đích trong subnet đó sẽ được gửi đến phiên PPP của GW nếu như nó đang mở. Lúc này không chỉ My-IP được định tuyến, cả subnet kia luôn.

Việc gán cố định My-IP là để dễ dàng định tuyến subnet này (mọi thứ tới subnet này thì các router của ISP gửi cho my-IP). Có được thêm điều 2, thì phía mạng riêng có sự thay đổi ít nhiều. Ta đặt GW là địa chỉ đầu tiên trong subnet: 15.23.56.1/24 và I1, I2, I3 là 15.23.56.11, 12, 13.

Lúc này, PC chạy Win98 không cần có cái rule NAT nữa, ta đổi ta dùng Cisco router đi. Do My-IP không quan trọng làm đại diện nữa, người ta gọi là địa chỉ đấu nối. Giờ ta xét các bước tương tự tình huống 2a, I1 mở trình duyệt vào vietfi.net, bỏ qua DNS ta phân tích thẳng phiên TCP luôn.

1. I1 bind một phiên TCP, với nguồn I1, port nguồn ngẫu nhiên, đích vietfi, port đích 80. Sau đó gửi gói SYN đến GW như 2a làm.
2. GW nhận gói từ I1, do chả cần làm gì nó bê nguyên vậy gửi ra phiên PPP (thực ra có giảm TTL nhưng cái này nhỏ tí).
3. Vietfi server nhận, đảo ngược nguồn vietfi đích I1, gửi trả SYN/ACK.
4. GW nhận được gói SYN/ACK, nó thấy địa chỉ đích là I1 không phải nó, mà trong LAN, nó lại bên nguyên gửi cho I1.
5. I1 nhận và làm các việc như bình thường, cũng chả quan tâm đến GW có thay đổi gì của mình không, giống 2a.

Ô, mọi thứ đơn giản thế, không có state table, không có đổi gì, không tính toán checksum nhiều, không lo xung đột. Dĩ nhiên như thế GW nhẹ việc, đơn giản hơn và một Cisco router làm tốt. Vậy tạo sao tất cả các hộ gia đình không được áp dụng thế này?

Có 1 số lý do khiến người ta không áp dụng cho gia đình, vì:

1. ISP sẽ phải thiết lập bảng định tuyến có mục subnet tới my-ip tới từng thuê bao gia đình. Nếu nhiều thuê bao, ví dụ 1 triệu, thì việc này không hề đơn giản, năng lực chứa/ xử lý bảng định tuyến to thế thì router mắc tiền.
2. Một subnet có đến 256 địa chỉ, 253 đặt cho PC (1 cho GW rồi). Nếu chỉ có 3 PC thôi thì để trống số còn lại, ISP không xài được cái chỗ này. Cách đây 20 năm tuy địa chỉ IPv4 còn thừa nhiều nhưng mỗi khối địa chỉ ISP vẫn phải bỏ tiền thuê/mua. Cấp cho thuê bao gấp 256 lần thế dĩ nhiên giá cho thuê bao tăng lên rồi.
3. Do các địa chỉ I1, I2 cả Internet biết, nên nếu máy I2 mở cổng 80 thành web server, thì đương nhiên các máy khác ở Internet sẽ nối tới được, chạy thành phục vụ. Điều đó không phải mục đích chính của mạng gia đình thời đó lẫn thời nay. Chưa kể nguy cơ bảo mật.

Vậy, lý do là mắc tiền, tốn kém, thuê bao dạng 2b sẽ mắc tiền hơn nhiều lần so với 2a. Hơn nữa, cái GW như Cisco router đó thường có giá bán và chi phí vận hành cao hơn. Do đó tình huống 2b thường được áp dụng khi bạn là nhà cung cấp dịch vụ nội dung Internet - ICP - giống VietFi đây, hơn là cho hộ gia đình hay công ty, chỉ có nhu cầu sử dụng Internet mà thôi.

một câu hỏi là nếu ta đặt địa chỉ 192.168.0.11 cho I1 ở tình huống 2b thì sao? Ok bạn đặt, và gửi gói đến VietFi là đến nơi, VietFi trả lời 1 gói. Tuy nhiên VietFi (hoặc ISP của VietFi) sẽ không thể gửi gói đó tới đích được, do địa chỉ 192.168.0.11 là thuộc subnet có tên private, chả phân cho ai và ISP không biết định tuyến thế nào cả, router sẽ bỏ gói đó đi, dù cố gửi bao lần đi nữa. I1 gửi đi mà không nhận được thì làm sao một phiên TCP có thể tạo nên được?

Lợi ích và công trạng của NAT

Như phân tích, NAT giúp các hộ gia đình chia sẻ 1 kênh Internet cho một vài máy tính của họ, khi kết nối một mạng gia đình. ISP chỉ tốn 1 địa chỉ IPv4 cho mỗi thuê bao, rất tiết kiệm chi phí. NAT giúp nhiều người truy cập được Internet hơn ở quán cafe có Wifi Internet miễn phí, ở các điểm công cộng nữa...

Mặc dù dynamic NAT là kỹ thuật tốn kém năng lực xử lý của CPU GW, lại cần RAM duy trì bảng state table, nhưng do phát triển công nghệ nên giá thành phần cứng rẻ đi, mạnh hơn, mà gia đình chỉ có vài đến chục PC nên nói chung là ít (lưu lượng lẫn số phiên chiếm trong state table), các dịch vụ như Web/HTTP Protocol lại rất ổn với NAT, nên nó rất hữu dụng. Sau 20 năm thì home router (đóng vai trò NAT) chế tạo nhiều, rẻ, các kiểu, có cả tính năng wifi bên cạnh mạng dây, nối mạng Internet quang tốc độ cao hơn nhiều lần, dùng NAT dễ hơn nhiều lần, mặc định ở các router này. NAT trở thành de-factor của kỹ thuật áp dụng truy cập Internet cho mọi mạng gia đình và công ty văn phỏng nhỏ trên thế giới hiện nay.

NAT dầu là de-factor, nó bản chất vẫn là một giải phát kỹ thuật mang tính tình thế (work-around) cho truy cập mạng Internet, vì thực tế chi phí triển khai lẫn hạn chế công nghệ là thứ tạo ra nó. NAT là thứ mà cha đẻ bộ giao thức TCP/IP (nền tảng công nghệ của Internet) không tính đến khi phát minh ra TCP/IP ngay từ đầu, do đó rất nhiều giao thức Internet khác nhau khi thiết kế không tính đến, không chạy ổn lắm khi bị NAT. Tôi sẽ viết tiếp về mấy điểm này ở các bài sau.