ICMP - Source Quench Message Analysis

Giới thiệu

Thông điệp ICMP Source Quench là loại thông điệp có thể được tạo ra bởi 1 gateway hoặc là 1 host. Bạn sẽ không thấy bất kỳ thông điệp nào như vậy hiện lên trên màn hình máy của bạn trừ khi bạn đang làm việc trên 1 gateway mà ở gateway đó sẽ xuất ra màn hình tất cả các thông điệp ICMP mà nó có. Tóm lại, 1 thông điệp ICMP Source Quench được tạo ra bởi 1 gateway hoặc 1 host đích để nói với người gửi giảm bớt tốc độ gửi tin bởi vì gateway hay host đó không thể theo kịp với tốc độ của dữ liệu mà nó nhận được.

Phân tích

Một gateway có thể loại bỏ các Internet datagram (hay packet) nếu nó không có 1 không gian đệm cần thiết để sắp xếp (lưu trữ tạm thời) những datagram đó cho đầu ra tới mạng tiếp theo trên tuyến đường tới mạng đích. Nếu 1 gateway loại bỏ 1 datagram, nó có thể gửi 1 thông điệp ICMP Source Quench tới host nguồn nơi gửi datagram đó.

Dưới đây là cấu trúc gói tin của thông điệp ICMP Source Quench:

ICMP - Destination Unreachable Message Analysis

Giới thiệu

Thông điệp 'ICMP Destination Unreachable' khá thú vị, bởi vì thực sự là nó không chỉ chứa 1 thông điệp mà có tới tận 6 thông điệp. Điều này có nghĩa là ICMP Destination Unreachable được chia thành 6 thông điệp khác nhau.

Bài này sẽ phân tích tất cả 6 thông điệp Destination Unreachable và giải thích mỗi thông điệp được sử dụng làm gì. Bảng dưới đây cho thấy 1 bảng tóm tắt ngắn gọn về các thông điệp sẵn có và giá trị của chúng có chứa trong ICMP Header.

Để khỏi lẫn lộn, thì các bạn hãy ghi nhớ rằng: ICMP Destination Unreachable là 1 thông điệp chung, các giá trị code khác nhau hoặc các thông điệp là 1 phần của nó là để làm rõ loại thông điệp "Destination Unreachable" nhận được là loại nào.

ICMP - Echo/Echo Reply (Ping) Message

Giới thiệu

Như đã được đề cập trong bài trước, 1 Echo chỉ đơn giản như hầu hết mọi người thường gọi là 1 "ping", Echo Reply là "ping reply". Các ICMP Echo được sử dụng chủ yếu để xử lý sự cố. Khi 2 host đang có vấn đề trong việc truyền thông với nhau, thì một vài yêu cầu ICMP Echo đơn giản sẽ cho ta thấy được liệu có vấn đề gì với các gói tin định tuyến trên đường truyền đến đích hay không.

Chúng ta hãy thử nhìn vào hình minh họa cho 1 gói ICMP Echo/Echo Reply:

Introduction to the ICMP Protocol

Internet Control Message Protocol, là 1 giao thức rất phổ biến và hỗ trợ cho sự hoạt động của giao thức IP. Vì giao thức IP được thiết kế để được hoàn toàn đáng tin cậy, nên ICMP sẽ được sử dụng để cung cấp thông tin phản hồi về các vấn đề đã tồn tại trong môi trường truyền thông.

ICMP là 1 trong những giao thức hữu ích nhất được cung cấp để khắc phục các vấn đề sự cố mạng như phân giải DNS, định tuyến, kết nối... Tuy nhiên bạn nên thận trọng vì bạn có thể phải dành ra nửa ngày chỉ để cố gắng tìm ra lý do tại sao bạn lại không nhận được 1 "ping trả lời" (thuật ngữ chính xác là 'echo reply') từ 1 máy chủ Web trong khi thực tế thì tường lửa của nó được cấu hình không trả lời 'pings' vì lý do an ninh. Điều này thường dẫn đến việc hầu hết các kỹ sư có kết luận không chính xác rằng các máy chủ từ xa có thể bị down.

Note

