NAT là kỹ thuật  thay đổi các địa chỉ mạng (Network Address) trong một gói tin (packet) để gây ảnh hưởng trong quá trình định hướng đi của packet cho một mục đích cụ thể. Địa chỉ mạng ở đây muốn nói đến địa chỉ IP  (Internet Protocol) ở layer  3, ngoài ra còn có thể thay đổi số port ở layer  4 theo mô hình phân lớp OSI. Bên cạnh đó địa chỉ mạng còn được phân biệt địa chỉ nguồn (source) và địa chỉ đích (destination). Tùy theo mục đích dùng NAT mà ta thay đổi một số hoặc tất cả các loại địa chỉ trên trên cùng một packet.

Xét mô hình load balancing như sau

 

Chúng ta sẽ xem các kỹ thuật  NAT sử dụng trong load balancing như thế nào.

Destination NAT

Đây là loại hình NAT phổ biến nhất, ta còn hay gọi là "NAT xuôi", hay "NAT vào". NAT theo kiểu này chỉ thay đổi địa chỉ IP  đích của gói tin mà không đụng đến các thành phần khác. Đây cũng là kiểu được sử dụng mặc định trong load balancing theo cách sau:

- Khi client gửi packet request R tới bộ cân bằng tải (load balancer), R sẽ có dest IP là VIP của load balancer (141.149.65.3), source IP là IP của client (188.1.1.10). Do load balancer đại diện cho tất cả những server  thực đằng sau nên IP của load balancer cũng là địa chỉ đại diện, client sẽ chỉ liên hệ với load balancer mà không biết  được địa chỉ thật của các server  là gì. Địa chỉ IP đại diện của load balancer còn được gọi là địa chỉ IP  ảo (Virtual IP - VIP)

- Load balancer sẽ gửi R đến server  2 để xử lý nên nó thực hiện thay dest IP trong R thành IP của server  2 (10.10.10.20), source IP vẫn giữ nguyên (188.1.1.10). Thao tác này gọi là Destination NAT.

- Nhờ có dest IP là IP của server  2 nên R sẽ được định tuyến tiếp đến server  2 xử lý.

- Khi server  2 trả lời, packet reply sẽ đi qua lại load balancer. Tại đây packet được un-NAT, nghĩa là thay lại địa chỉ IP  của server  2 (lúc này trở thành source IP) bằng VIP của load balaner.

Reverse NAT

Trong cơ chế load balancing, các server  thật chỉ được cấp địa chỉ IP  private (vì nhiều lý do, trong đó có sự hạn chế về số lượng  IP public và tính bảo mật), nghĩa là không thể đi ra Internet  được. Load balancer thường được public ra Internet  để nhận request cho các server  bên trong nên nó thường có một địa chỉ IP  public để các client kết nối từ bên ngoài vào, và địa chỉ này cũng là VIP. Khi client muốn sử dụng dịch vụ  của server  bên trong, load balancer thực hiện việc chuyển đổi địa chỉ dest IP từ public sang private để đến được server, đó là kiểu NAT ta xét ở trên. Trong trường hợp ngược lại, khi server  bên trong muốn khởi tạo kết nối với bên ngoài Internet, load balancer phải thực hiện việc chuyển địa chỉ source IP của packet đi ra từ private sang public để có thể lưu thông trên Internet. Do cách hoạt động  như vậy nên kiểu NAT này còn được gọi là SourceNAT, "NAT ngược", hay "NAT ra".

Port-Address Translation (PAT)

Hai trường hợp trên ta đã xem xét hai kiểu thay đổi địa chỉ IP, trường hợp thứ ba  này còn được gọi là "NAT port", nghĩa là số port TCP/UDP ở trong packet sẽ bị thay đổi (ở đây ta không xét đến các protocol  khác cũng có dùng port). PAT cũng là một phần tất yếu của load balancing. Cách hoạt động  của nó cũng rất đơn giản: Khi ta liên kết (bind) port 80 của VIP trên load balancer đến port 1000 trên server  thật, load balancer sẽ thực hiện việc chuyển đổi và đẩy toàn bộ yêu cầu port 80 (dest port) đến port 1000 trên server.

