Kỹ thuật NAT
By huyxNội dung:
- -1-Giới thiệu
- -2-Các kỹ thuật NAT cổ điển
* NAT tĩnh
* NAT động
* Masquerading(NAPT) - -3-Các kỹ thuật NAT khác
* Virtual Server(Load balancing)
* Multiple routes per Destination - -4-Các vấn đề cần giải quyết cho kỹ thuật NAT
* Lưu giữ thông tin trạng thái
* Phân chia (fragmentation)
* Định ra giao thức (protocol) cụ thể
Trình bày
1) Giới thiệu:
Lúc đầu, khi NAT được phát minh ra nó chỉ để giải quyết cho vấn đề thiếu IP .Vào lúc ấy không ai nghĩ rằng NAT có nhiều hữu ích và có lẽ nhiều ứng dụng trong những vấn đề khác của NAT vẫn chưa được tìm thấy.
Trong ngữ cảnh đó nhiều người đã cố gắng tìm hiểu vai trò của NAT và lợi ích của nó trong tương lai.Khi mà IPv6 được hiện thực thì nó không chỉ giải quyết cho vấn đề thiếu IP.Qua nhiều cuộc thử nghiệm họ đã chỉ ra rằng viêc chuyển hoàn toàn qua IPv6 thì không có vấn đề gì và mau lẹ nhưng để giải quyết những vấn đề liên qua giữa IPv6 và IPv4 là khó khăn.Bởi vậy có khả năng IPv4 sẽ là giao thức chủ yếu cho Internet và Intranet … lâu dài hơn những gì họ mong muốn.
Trước khi giải thích vai trò của NAT ngày nay và trong tương lai ,những người này muốn chỉ ra sự khác nhau về phạm vi của NAT được sủ dụng vào ngày đó.Sự giải thích sẽ đưa ra một cái nhìn tổng quan và họ không khuyên rằng làm thế nào và nên dùng loại NAT nào.Sau đây chỉ là giới thiệu và phân loại các NAT phần chi tiết sẽ được thảo luận và đề cập trong chương sau khi hiện thực NAT là một laid out.
Phần trình bày được chia làm 2 phần :
- Phần đầu được đặt tên là CLASSIC NAT nó là các kỹ thuật NAT vào những thời kỳ sơ khai (đầu những năm 90) được trình bày chi tiết trong RFC 1931. Ứng dụng của nó chủ yếu giải quyết cho bài toán thiếu IP trên Internet.
- Phần hai trình bày những kỹ thuật NAT được tìm ra gần đây và ứng dụng trong nhiều mục đích khác.
2)Các kỹ thuật NAT cổ điển:
Nói về NAT chúng ta phải biết rằng có 2 cách là tĩnh và động .Trong trường hợp đầu thì sự phân chia IP là rõ ràng còn trường hợp sau thì ngược lại.Với NAT tĩnh thì một IP nguồn luôn được chuyển thành chỉ một IP
đích mà thôi trong bất kỳ thời gian nào.Trong khi đó NAT động thì IP này là thay đổi trong các thời gian và trong các kết nối khác nhau.
Trong phần này chúng ta định nghia :
m: số IP cần được chuyển đổi (IP nguồn)
n: số IP sẵn có cho việc chuyển đổi (IP NATs hay gọi là IP đích)
* NAT tĩnh
Yêu cầu m,n>=1;m=n(m,n là số tự nhiên)
Với cơ chế IP tinh chúng ta có thể chuyển đổi cùng một số lượng các IP nguồn và đích .Trường hợp đặc biệt là khi cả 2 chỉ chứa duy nhất một IP ví dụ netmask là 255.255.255.255 .Cách thức hiện thực NAT tĩnh thì dễ dàng vì toàn bộ cơ chế dịch địa chỉ được thực hiện bởI một công thức đơn giản:
Địa chỉ đích =Địa chỉ mạng mới OR (địa chỉ nguồn AND ( NOT netmask))
Không có thông tin về trạng thái kết nối.Nó chỉ cần tìm các IP đích thích hợp là đủ.
Các kết nối từ bên ngoài hệ thống vào bên trong hệ thống thì chỉ khác nhau về IP vì thế cơ chế NAT tĩnh thì hầu như hoàn toàn trong suốt.
Ví dụ một rule cho NAT tĩnh:
Dịch toàn bộ IP trong mạng 138.201.148.0 đến mạng có địa chỉ là 94.64.15.0,netmask là 255.255.255.0 cho cả hai mạng.
Dưới đây là mô tả việc dịch từ địa chỉ có IP là 138.201.148.27 đến 94.64.15.27,các cái khác tương tự.
10001010.11001001.10010100.00011011 (host 138.201.148.0)
AND
00000000.00000000.00000000.11111111 (reverse netmask)
01011110.01000000.00001111 (new net: 94.64.15.0)
01011110.01000000.00001111.00011011 (địa chỉ mới )
* NAT động
Yêu cầu m>=1 và m>=n
NAT động được sử dụng khi số IP nguồn không bằng số IP đích.Số host chia sẻ nói chung bị giới hạn bởi số IP đích có sẵn.NAT động phức tạp hơn NAT tĩnh vì thế chúng phải lưu giữ lại thông tin kết nối và thậm chí tìm thông tin của TCP trong packet.
Như đã đề cập ở trên NAT động cũng có thể sử dụng như một NAT tĩnh khi m=n.Một số người dùng nó thay cho NAT tĩnh vì mục đích bảo mật.Những kẻ từ bên ngoài không thể tìm được IP nào kết nối với host chỉ định vì tại thời điểm tiếp theo host này có thể nhận một IP hoàn toàn khác.Trong trường hợp đặc biệt thậm chí có nhiều địa chỉ đích hơn địa chỉ nguồn (m
Bất cứ khi nào nếu một kẻ từ bên ngoài muốn kết nối vào một host chỉ định ở bên trong mạng tại một thời điểm tùy ý chỉ có 2 trường hợp :
+ Host bên trong không có một entry trong bảng NAT khi đó sẽ nhận được thông tin “host unreachable” hoặc có một entry nhưng NAT-IPs là không biết.
+ Biết được IP của một kết nối bởi vì có một kết nối từ host bên trong ra ngoài mạng.Tuy nhiên đó chỉ là NAT-IPs và không phải là IP thật của host.Và thông tin này sẽ bị mất sau một thờii gian timeout của entry này trong bảng NAT router.
Ví dụ về một rule cho NAT động:
Dịch toàn bộ những IP trong class B ,địa chỉ mạng 138.201.0.0 đến IP trong class C 178.201.112.0.Mỗi kết nối mới từ bên trong sẽ được liên kết với tập IP của class C khi mà IP đó không được sử dụng.
– Xem thêm hình vẽ mô tả trong tài liệu NAT của SuSe –
*Masquerading(NAPT)
Yêu cầu m>=1 và n=1
Đây là một trường hợp đặc biệt của NAT động.Thuật ngữ Masquerading trở nên nổi tiếng bởi vì nó được hiện thực trong thế giới Linux .Nó là loại NAT được sử dụng hầu hết vào thời điểm đó.Với cơ chế này nhiều địa chỉ IP được ẩn đi dưới một địa chỉ duy nhất.Nó tương phản với NAT động ,rằng chỉ có một kết nối cho một IP duy nhất tại một thời điểm .Trong masquerading nhiều kết nối đến cùng một IP sẽ được phân chia thông qua TCP Port.Vấn đề đặc biệt của Masquerading là một số service trên host chỉ định chỉ chấp nhận kết nối từ những port đặc quyền để đảm bảo rằng kết nối đi vào không phải là từ một user bình thường.Có lẽ chỉ superuser có thể xử lý những port này.Vì trên DOS hoặc Window mọi người đều có thể sử dụng chúng nên một số chương trình không thể sử dụng kết nối masquerading.Masquerading thường sử dụng những port ở một tầm vực cao.Trong Linux ,bắt đầu là 61000 và kết thúc là 61000+4096.Mặc định này có thể thay đổi bằng cách edit /linux/include/net/ip_masq.h
Điều này cũng chỉ ra rằng Linux hiện thực masquerading chỉ cho đồng thời 4096 kết nốI masquerading .Kết nối masquerading cần phải lưu giữ nhiều thông tin về trạng thái kêt nối.Ví dụ trên Linux, nó xem như tất cả các packet với Destination IP= Local IP và Destination port nằm trong tầm port cho phép của Masquerading khi phải demasqueraded(phân giải những packet đã được masqueraded) Thực chất là việc thay đổi destination address và source address trong header packet.
Rõ ràng Masquerading chỉ có một chiều . Những kết nối vào thì không thể Masquerading .Vì thậm chí khi một host có một entry trong masquerading table của NAT device thì entry này chỉ hợp lệ khi một kết nối đang được active.Ngay cả một ICMP-Reply liên quan đến kết nối (host/port unreachable) cũng phải được filter và relay bởi NAT router.
Trong khi thật sự kết nối vào không thể Masquerading nhưng chúng ta có thể thêm vào để cho phép điều đó tuy nhiên chúng không phải là một phần thuộc về Masquerading .Chúng ta có thể làm điều đó ví dụ setup một NAT device để nó relay tất cả các kết nối từ bên ngoài đến port telnet của một host bên trong Tuy nhiên vì chúng ta chỉ có một IP được thấy từ bên ngoài cho phép kết nối vào cho cùng một service nhưng cho các host khác nhau bên trong mạng .Chúng ta phải cho lắng nghe trên một port khác Vì nhiều service trên những well-known port thì không thể thay đổi hoặc việc thay đổi là bất tiện đặc biệt trên những pulic server.Ví dụ 80 cho HTTP , 23 cho TELNET. Chỉ có một cách giải quyết là phải có nhiều IP đích khi các service này tăng lên.Một IP đích có thể vẫn đuợc chia sẻ bởi những service khác nhau và rồi được remap với những IP nguồn khác bên trong mạng .Nhưng đây không phải là Masquerading.
Ví dụ cho một rule của Masquerading
- Masquerading cho mạng 138.201.0.0 dùng NAT đến IP local
- Cho mỗi packet IP đi ra source IP sẽ được thay bởi IP của NAT router.Source port sẽ được đổi thành một port nằm trong tầm của Masquerading.
– Xem thêm hình vẽ mô tả trong tài liệu NAT của SuSe –
Lợi ích lớn nhất của Masquerading là chỉ cần một IP được cấp mà toàn mạng vẫn có thể kết nối trực tiếp đến Internet ,điều này là quan trọng vì địa chỉ IP thì qúa mắc.Mặc dù đối với những ứng dụng mức gateway chúng ta không cần thêm bất kỳ IP và bất kỳ loại NAT nào và một IP thì vẫn đủ nhưng cho một số giao thức thí dụ tất cả UDP based service nó thì không chỉ là mức gateway mà cần phải kết nối IP trực tiếp. Tham khảo thêm RFC 1631(NAT) được đề cập là Network Address Port Translation (NAPT)
3)Các kỹ thuật NAT khác
*Virtual Server (Loadbalancing)
NAT router đóng vai trò là một virtual server và các kết nối vào sẽ được chuyển đến 2 hay nhiều server thật .Phụ thuộc vào giải thuật được xây dựng mà kết nối này sẽ đi vào server nào ở bên trong.
Ví dụ một NAT rule như sau:
- Tạo một virtual server với IP là 138.201.14.100
- Sử dụng 2 host là 138.201.14.111 và 148.201.14.112 là những real server cho virtual server.
- Một kết nối từ bên ngoài sẽ được remap bởi NAT router để sử dụng một trong 2 host (realserver)
– Xem thêm hình vẽ mô tả trong tài liệu NAT của SuSe –
+ Load Balancing
Giải thuật để quyết định real server nào được kết nối. Cho ví dụ kiểm tra tải trên những realserver dựa trên việc đếm số packet trên mỗi giây đi qua NAT device đến real server sau đó sẽ chọn ra realserver có hiệu năng nhất.Bằng cách ấy sẽ điều chỉnh được traffic trên mạng và giảm tải cho các server.Số giải thuật được sử dụng ở đây thì không thể đếm được và dựa trên những cách tính toán khác nhau nhưng tất cả đều có chung mục đích là giảm tải cho server.Khái niệm “tải” ở đây thì không rõ ràng và không được đĩnh nghĩa duy nhất.
Cho ví dụ về loadbalancing:
Chạy một deamon trên mỗi server cung cấp thông tin cho NAT router về tải (load) trên máy này và remap những kết nối mới đến hệ thống nơi mà số này là thấp nhất.
Điều này đòi hỏi sự liên lạc giữa những host(real server) và NAT router vì thế chúng ta nên sử dụng những thông tin có trên NAT router như là số kết nối hiện tại đang được remap đến một host hoặc ta phải sử dụng những thông tin vốn không có trên server nhưng có thể dễ dàng được tìm thấy như là số byte hoặc packet mỗi giây của một host hiện tại handle.Yếu tố được đề cập ở đây sẽ là một vài ý niệm để quyết định việc đạt được sự cân bằng trong việc phân bố tải Chính xác hơn là chúng ta cố gắng đo lường và tính toán tải cho mỗi host.Có một số giải thuật ví dụ như giải thuật dựa trên học thuyết về nguyên lý không chắc chắn trong định lượng của Heisenberg.
Vì thế chúng ta phải tìm cách làm tối thiểu chi phí của host để quyết định tải và host sẽ được kết nối.
Ngay cả khi chúng ta giả sử đã tìm ra một phương thức chính xác và tốt để quyết định tải được sử dụng dựa trên việc định nghĩa “tải” là gì thì thực tiễn vẫn chưa phải là giải pháp tốt nhất vì một IP packet có kích thước nhỏ nhất chỉ được xác định bằng cách định lượng vật lý.Chúng ta có thể chỉ mới chọn được host nào chúng ta cần gửi kết nối đến khi một kết nối mới được mở mà chưa thật sự tối ưu.Tuy nhiên dù sao đi nữa các phương thức đề cập ở trên cũng có thể được áp dụng vào thực tiễn cho việc xác định cân bằng tải ngoài ra có thể có một cách tính toán nào đó tốt nhất mà chúng ta chưa tìm ra.
Có nhiều cách tiếp cận để giải quyết cho bài toán Load balancing ,hầu hết trong số chúng đều ở mức application.Một ví dụ được mô tả trong RFC 1794 đó là dùng DNS support cho Load balancing.Trong tài liệu này đề cập đến việc dùng DNS cho việc điều khiển tải của máy bằng cách tìm ra IP của máy ít bận rộn nhất khi được chất vấn (queried) Vì DNS-queries sẽ được cache bởi liên tiếp các DNS-server với việc điều khiển các giới hạn một cách khắt khe.Nó làm việc hoàn toàn tốt khi có nhiều chất vấn và ngay cả khi chúng đến từ nhiều máy client.Tuy nhiên dù cho Load balancing có làm việc trong trạng thái tốt thì cách tiếp cận này sẽ không giúp được gì một khi server bị fail vì thậm chí ngay cả khi các IP được phân chia riêng biệt trong việc chất vấn thì nó vẫn còn được cache do đó khi server bị fail thì có thể server này là hiệu năng nhất và cơ chế load balancing hoàn toàn bị phá vỡ .Một ví dụ cho chương trình cache nổi tiếng là Squid nó sử dụng giải thuật phức tạp để tìm ra một mục tiêu tốt nhất.Giải quyết này chưa hẳn đã giống trên NAT nhưng mục tiêu của nó là như nhau.Với NAT chúng ta có thể phân bố tải cho những service lớn và đa dạng dựa trên IP còn Squid phục vụ cho một mục đích khác và sự so sánh này chưa hẳn đã hoàn toàn hợp lý.Người viết chọn squid là một ví dụ vì trong squid thực hiện việc load balancing để tìm ra một dữ liệu sao cho tối ưu một cách thông minh.
+ Backup Systems
Virtual server cũng có thể được sử dụng để đạt được khả năng phục vụ tốt nhất nếu giải quyết được bài toán một real server bất kỳ bị fail ở trên.Vì các service được cung cấp bởi Virtual server thì có khả năng trên bất kỳ real server . Đặt trường hợp một real server bị fail có xác suất là p thì một virtual server sử dụng N real server trong trường hợp bị fail có thể được tính toán như sau:
Đặt
+ p1..pn là khả năng xảy ra lỗi của server n trên N (N là số server được cung cấp cho virtual server)
+ pNAT: khả năng xảy ra lỗi của NAT router,lỗi này không phụ thuộc vào thiết bị khác
+ pvirt: khả năng xảy ra lỗi của virtual server khi một realserver bị fail
Công thức được tính toán là:
Pvirt=1-((1- [tích(pi) chạy từ 1->n]) X (1-pNAT))
Dĩ nhiên setup hệ thống sử dụng công thức trên cho việc tính toán load balancing phải thay đổi danh sách server được sử dụng bởi NAT router ngay khi một real server bị fail . Điều này không thuộc về NAT-code nhưng có thể thực hiện tốt ở mức cao ,thậm chí từ shell scripts.Quan trọng là phải có cơ chế remove server bị fail từ bảng virtual server vì thế phải xây dựng bảng virtual server có khả năng thay đổi dễ dàng
để những IP có thể thêm vào hoặc loại bỏ trong thời gian thực thi (runtime)
Như vậy với cách làm này chúng ta đã có một liên kết giữa 2 khả năng là load balancing và high availability dùng virtual server.Nó thì hoàn toàn trong suốt đốI với tất cả các host ,người sử dụng và những chương trình dùng virtual service.
*Multiple routers per Destination
Như ở trên chúng ta thấy chúng ta có thể dùng NAT để phân bố tải qua nhiều host và đạt được khả năng sẵn dùng cao (high availability) .Chúng ta có thể sử dụng NAT để làm điều này cho nhiều mạng không? Vâng chúng ta có thể. Ở phần trên chúng ta thấy chúng ta đã sử dụng virtual server thay thế cho nhiều host thật sự (real server)
Chúng ta cũng có thể tạo ra kết nối mạng ảo (virtual network) gồm nhiều mạch thật sự (real wire) dùng kỹ thuật virtual server.
Chúng ta có thể làm điều này với NAT như thế nào? Hãy tưởng tượng chúng ta có 2 nguồn cung cấp Internet (Internet provider).Chọn 2 bởi vì chúng ta không muốn xảy ra lỗi khi một nguồn bị hỏng.Mỗi host cần kết nối Internet phải có một IP duy nhất vì thế chúng ta mua cho mỗi host một IP từ 2 nhà cung cấp khác nhau.Như vậy chúng ta có thể sử dụng một trong 2 host để gửi packet đến cùng một vị trí.Bây giờ chúng ta sẽ setup cho hệ thống mô tả ở trên,chúng ta sẽ phân bố tải bằng cách sử dụng một ít host thông qua provider 1 và một vài cái khác thông qua provider 2 và chúng ta có “higher availibility” của kết nối đến Internet .Tuy nhiên chúng ta cũng có thể hình dung ra rằng rất khó thực hiện load balancing khi mỗi host quyết định gửi packet đi. Chúng ta không đề cập đến làm thế nào để một mạng dùng IP này hay IP khác. Ở đây vấn đề là sẽ sử dụng một “central authority” để quyết định host nào sẽ sử dụng provider nào dĩ nhiên thông qua một special NAT router.Sử dụng Nat máy tính Local của chúng ta chỉ cần một IP.Nếu chúng ta có một provider tin cậy chúng ta có thể sử dụng IP của provider này cung cấp đồng thời vẫn có thể sử dụng các IP bên trong mạng.Bây giờ nếu một host bên trong mạng muốn thiết lập một kết nối mới tới Internet nó chỉ cần gửi packet đến default router (NAT-router) với source IP là IP của host này.Do NAT-router biết được tất cả những kết nối đi ra,nó sẽ quyết định provider để gửi packet đi sao cho tối ưu.Nó sẽ thay source IP là IP của provider đã chọn và gửi packet đến router của provider này.Vì source IP là IP của provider cung cấp nên con đường đi tiếp theo của packet sẽ do provider quyết định thông qua provider router .Host gửi packet đi sẽ không bao giờ biết provider nào được chọn bởI NAT router vì thế xử lý là trong suốt.
Chúng ta có thể sử dụng cùng một giải thuật đã sử dụng cho Virtual server. Điểm khác nhau giữa ứng dụng là ở ứng dụng này chúng ta đã can thiệp vào xử lý routing.
4) Các vấn đề cần giải quyết cho kỹ thuật NAT
Có 5 khái niệm liên quan đến một connection cho NAT đó là:protocol,source IP và port ,Destination IP và port.Vì cơ chê NAT thay đổi các thông tin trong một packet nên ta có thể tạm chia thành 3 section:
-section 1: tiến trình packet đi từ source đến NAT-router
-section 2: tiến trình packet đi từ NAT-router đến Destination
-section 3: hoạt động diễn ra trong NAT-router,NAT router phải biết cả 2 section 1 và 2
Như vậy chỉ có NAT-router biết những gì thật sự xảy ra cho một packet. Điều đó cũng có nghĩa là NAT-device phải lưu giữ hầu hết thông tin về một kết nối để quyết định con đường đi của packet.
Chúng ta thấy NAT-router phần nào đó giống như một firewall bởi vì nó không chỉ relay packet từ nơi này đến nơi khác ,mà nó còn điều khiển luồng dữ liệu.NAT-router biết nhiều về mỗi kết nối như thể các thiết bị mạng biết về kết nối của nó.Nghĩa là chúng phải lưu giữ thông tin trạng thái .Chúng có thể đọc thông tin từ các packet ,so sánh và thay đổi nó.
* Lưu giữ thông tin trạng thái
Ngoại trừ NAT tĩnh,các cái còn lạI đòi hỏi chúng ta cần phảI lưu trữ và quản lý thông tin động từ client đang sử dụng hệ thống là một router.Thông tin này phảI được mất đi sau một thời gian timeout để NAT-IP được gắn cho một host còn có thể được sử dụng lại.Thời gian timeout cũng là một lý do tạI sao phảI đọc thông tin TCP-header.Timeout có thể ngắn cho một TCP-connection vừa được đóng và cao cho TCP-connection vẫn còn được thiết lập.Ví dụ nhiều telnet session có thể treo trong một thờI gian dài không có sự trao đổI bất kỳ packet nào .Trong trường hợp này,nếu chúng ta có đủ NAT-IP chúng ta không cần ngắt kết nốI này ,nhưng giả sử trong trường hợp nhiều kết nốI mớI được yêu cầu và NAT-IP cần có thêm IP thì chúng ta sẽ cho telnet session này bị chết để lấy lạI IP.
Một cách khác là chúng ta không giữ thông tin trạng thái mà chỉ cần tìm IP chỉ định (NAT-ip) Nó thì đơn giản hơn cho việc hiện thực NAT và trong nhiều trường hợp sẽ làm việc tốt cho các giải quyết ở trên.Khi luôn có đủ NAT-IP còn dư cho việc sử dụng chúng ta không chú ý tới chi tiết khác nhau của 2 cách ,ngoại trừ trong một telnet session hoặc các chương trình liên quan chẳng hạn như ssh.Chỉ khi số NAT-IP không nhiều và không đủ ,chúng ta mới cần lưu giữ thông tin trạng thái vì chúng ta có thể nhận ra ngay chính xác một kết nối vừa mới đóng và có thể lấy lại ngay IP đã cấp phát mà không cần hết thời gian timeout.Việc lưu giữ dấu vết của các kết nối khác nhau phục vụ cho mục đích bảo mật nếu nó được sử dụng bởI firewall, đây không hẳn chỉ là NAT.
Có một số trường hợp việc NAT chỉ truy tìm chỉ IP thì hoàn toàn không hiệu qủa. Đó là trong các ứng dụng virtual server và virtual network bởI vì traffic được sinh ra bởI một IP thì không thể nào phân chia được nữa.Khi chúng ta yêu cầu NAT truy tìm thêm cả TCP/UDP port thì chúng ta có thể cân bằng tảI và giảm traffic tốt hơn bằng cách remap các kết nốI đến một IP thích hợp
– Xem thêm hình vẽ mô tả trong tài liệu NAT của SuSe –
* Phân chia (fragmentation)
Quan hệ mật thiết vớI việc lưu giữ thông tin trạng thái về TCP và có thể là UDP là vấn đề IP fragment.Nó quyết định việc thay đổI không phảI chỉ IP address mà còn TCP/UDP port.Telnet packet có thể được đốI xử khác vớI HTTP packet.Cho một ví dụ chỉ sử dụng một virtual server hoặc DNS cho tất cả các service nó được map tới các host cung cấp service thực sự ,nhiều service thậm chí được cung cấp bởI virtual host.Một firewall là gateway mức application có thể làm được điều này nhưng gateway thì hầu như là không trong suốt.
Vấn đề là ngay khi một packet được fragment đến NAT-router ,nó không thể cung cấp thông tin về port ngoạI trừ fragment đầu tiên chứa TCP-header. Đó là lý do tạI sao chúng ta phảI lưu giữ những thông tin trạng thái về mỗI fragment.Chúng ta phảI lưu giữ tất cả thông dữ liệu của fragment đầu tiên gồm TCP/UDP port của nó để mà chúng ta có thể biết port của những fragment khác đang hoạt động.Nhiều khi phương pháp này không thích đáng vì IP layer không đảm bảo packet tới với đúng số thứ tự (sequence) Ví dụ fragment thứ 3 của packet đã được fragment có thể đi qua NAT router đầu tiên trước khi fragment đầu tiên vẫn còn lưu giữ thông tin port .Trong trường hợp này chúng ta sẽ ngăn lạI các fragment không phảI là fragment số 1 đến khi fragment số 1 đã tớI đích để chúng ta biết chúng ta có cần phảI thay đổI thông tin của packet hay không .Xem thêm về “IP fragment” ở các tài liệu khác.Việc thay đổI không chỉ IP mà còn TCP/UDP port thì không quan trọng nhưng chắc chắn hữu ích.
Ví dụ chúng ta sử dụng một virtual server .Giả sử chúng ta muốn tạo một virtual webserver và deamon của webserver thật sự đang chạy trên những máy khác nhau và lắng nghe trên những port khác nhau vì một số lý do.Khi đó nếu chúng ta không ghi nhận lạI destination port trong packet , default là port 80 đến virtual server và thay destination port là port mà real webserver đang lắng nghe vào packet reply thì chúng ta không thể có được những gì chúng ta mong muốn.Khi đó tất cả các real webserver phảI lắng nghe trên cùng một port mà virtual server cung cấp dịch vụ web (default là port 80).Xin nói thêm là một TCP connection thực hiện cơ chế handshaking 3 lần như vậy nếu packet reply không chỉ ra đúng port để kết nốI tớI thì kết nốI sẽ không được thiết lập.
* Định ra giao thức (protocol) cụ thể
NAT không phảI luôn luôn trong suốt như đã nói ,nó chỉ hoàn toàn trong suốt khi mà IP là giao thức nắm giữ thông tin về IP của một packet.Có một số giao thức chúng gửI IP là một phần của dữ liệu truyền đi.Như vậy nếu IP này đã được thay đổI vớI NAT router thì chúng ta sẽ gặp nhiều vấn đề trục trặc khi gửI tớI ngườI nhận .Nó không thể đúng IP đã được truyền đi.Một cách giảI quyết cho vấn đề này là tìm thông tin data truyền đi dựa trên một giao thức nào đó để biết được thông tin về IP đã được thêm vào.Qúa trình này chỉ làm thêm overhead và phức tạp hơn.
*Một số ví dụ cho những Protocol làm việc vớI NAT
FTP
FTP command PORT và response PASV cả 2 đều send một IP và port cho đầu kết nốI bên kia .Cho FTP để làm việc vớI một kết nốI đã bị thay đổI chúng ta phảI thay thế IP trong message . Điều này rất phức tạp vì IP và port được truyền đi dướI dạng mã ASSCII mô tả cho một số thập phân.Tức là mỗI số thập phân đơn lẻ được mô tả là một byte trong packet .Vì lý do này IP thì không có một chiều dài cố định trong một FTP-packet, bây giờ chúng ta thay thế IP hiện tạI bởI một IP khác ít hoặc nhiều số hơn ,packet sẽ lớn hoặc nhỏ đi điều này buộc phảI chỉnh lạI TCP –sequence number vì thế chúng ta phảI giữ một số thông tin về những kết nốI này để điều chỉnh các sequence number thích hợp trong mỗI packet . Đây không chỉ là vấn đề cho giao thức FTP mà còn cho nhiều giao thức khác mà khi thay đổI IP thì nó làm thay đổI chiều dài packet
ICMP
Một số ICMP message phụ thuộc vào loạI message ,nếu thêm vào header của packet có thể gây ra những vấn đề .Nếu packet này được thay đổI thì header này sẽ chứa NAT-Ip chứ không phảI IP của host sẽ nhận message ICMP này .Dựa trên điều này nếu bây giờ chúng ta không thay local IP mà là thêm vào NAT-Ip vào header thì điều này sẽ được giảI quyết.
DNS
Dễ thấy vấn đề ở đây là nếu một name service của một IP bên trong muốn cung cấp ra ngoài NAT-domain.Một cách giảI quyết là sẽ dùng 2 DNS service .Một cho việc giảI đáp cho các IP bên trong và một cái khác giảI đáp cho các IP ngoài mạng .Dĩ nhiên các IP được giảI đáp bởI DNS server thứ 2 không được đưa vào danh sách nhóm IP động cho NAT.NAT router thì hầu hết được đặt trên ranh giới giữa các mạng
phân chia internal DNS và external DNS và được mở rộng sử dụng cho lý do bảo mật
Nếu sử dụng một cách tiếp cận phức tạp hơn là ghi lại tất cả các DNS data đã được relay bởI NAT router chúng ta nên sử dụng một gateway mức ứng dụng hơn là hiện thực một NAT bởI vì DNS thích hợp vớI mức gateway hơn và chúng ta chỉ nên tác động tớI kernel khi thật sự cần thiết(xây dựng NAT)
BOOTP
Giao thức này không có vấn đề gì vớI NAT vì nó không đi ra khỏI ranh giớI của một NAT-domain.
Routing Protocol (RIP,EGP…)
Không cần phảI giảI thích tạI sao routing protocol gặp rất nhiều vấn đề vớI NAT .Có nhiều giao thức tìm đường khác nhau và làm việc vớI nó thì không dễ dàng chút nào
Có 3 cách giảI quyết là:
- Không sử dụng những giao thức này ,chỉ sử dụng static routing. Đây là cách chọn lựa tốt cho phần lớn các kết nốI từ mạng chúng ta ra bên ngoài thông qua NAT router
- Sử dụng một gateway mức ứng dụng
- Ghi lạI thông tin của packet
Đặc biệt 2 thư mục nằm trong System 32 của Win Xp, bạn có thể xoá chúng mà không sao cả: chiếm gần 300-400MB là dllcache và Reinstall backup.