Một vài năm trước đây đã có 1 chương trình được phát hành, và hiện tại vẫn đang còn được chia sẻ trên Internet, gọi là Click. Click được thiết kế để chạy trên nền tảng Windows và chức năng của nó là để chống lại những người dùng mIRC. Chương trình sẽ sử dụng các thông điệp khác nhau có sẵn trong giao thức ICMP để gửi thông báo lỗi đặc biệt cho người dùng mIRC, làm cho những người dùng từ xa nghĩ rằng họ mất kết nối với IRC Server, và do đó ngắt kết nối chương trình tới máy chủ. Sự kì diệu không phải ở chỗ là những gì chương trình có thể làm, mà chính là làm thế nào để chương trình đó có thể làm như vậy. Đây là nơi mà 1 chuyên viên mạng thực sự sẽ có thể xác định và sửa chữa các điểm yếu an ninh mạng.

DNS Response Message Format

Giới thiệu

Bài trước chúng ta đã được giới thiệu về định dạng của thông điệp truy vấn DNS. Chúng ta đã phân tích khá chi tiết và cho thấy cách 1 máy sử dụng cờ Flags/Parameters để lựa chọn những tùy chọn (Option) khác nhau.

Trong bài này, chúng ta sẽ xem và phân tích những đáp ứng nhận được từ những truy vấn ở bài trước. Những đáp ứng của 1 truy vấn, trong trường hợp của 1 truy vấn đệ quy, đến trực tiếp từ máy chủ DNS mà chúng ta đã gửi truy vấn và trong trường hợp của 1 truy vấn không đệ quy sẽ đến từ các máy chủ DNS gần đây nhất mà các máy khách liên hệ để có được thông tin cần thiết.

Bài này là sự tiếp nối của bài trước đó, vì vậy hãy chắc chắn rằng các bạn đã hiểu được những bài trước của loạt bài DNS này để khi đọc bài này chúng ta có thể hiểu được 1 cách sâu sắc.

Phân tích DNS - Server Response

Đây là câu trả lời (được tô màu xanh) của truy vấn trước đó gửi đến 1 máy chủ DNS ở Úc (139.130.4.4), là nơi tôi yêu cầu phân giải tên miền www.firewall.cx:

Có 1 chi tiết đáng chú ý là thời gian để truy vấn này trở lại với máy của tôi. Thời gian từ lúc mà máy của tôi gửi gói tin cho đến khi nhận được câu trả lời 0.991 giây.

Trong 1 thời gian ngắn mà gói tin di chuyển từ Hy Lạp đến Úc, truy cập máy chủ DNS và máy chủ DNS đó đã gửi các truy vấn của nó cho đến khi tìm được câu trả lời và sau đó tạo ra 1 đáp ứng DNS để gửi trở lại Hy Lạp (nơi mạng gia đình của tôi).

Có rất nhiều yếu tố góp phần nên phản ứng khá nhanh này. Giao thức vận chuyển UDP, là giao thức không yêu cầu quá trình bắt tay 3 bước; tải trọng của máy chủ DNS mà tôi đã gửi truy vấn; tải trọng của các máy chủ DNS khác mà nó đã gửi yêu cầu; tốc độ của tất cả các máy chủ và của chính mạng gia đình và tải trọng chung giữa các router mà gói tin đã phải di chuyển qua để đến được các địa điểm khác nhau.

DNS Query Message Format

Giới thiệu

Bài này chúng ta sẽ đi vào phân tích các gói dữ liệu DNS (DNS packet). Chúng ta sẽ được thấy cách mà các thông điệp DNS được định dạng nên cùng với các các tùy chọn (Option) và các biến chứa trong những thông điệp đó. Để hiểu 1 giao thức, bạn phải hiểu thông tin mà giao thức đó mang từ 1 máy đến máy khác.

Bởi vì các định dạng thông điệp DNS có thể khác nhau, tùy thuộc vào đó là truy vấn hay là câu trả lời, nên tôi sẽ chia bài phân tích này thành 2 phần. Phần 1 phân tích định dạng DNS của 1 truy vấn, nói cách khác là sẽ cho thấy gói dữ liệu trông như thế nào khi chúng ta yêu cầu 1 máy chủ DNS phân giải 1 tên miền. Phần 2 phân tích định dạng DNS của 1 câu trả lời, chính là trả lời của máy chủ DNS về truy vấn của chúng ta.

Phân tích DNS - Host Query

Như đã đề cập trong bài trước, 1 truy vấn DNS được tạo ra khi 1 máy cần phải phân giải 1 tên miền thành 1 địa chỉ IP. Kết quả này có được là do việc bạn nhập "www.firewall.cx" trong thanh địa chỉ ở trên trình duyệt web của bạn hoặc chỉ đơn giản là bằng cách chạy 1 chương trình sử dụng Internet và từ đó tạo ra các truy vấn DNS để có thể giao tiếp thành công với máy chủ cần thiết.