Những lợi ích khi ta thực hiện PAT:

- Bảo mật  là ích lợi đầu tiên mà ta thấy ngay. Bằng cách không mở những cổng mặc định trên server, ta có thể gây khó khăn hơn cho việc tấn công  ác ý. Chẳng hạn, ta có thể chạy một Web  server  trên port 4000, và liên kết port 80 của VIP trên load balancer đến port 4000 của server  thật. Lúc bấy giờ, kẻ tấn công  không thể khai thác trực tiếp  lên port 80 của server  thật được, vì nó không được mở.
- Khả năng co dãn (scalability) PAT cho phép ta chạy cùng một ứng dụng  trên nhiều port. Tùy theo cách thiết kế  ứng dụng, có thể việc chạy nhiều bản sao của nó sẽ làm tăng hiệu suất  phục vụ lên. Chẳng hạn ta có thể chạy máy chủ  web  IIS trên các port 80, 81, 82 của mỗi server  thật. Sau đó chỉ cần liên kết port 80 của VIP với mỗi port chạy IIS của server  thật. Load balancer sẽ phân bổ lưu thông không chỉ cho các server  mà còn giữa các port trên từng server.
- Khả năng quản trị  (manageability) chẳng hạn khi host nhiều website  trên một bộ các server  thật, ta có thể chỉ cần dùng một VIP để đại diện cho tất cả các domain  của các website. Lúc này load balancer sẽ nhận tất cả các request đến port 80 ở cùng một VIP. Web  server  của ta có thể chạy mỗi domain  trên một port khác nhau, chẳng hạn www.abc.com trên port 81, www.xyz.com trên port 82. load balancer có thể gửi lưu thông đến port phù hợp dựa trên domain  trong URL của mỗi HTTP request.

Full NAT

Như vậy ta đã xét kỹ thuật  NAT thay đổi lần lượt địa chỉ đích, địa chỉ nguồn, rồi thay đổi port khi cân bằng tải. Mỗi sự thay đổi là một loại hình NAT có ứng dụng  trong từng trường hợp riêng. Kết hợp các kiểu thay đổi này lại, ta có một kiểu NAT khác phức tạp hơn là Full NAT. Kiểu NAT này có tên gọi như vậy vì nó bao gồm các thay đổi sau đây trên gói tin request:
- Địa chỉ IP nguồn (source IP)
- Địa chỉ IP đích (dest IP)
- Port nguồn (source port)

Lưu ý source port ở đây là port của client, còn dest port là port được request trên server, chẳng hạn port 80 ở ví dụ trên.

Xem mô hình như sau:

 

Mô hình load balancing này khác với mô hình trong những kiểu NAT trên ở chỗ, packet từ server  reply có thể bỏ qua load balancer mà đi thẳng đến client ở ngoài Internet. Vấn đề ở chỗ địa chỉ IP  của server  vẫn là private IP, do đó đương nhiên packet reply mang "biển số tỉnh" sẽ chẳng bao giờ đến được client.

Vậy thì bằng cách nào để buộc server  phải trả lời thông qua load balancer để được NAT địa chỉ IP  đi ra Internet? Cách đơn giản nhất là ta có thể khai báo cho load balancer là default gateway của các server. Nhưng cách này yêu cầu load balancer phải ở cùng subnet với các server  (cùng Layer  2 broadcast domain). Nếu không thể nằm cùng subnet thì sao? Đây là chỗ Full

NAT được sử dụng.

Khi được thiết lập để thực hiện Full NAT, load balancer sẽ thay source IP của tất cả các request packet bằng một địa chỉ được khai báo trên load balancer, xem như là source IP, rồi thay dest IP (lúc này đang là VIP) thành IP của server  (10.10.10.20), trước khi gửi đến server  2. Source IP này có thể giống hoặc khác VIP, tùy vào từng sản phẩm  load balancer. Như vậy tương tự như proxy, lúc này server  thật sẽ xem load balancer như là client yêu cầu mình, và không quan tâm  đến client thực sự nữa. Vì thế server  sẽ reply lại cho load balancer và load balancer sẽ đổi lại dest IP thành IP của client thực sự (188.1.1.100) để gửi đi.