Bây giờ tôi sẽ đưa ra 1 ví dụ để các bạn có thể hiểu rõ hơn. Hãy thử xem 1 gói tin có chứa truy vấn DNS trông sẽ như thế nào khi đang được truyền trên mạng:

Đây là gói tin đã được chụp lại và chúng ta sẽ chuẩn bị phân tích nó. Để tạo ra gói tin này, tôi đã gõ "ping www.firewall.cx". Dòng lệnh tạo ra gói tin này, bắt nguồn từ mạng của tôi và điểm đến của nó là 1 name server có địa chỉ ở Úc. Chú ý là cổng đích của gói tin này được thiết lập là 53, chính là cổng mà DNS hoạt động, và giao thức được sử dụng cho truy vấn DNS đó là UDP.

DNS Queries & Resolution Process

Giới thiệu

Bài này sẽ giúp các bạn hiểu được các truy vấn DNS hoạt động trên Internet và mạng gia đình của bạn như thế nào. Có 2 cách sử dụng hệ thống tên miền để phân giải 1 host hoặc 1 tên miền sang 1 địa chỉ IP và chúng ta sẽ xem xét từng cách một.

Các loại truy vấn và cách giải quyết

Như đã đề cập trong phần giới thiệu, có 2 cách cho 1 client sử dụng hệ thống tên miền.

Cách thứ nhất, client liên hệ với các máy chủ tên (điều này tương đương với 1 truy vấn không đệ quy) cùng 1 lúc cho tới khi nó tìm thấy máy chủ có chứa những thông tin mà nó yêu cầu. Cách khác là yêu cầu hệ thống máy chủ tên thực hiện bản dịch đầy đủ (điều này tương đương với 1 truy vấn đệ quy), trong trường hợp này, client sẽ gửi truy vấn và nhận được phản hồi có chứa địa chỉ IP của tên miền đang tìm kiếm.

Thật sự rất thú vị khi tìm hiểu về cách mà truy vấn DNS hoạt động như thế nào. Trong khi phân tích những gói tin được gửi và nhận từ các máy chủ DNS, tôi sẽ chỉ cho bạn cách mà client lựa chọn phương pháp mà client muốn truy vấn của nó sẽ được giải quyết.

Ví dụ về DNS Resolution

Chúng ta hãy cùng xem ví dụ sau:

Khi ai đó muốn truy cập trang web của Cisco (www.cisco.com), họ sẽ dùng trình duyệt web và gõ "http://www.cisco.com" hoặc "www.cisco.com" và sau 1 vài giây, trang web sẽ được hiển thị. Nhưng những gì xảy ra đằng sau những thao tác đó không phải ai cũng biết. Đó là những gì mà chúng ta sẽ tìm hiểu ngay bây giờ.

The DNS Protocol

Giới thiệu

Bạn đã bao giờ tự hỏi DNS đến từ đâu? Đây sẽ là những bài mà tôi và bạn sẽ cùng tìm hiểu về giao thức này. Bản tóm lược ngắn gọn về lịch sử DNS cũng sẽ giúp bạn hiểu lý do tại sao các máy chủ DNS đang chạy chủ yếu trên các hệ thống Linux và UNIX. Sau đó chúng ta có thể thấy DNS làm việc ở những tầng nào trong mô hình OSI và ở cuối bài này, tôi và bạn sẽ cùng tìm hiểu các Domain (tên miền) và các máy chủ DNS có cấu trúc như thế nào và làm sao để chúng đảm bảo được thời gian hoạt động và hiệu quả.

Lịch sử

DNS được sử dụng trong những ngày đầu khi Internet chỉ là 1 mạng nhỏ được tạo ra bởi Bộ Quốc Phòng Mỹ cho các mục đích nghiên cứu. Do đó mạng chỉ cần 1 file HOSTS chứa tất cả các thông tin cần thiết về máy tính ở trong mạng và giúp các máy tính chuyển đổi được thông tin địa chỉ và tên mạng cho tất cả các máy tính trong mạng một cách dễ dàng. Và đó chính là bước khởi đầu của hệ thống tên miền gọi tắt là DNS (Domain Name System).

Nhưng khi mạng máy tính ngày càng phát triển thì việc quản lý thông tin chỉ dựa vào 1 file HOSTS là rất khó khăn và không khả thi. Vì thông tin bổ sung và sửa đổi vào file HOSTS ngày càng nhiều và nhất là khi hệ thống máy tính được phát triển dựa trên bộ giao thức TCP/IP dẫn đến sự phát triển tăng vọt của máy tính:

- Lưu lượng và trao đổi trên mạng tăng lên.

- Tên miền trên mạng và địa chỉ ngày càng nhiều.

- Mật độ máy tính ngày càng cao do đó đảm bảo phát triển ngày càng khó khăn.

Đến năm 1984, Paul Mockpetris thuộc viện USC's Information Sciences Institute phát triển 1 hệ thống quản lý tên miền mới gọi là DNS và ngày nay nó ngày càng được phát triển và hiệu chỉnh bổ sung tính năng để đảm bảo yêu cầu ngày càng cao của hệ thống.

TCP Data

Giới thiệu

Cuối cùng, chúng ta đã đi đến bài cuối trong loạt bài phân tích về giao thức vận chuyển TCP. Bài này để dành riêng cho phần dữ liệu nằm tiếp sau TCP Header.

The Data

Chúng ta hãy cùng xem sơ đồ dưới đây:

Khi gói tin trên đến với người nhận, 1 quá trình mở gói là cần thiết để loại bỏ các phần được đóng gói thêm vào khi đi qua từng lớp của mô hình OSI. Sau đó, phần dữ liệu sẽ được đưa cho ứng dụng đang chờ đợi nó. Như vậy, khi gói tin được nhận đầy đủ bởi card mạng, nó được trao cho lớp 2 (Data Link), sau khi thực hiện kiểm tra lỗi ở trên gói tin, nó sẽ loại bỏ các thành phần liên quan đến lớp 2 (Data Link), có nghĩa là các khối màu vàng sẽ được loại bỏ.

Phần còn lại đó là IP Header, TCP Header, và dữ liệu, có thể gọi 3 phần đó là 1 IP Datagram, sẽ được đưa qua lớp 3 của mô hình OSI (Network) nơi các kiểm tra khác sẽ được thực hiện và nếu không phát hiện ra lỗi, IP Header sẽ bị tước bỏ và phần còn lại (bây giờ gọi là 1 Segment) sẽ được đưa lên lớp thứ 4 của mô hình OSI.

Giao thức TCP sẽ chấp nhận Segment và thực hiện kiểm tra lỗi trên Segment này. Giả sử không tìm thấy lỗi, thì TCP Header sẽ được gỡ bỏ và sẽ được đưa lên các lớp trên để đến với các ứng dụng đang chờ nó.

Tổng kết

Cuối cùng thì loạt bài về phân tích giao thức TCP đã xong. Sau khi đọc tất cả những bài này, tôi chắc chắn bạn sẽ có 1 sự hiểu biết tốt hơn về mục đích của giao thức TCP và quá trình diễn ra nó, và bạn có thể thực sự đánh gia cao chức năng của giao thức này.

Lược dịch từ bài gốc: Click Here

Analysing TCP Header Options

Giới thiệu

TCP Options (MSS, Window Scaling, Selective Acknowledgements, Time Stamps, Nop) có vị trí nằm ở cuối TCP Header.

Truyền thông dữ liệu càng ngày càng trở nên phức tạp hơn, ít chấp nhận sai sót và độ trễ, rõ ràng là các tính năng mới này đã được tích hợp cho TCP transport để giúp khắc phục nhiều vấn đề.

Ví dụ, Window Scaling, đã được đề cập đến ở bài trước và được giới thiệu ở đây, có thể sử dụng trường TCP Options bởi vì trường Window nguyên thủy của nó chỉ dài có 16 bits, cho phép một số thập phân tối đa là 65.535. Rõ ràng đây là con số quá nhỏ so với việc chúng ta muốn biểu thị giá trị 'Window Size' sử dụng những con số trong phạm vi kích thước hàng ngàn đến 1 triệu như 400.000 hay 950.000.

Trước khi đi phân tích chi tiết, chúng ta hãy xem qua trường TCP Options ở dưới hình sau:

Nằm ở cuối Header và ngay trước phần dữ liệu, nó cho phép chúng ta sử dụng những cải tiến mới được khuyến nghị bởi các kỹ sư đã giúp thiết kế nên các giao thức mà chúng ta đang sử dụng trong truyền thông dữ liệu ngày nay.