Như vậy source port được thay đổi ở chỗ nào? Mỗi lần thay đổi một source IP của client thành source IP của load balancer, gọi là một session, thì load balancer thực hiện lưu lại những thông tin  của client trong session đó bằng cách đổi source port trong cùng packet (lúc này đang là source port của client).

Source port lúc này có ý nghĩa như là một session ID không hơn không kém. Khi server  reply về cho load balancer, source port cũng được gửi trả về theo packet reply. Dựa vào source port này, load balancer xác định được session của client trong bảng lưu để thay lại source IP, source port của client như cũ.

Ưu điểm của kiểu NAT này là cho phép bạn thực hiện việc thay đổi địa chỉ thông qua load balancer trên mọi topology mạng. Nhược điểm là không lấy được các thông tin  về IP, port từ phía client. Những ứng dụng  như Web  có sử dụng thông tin  từ source IP của client thì không nên dùng mô hình này. Một số sản phẩm  load balancing còn cung cấp chức năng log và report source IP của các request.

Enhanced NAT

Những kỹ thuật  NAT vừa trình bày ở trên đều xoay quanh việc thay đổi địa chỉ IP, cũng như port trong packet header. Tuy nhiên có những protocol  đặc biệt chứa thông tin  địa chỉ hay port nhúng trong packet payload, cũng cần phải được thay đổi cùng với packet header.

Điều này đòi hỏi load balancer phải hiểu biết theo từng protocol  cụ thể. Khái niệm enhanced NAT nói đến kiểu NAT phức tạp được BLer thực hiện với những hiểu biết theo từng protocol  cụ thể để làm cho những protocol  đó hoạt động  được với việc cân bằng tải.

Trong số các protocol  đặc biệt đó, thông dụng nhất là các protocol  streaming media  (ví dụ RTSP - Real  Time Streaming Protocol). Đây cũng là các protocol  sử dụng cân bằng tải phổ biến nhất, vì chúng cực kì ngốn tài nguyên  mạng và tính toán khi phải phục vụ đồng thời cho hàng trăm đến hàng ngàn người sử dụng.

Các protocol  streaming thường gồm có hai kết nối, một kết nối điều khiển xây dựng  trên TCP và một kết nối dữ liệu  dựa trên UDP. Để khởi đầu, client khởi tạo một kênh điều khiển đến một well-known port trên server. Client và server  sẽ thoả thuận các điều khoản cho kênh điều khiển. Sự thoả thuận gồm có IP của server  và số port của server  mà client sẽ gửi dữ liệu  đến trên kết nối dữ liệu.

Nếu các server  có địa chỉ IP  private, load balancer sẽ thực hiện Destination NAT cho kết nối điều khiển. Nhưng đồng thời load balancer cũng phải xem các thông tin  thoả thuận và thay đổi mọi thông tin  về địa chỉ IP  hay port mà server  và client trao đổi sao cho client sẽ gửi dữ liệu  đến VIP public chứ không phải IP private của server  (những thông tin  này nằm trong payload của packet).

Hơn nữa, dest port được chọn trong quá trình thoả thuận lại không biết  trước được nên BLer phải xử lý request ngay cả khi port chưa được liên kết đến bất kỳ server  nào.

Tuy nhiên, nhiều doanh nghiệp  lại có những chính sách bảo mật  trên tường lửa làm cho những kết nối dữ liệu  trên nền tảng UDP có thể không thành công. Do đó nhiều hệ thống  streaming media  cho phép stream trên nền HTTP, nghĩa là toàn bộ dòng dữ liệu  sẽ được gửi đi bằng kết nối được thiết lập bởi giao tiếp HTTP. Điều này làm cho việc NAT trở nên nhẹ nhàng hơn.

Direct Server  Return (DSR)

Lại xét mô hình cân bằng tải thứ hai. Với mô hình này ta đã xem hai cách xử lý cùng với các ưu nhược điểm của chúng là gán BLer làm default gateway hay dùng kỹ thuật  Full NAT để ép các reply của server  phải đi qua load balancer.

Nhưng trường hợp ta muốn server  trả lời trực tiếp  cho client mà không thông qua BLer thì sao? Đây không phải là câu hỏi  vô lý, vì trong trường hợp năng lực xử lý  của BLer bị giới hạn, thì việc tách dòng lưu thông reply đi trực tiếp  mà không qua BLer sẽ giúp load balancer tập trung vào xử lý các lưu thông request hiệu quả hơn, tránh tắc nghẽn, nâng cao hiệu suất.

Nhưng với địa chỉ IP  private, các server  làm sao trả lời trực tiếp  qua Internet  đến client được? Chỉ với một chút phù phép xoay quanh các địa chỉ IP  là vấn đề sẽ được giải quyết: khi được thiết lập để thực hiện DSR, load balancer không chuyển dest IP thành IP của server  mà vẫn giữ nguyên là VIP (public IP). load balancer chỉ đổi dest MAC  thành MAC  của server  để packet có thể đến được server. Như vậy giới hạn của DSR là load balancer và các server  phải nằm cùng subnet.

Vấn đề còn lại là làm sao để khi server  nhận request packet từ load balancer chuyển đến sẽ không từ chối, vì dest IP không phải là IP của server, mà là VIP! Một cách đơn giản, ta cấu hình để VIP là địa chỉ của loopback interface trên mỗi server. Load balancing dùng cách này vì lợi dụng những tính chất thú vị sau đây của loopback interface:

- Có thể gán bất kỳ địa chỉ IP  nào, không bắt buộc phải bắt đầu bằng 127.

- Vì loopback interface không phải là một thiết bị thật, nó không có địa chỉ MAC, nên hệ thống  sẽ không trả lời cho các request ARP. Do đó sẽ không có hệ thống  bên ngoài nào biết được địa chỉ IP  của loop back interface. Tuy nhiên, hệ thống  vẫn nhận request đến IP của loop back interface và trả lời như là các interface khác.

Ta có thể thiết lập một địa chỉ IP  public cho loop back interface trên Linux  như sau:

ifconfig lo 141.149.65.3 netmask 255.255.255.0 up

Như vậy, bằng một chút thủ thuật với các địa chỉ, server  thật không cần địa chỉ IP  public vẫn có thể nhận request và trả lời trực tiếp  cho client.

DSR rất hữu ích cho những ứng dụng  tốn băng thông như FTP, streaming media, khi mà kích thước  packet reply là rất lớn so với kích thước  packet request. Kỹ thuật  này cũng được ứng dụng  cho những protocol  đòi hỏi phức tạp khi thực hiện NAT hay không được load balancer hỗ trợ.

Chẳng hạn những giao thức streaming media  như trong phần Enhanced NAT có đề cập, thì ta có thể dùng DSR thay vì NAT. Người ta cũng cân nhắc DSR khi triển khai load balancing trên mô hình mạng như mô hình 2, khi mà lưu thông reply từ server  không đảm bảo là sẽ đi qua lại load balancer.

Kết luận

NAT tạo nên nền tảng của load balancing. NAT trong load balancing rất đa dạng, tùy thuộc vào từng tình huống mà ta áp dụng. Càng đi sâu, ta càng thấy cái hay trong việc xử lý thông tin  của các packet, những đối tượng luận lý để giải quyết các vấn đề vật lý thú vị như thế nào. Nắm vững các kỹ thuật  NAT giúp ta có thể triển khai các hệ thống  cân bằng tải một cách an toàn và hiệu quả nhất.

Bạn có ý kiến gì về bài viết Nghệ thuật NAT - Phần 1: Các yếu tố kỹ thuật cho người dùng cấp cao này? Hãy gởi suy nghĩ, bình luận, đánh giá, lời khuyên ... của bạn về bài viết Nghệ thuật NAT - Phần 1: Các yếu tố kỹ thuật cho người dùng cấp cao bạn tại đây.