ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
PHẠM THANH TÙNG
THỬ NGHIỆM CÁC GIẢI PHÁP ĐẢM BẢO CHẤT
LƯỢNG DỊCH VỤ TRÊN CÁC THIẾT BỊ ĐỊNH TUYẾN
SỬ DỤNG HỆ ĐIỀU HÀNH NGUỒN MỞ VYOS
LUẬN VĂN THẠC SĨ CHUYÊN NGÀNH AN TOÀN THÔNG TIN
HÀ NỘI – 05/2019
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
PHẠM THANH TÙNG
THỬ NGHIỆM CÁC GIẢI PHÁP ĐẢM BẢO CHẤT
LƯỢNG DỊCH VỤ TRÊN CÁC THIẾT BỊ ĐỊNH TUYẾN
SỬ DỤNG HỆ ĐIỀU HÀNH NGUỒN MỞ VYOS
Ngành: Công nghệ thông tin
Chuyên ngành: An toàn thông tin
Mã số: 8480202.01
LUẬN VĂN THẠC SĨ CHUYÊN NGÀNH AN TOÀN THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. NGUYỄN ĐẠI THỌ
MỤC LỤC
DANH MỤC CÁC TỪ VIẾT TẮT ........................................................................ 5
DANH MỤC CÁC HÌNH VẼ................................................................................. 6
DANH MỤC CÁC BẢNG ...................................................................................... 8
MỞ ĐẦU .................................................................................................................. 9
CHƯƠNG 1. TỔNG QUAN VỀ QOS VÀ 1 SỐ CƠ CHẾ QOS CƠ BẢN ...... 11
1.1. Tổng quan về QoS [1,4] ................................................................................ 11
1.2. Các tham số hiệu suất QoS [1,4] ................................................................... 12
1.3. Các cơ chế QoS cơ bản ................................................................................. 13
1.3.1. Cơ chế bỏ đuôi - DropTail ....................................................................... 13
1.3.2. Cơ chế loại bỏ ngẫu nhiên –‘ RED [5]..................................................... 13
1.3.3. Cơ chế Adaptive-RED (A-RED) [6] ........................................................ 20
1.4. Kết chương .................................................................................................... 24
CHƯƠNG 2. CÁC CƠ CHẾ QOS VÀ CẤU TRÚC TRONG VYOS .............. 25
2.1. Giới thiệu chung về thiết bị định tuyến hệ điều hành nguồn mở VyOS ....... 25
2.2. Cấu trúc file hệ thống trong VyOS ............................................................... 25
2.2.1. Thư mục /opt/vyatta/bin ........................................................................... 26
2.2.2. Thư mục /opt/vyatta/sbin ......................................................................... 27
2.2.3. Thư mục /opt/vyatta/share........................................................................ 28
2.3. Các kiểu QoS trong VyOS [8,9] ................................................................... 29
2.4. Kiến trúc QoS trong VyOS ........................................................................... 31
2.5. Xác định mã nguồn giải thuật QoS trong kernel VyOS................................ 37
2.6. Kết chương .................................................................................................... 41
CHƯƠNG 3. THỰC HIỆN THỬ NGHIỆM VÀ KẾT QUẢ ............................ 42
3.1. Tổng quan về chương trình giả lập EVE-NG [13]........................................ 42
3.2. Xây dựng sơ đồ mạng mô phỏng hệ thống ................................................... 43
3.4. Thực hiện thử nghiệm ................................................................................... 45
3.4.1. Cấu hình ................................................................................................... 45
3.4.2. Kết quả kiểm thử ...................................................................................... 46
Internet of things
FIFO
First In First Out
WDA
Web farm DDoS Attack attenuator
ISP
Internet Service Provider
EVE-NG
Emulated Virtual Environment – Next
Generation
TC
Traffic Control
ECN
Explicit Congestion Notification
5
6
Hình 23: Thông tin phiên bản kernel VyOS 1.2 ............................................. 38
Hình 24: Thao tác thêm vào và lấy một đối tượng ra khỏi hàng đợi RED ..... 38
Hình 25: Mô tả giải thuật RED trong mã nguồn kernel .................................. 39
Hình 26: Mô tả giải thuật Adaptive RED (A-RED) trong mã nguồn kernel .. 39
Hình 27: Hệ thống mạng mô phỏng ................................................................ 44
Hình 28: Công thức tính các tham số của RED .............................................. 45
Hình 29: Cấu hình traffic policy với queue type là drop-tail .......................... 46
Hình 30: Lưu lượng gói tin đo ở đầu ra eth1 VyOS với trường hợp là
DropTail .......................................................................................................... 46
Hình 31: Lưu lượng gói tin đo ở đầu ra eth1 VyOS với trường hợp là RED-1
......................................................................................................................... 47
Hình 32: Lưu lượng gói tin đo ở đầu ra eth1 VyOS với trường hợp là RED-2
......................................................................................................................... 47
Hình 33: Lưu lượng gói tin đo ở đầu ra eth1 VyOS với trường hợp là A-RED
......................................................................................................................... 48
Hình 34: Lưu lượng gói tin đo ở đầu ra eth1 VyOS trong 4 trường hợp từ
nguồn đến là thiết bị R2 .................................................................................. 48
Hình 35: Kết quả lượng gói tin bị loại bỏ cụ thể từng trường hợp ................. 49
Hình 36: Kết quả so sánh tổng hợp lượng gói tin bị loại bỏ của 4 trường hợp
......................................................................................................................... 50
7
DANH MỤC CÁC BẢNG
Bảng 1: So sánh chương trình giả lập EVE-NG với GNS3 ............................. 43
Bảng 2: Các tham số cài đặt thử nghiệm .......................................................... 44
này trên thiết bị thật hoặc là sát với thực tế thông qua giả lập. Trước đây tại
trường Đại học Công Nghệ - Đại Học Quốc Gia Hà Nội, đã có một số đồ án,
luận văn xoay quanh vấn đề chống tấn công DdoS bằng cách thực hiện cài đặt
giải thuật WDA (Web farm DDoS Attack attenuator, được giới thiệu bởi Ehud
Doron và Avisha Wool, là một kiến trúc được xây dựng nhằm bảo vệ các
Web server. Theo đó, các Web server sẽ được kết nối với Internet thông qua
Router ISP. Để nâng cao khả năng chống đỡ của hệ thống trước các cuộc tấn
công, WDA sẽ được thêm vào như một phần trong cơ chế quản lý của thiết bị
định tuyến của ISP) cụ thể có luận văn của Nguyễn Xuân Hưởng [2] đã thực
9
hiện cài đặt một phần cơ bản của giải thuật WDA lên thiết bị thật là router của
Cisco, luận văn của Nguyễn Anh Tú [3] thử nghiệm mức độ có thể cài đặt giải
thuật WDA lên thiết bị định tuyến của Cisco, qua kết quả cài đặt và kiểm thử để
đi tới việc đề xuất cài đặt giải thuật WDA lên một thiết bị định tuyến mã nguồn
mở VyOS.
Tuy nhiên sau khi đọc báo cáo luận văn của Tú, tôi thấy việc cài đặt lên
thiết bị định tuyến mã nguồn mở VyOS vẫn đang còn bỏ ngỏ khi Tú mới chỉ
đang ở mức nghiên cứu được cấu trúc thư mục chứa các lệnh của VyOS chứ
chưa thử nghiệm cài đặt, cấu hình trên VyOS. Do đó, ở luận văn này, tôi muốn
tiếp tục nghiên cứu trên thiết bị định tuyến hệ điều hành nguồn mở VyOS mà
không phải trên giả lập simulator bởi vì hướng triển khai trên các thiết bị định
tuyến của các hãng lớn như Cisco không cho phép ta xâm nhập vào bên trong
mã nguồn để thay đổi cấu trúc cũng như thêm các tính năng. Mặt khác do vấn đề
về chi phí, nên luận văn này được làm trên một môi trường emulator EVE-NG,
sử dụng hoàn toàn các firmware của thiết bị định tuyến thật do nhà cung cấp
phát hành, nên vẫn đảm bảo không có sự sai khác khi so sánh với việc làm trên
thiết bị thật. Mục tiêu lâu dài của luận văn là có thể can thiệp vào các giải thuật
quản lý hàng đợi trong nhân hệ điều hành để có thể chống tấn công trong các
tòa nhà thông minh hoặc thành phố thông minh. Phần lớn dữ liệu được thu thập
và phân tích, như nhiệt độ, độ ẩm và nhận thức vị trí, rất nhạy cảm với thời gian.
Do độ nhạy thời gian này, dữ liệu này cần được xác định chính xác, đánh dấu và
xếp hàng phù hợp.
Tại sao QoS quan trọng?
Một số ứng dụng chạy trên mạng rất nhạy cảm với độ trễ. Các ứng dụng
này thường sử dụng giao thức UDP trái ngược với giao thức TCP. Sự khác biệt
chính giữa TCP và UDP là khi sử dụng TCP nếu bất kỳ gói tin nào bị mất,
không đúng định dạng hoặc bị lỗi, giao thức TCP có thể truyền lại và sắp xếp lại
các gói để tạo lại tệp trên PC đích.
Nhưng đối với các ứng dụng UDP như cuộc gọi điện thoại IP, bất kỳ gói bị
mất nào cũng không thể được truyền lại vì các gói thoại đi vào dưới dạng luồng
được đặt hàng; truyền lại các gói là vô ích. Do đó bất kỳ gói bị mất hoặc bị trì
hoãn cho các ứng dụng chạy giao thức UDP là một vấn đề thực sự. Trong ví dụ
về cuộc gọi thoại, việc mất thậm chí một vài gói sẽ dẫn đến chất lượng giọng nói
trở nên khó hiểu và không thể hiểu được.
Nếu mạng của bạn có nhiều băng thông và không có lưu lượng truy cập
vượt quá những gì nó có thể xử lý, bạn sẽ không gặp vấn đề với mất gói, trễ
hoặc biến thiên độ trễ - jitter. Nhưng trong nhiều mạng doanh nghiệp, sẽ có lúc
các liên kết bị tắc nghẽn quá mức đến mức các bộ định tuyến và bộ chuyển
11
mạch bắt đầu loại bỏ các gói vì các gói vào/ra nhanh hơn những gì các bộ định
tuyến có thể được xử lý. Đây là nơi QoS xuất hiện.
Thông thường, mạng thường phải truyền tải nhiều loại gói tin với các yêu
cầu về hiệu năng là khác nhau. Có thể loại gói tin đó là rất quan trọng trong dịch
vụ này nhưng lại không quá quan trọng trong dịch vụ khác. Vì thế một cơ chế
đảm bảo chất lượng dịch vụ được triển khai trong một mạng phải xem xét đến sự
12
1.3. Các cơ chế QoS cơ bản
1.3.1. Cơ chế bỏ đuôi -DropTail
Drop Tail là cách thức quản lý hàng đợi đơn giản, truyền thống dựa vào cơ
chế FIFO và chỉ đặt độ dài tối đa cho mỗi hàng đợi tại bộ định tuyến. Theo cơ
chế này, tất cả các gói tin đến được xếp vào hàng đợi; khi hàng đợi đầy thì các
gói tin đến sau đều bị loại bỏ; để chọn các gói tin truyền đi thì gói tin nào đến
trước được phục vụ trước. Trong Drop Tail, lưu lượng không được phân biệt,
mỗi gói đều có cùng mức độ ưu tiên. Drop Tail sẽ tiếp tục loại bỏ / thả gói tin
cho đến khi hàng đợi có đủ chỗ cho các gói mới.
Do đặc tính đơn giản, dễ triển khai mà DropTail đã được sử dụng nhiều
năm trên thiết bị định tuyến ở Internet, tuy nhiên giải thuật này có những nhược
điểm như sau:
− Hiện tượng đầy Queue: các gói tin đến thiết bị định tuyến thường theo
từng cụm chứ không phải lần lượt. Vì thế cơ chế hoạt động của
DropTail khiến cho hàng đợi có thể dễ dàng bị đầy trong 1 khoảng
thời gian dài, dẫn đến thời gian trễ trung bình của các gói tin lớn. Để
tránh hiện tượng này thì với DropTail chỉ có cách là tăng bộ đệm của
thiết bị định tuyến, cách này tỏ ra hết sức tốn kém và không hiệu quả.
− Không đảm bảo QoS: Với cơ chế DropTail thì không có cách nào để
ưu tiên những gói tin quan trọng được truyền qua thiết bị định tuyến
sớm hơn khi tất cả đang ở trong hàng đợi.
1.3.2. Cơ chế loại bỏ ngẫu nhiên – RED [5]
1.3.2.1. Tổng quan
RED (Random Early Detection of congestion; Random Early Drop) là một
một cái nhìn thống nhất về các nguồn khác nhau góp phần vào sự tắc
nghẽn này đồng thời cũng là nơi thích hợp để quyết định những nguồn
nào cần thông báo về sự tắc nghẽn này.
− Việc thứ hai là thông báo tắc nghẽn tới nguồn phát. Việc này được
thực hiện bằng cách đánh dấu và thông báo cho nguồn phát giảm lưu
lượng xuống. Nếu tắc nghẽn được phát hiện trước khi bộ đệm gateway
đầy, thì gateway đó không cần thiết phải loại bỏ các gói và thông báo
tới các nguồn phát. Việc đánh dấu và thông báo này có thể bao gồm
việc loại bỏ một gói, đánh dấu bằng cách đặt bit trong header gói tin
hoặc một số phương thức khác được hiểu bởi các giao thức tầng giao
vận.
− Việc thứ ba mà các RED gateway cần đạt được là tránh hiện tượng
đồng bộ toàn cục và không chống lại các dòng lưu lượng có đặc tính
đột biến. Với Drop Tail gateway và Random Drop gateway có sự sai
lệch chống lại lưu lượng truy cập đột biến. Khi lưu lượng truy cập từ
một kết nối cụ thể càng tăng thì càng có nhiều khả năng hàng đợi
14
gateway sẽ bị tràn. Còn hiện tượng đồng bộ toàn cục xảy ra khi tất cả
các kết nối đồng loạt giảm kích thước cửa sổ, dẫn tới mất thông lượng
trong mạng ở cùng một thời điểm. Để tránh hai hiện tượng này, các
gateway có thể dùng các thuật toán riêng biệt để phát hiện tắc nghẽn
và quyết định kết nối nào sẽ được thông báo tắc nghẽn tại gateway.
RED gateway chọn ngẫu nhiên các gói tin đến để đánh dấu; với
phương pháp này xác suất đánh dấu một gói tin từ một kết nối cụ thể
gần như tỉ lệ thuận với phần băng thông được chia sẻ của kết nối đó
tại gateway. Phương pháp này có thể được thực hiện một cách hiệu
nổ cho phép trong hàng đợi tại gateway.
− Giải thuật tính xác suất đánh dấu gói tin xác định mức độ thường
xuyên của việc đánh dấu gói tin của gateway với mức độ tắc nghẽn
hiện tại. Mục tiêu của việc đánh dấu gói tin của gateway phải đảm bảo
sao cho các gói tin được đánh dấu tại những khoảng thời gian đều
nhau, để tránh hiện tượng sai lệch, đồng bộ toàn cầu và đánh dấu các
gói thường xuyên đủ để kiểm soát kích thước hàng đợi trung bình.
Giải thuật chi tiết của RED tại gateway được mô tả như hình 2
dưới đây.
16
Hình 2: Giải thuật chi tiết RED
Các biến thay đổi:
avg: kích thước hàng đợi trung bình
q_time: điểm bắt đầu hàng đợi rỗng
count: số lượng các gói đến ngay sau gói cuối cùng bị đánh dấu
Các tham số cố định:
wq: trọng số hàng đợi
minth: chiều dài ngưỡng nhỏ nhất của hàng đợi
maxth: chiều dài ngưỡng lớn nhất của hàng đợi
maxp: xác suất loại bỏ tối đa
Các tham số khác:
17
có trọng số tăng theo cấp số nhân
avg (1 – wq) * avg + wq * q
18
Trọng số hàng đợi wq xác định hằng số thời gian của bộ lọc thông thấp.
Tiếp theo là phần lập luận cho việc thiết lập các cận trên hoặc dưới cho tham số
wq.
Cận trên cho wq:
Nếu wq quá lớn, khi đó quy trình lấy trung bình sẽ không lọc được tắc
nghẽn thoáng qua tại cổng.. Giả sử ban đầu hàng đợi rỗng (kích thước trung bình
bằng 0), sau khi có các gói, số gói tin trong hàng đợi sẽ tăng từ 0 đến L (có L gói
tin trong hàng đợi). Sau khi gói tin thứ L đến gateway, kích thước hàng đợi trung
bình avgL được tính như sau :
𝐿
𝐿
avgL = ∑
𝑖=1
𝑖wq (1 − wq )
Áp dụng công thức
𝐿
∑𝑖=1 𝑖𝑥 𝑖
𝐿+1
wq
Cận dưới cho wq:
Cổng RED được thiết kế để giữ kích thước hàng đợi trung bình được tính
dưới một ngưỡng nhất định. Tuy nhiên sẽ không đạt được mục đích nếu như avg
không phản ánh hợp lý kích thước hàng đợi trung bình hiện tại. Nếu wq được
thiết lập quá thấp, thì giá trị avg sẽ phản ứng rất chậm với sự thay đổi kích thước
hàng đợi trong thực tế. Trong trƣờng hợp này, RED gateway không phát hiện
thấy sự bắt đầu của tắc nghẽn. Khi đưa ra giá trị ngưỡng dưới minth, tức là đã
cho phép hấp thu bùng nổ đến L gói tin. Sau đó trọng số wq phải được chọn thoả
mãn bất phương trình avgL < minth:
𝐿+1+
(1−wq )
𝐿+1
wq
−1
< minth
Theo các kết quả tính toán của các nghiên cứu về RED, giá trị cho wq
thường sử dụng là 0.002.
b. Các giá trị ngưỡng minth và maxth
Giá trị tối ưu cho minth và maxth phụ thuộc vào kích thước hàng đợi trung
bình mong muốn. Nếu lưu lượng truy cập bùng nổ, thì minth phải lớn tương ứng
để cho phép việc sử dụng liên kết được duy trì ở mức cao chấp nhận được. Giá
hiện tại.
Điểm yếu thứ hai của RED là thông lượng cũng nhạy cảm với lưu lượng tải
và các tham số RED. Cụ thể, RED thường không hoạt động tốt khi hàng đợi
trung bình trở nên lớn hơn maxth và dẫn đến thông lượng giảm đáng kể và tỉ lệ
20
loại bỏ gói tin tăng. Để tránh nhược điểm này cũng cần đến sự điều chỉnh liên
tục các tham số RED.
Mục đích của tác giả là tìm kiếm một thay đổi tối thiểu hơn cho RED có
thể làm giảm bớt các vấn đề về thay đổi độ trễ và độ nhạy tham số được đề cập ở
trên, đó cũng là nguyên tắc cốt lõi của giải thuật A-RED cải tiến từ giải thuật
RED gốc.
1.3.3.2. Giải thuật A-RED
Các mục tiêu của A-RED khác với RED ban đầu theo bốn cách:
maxp được thay đổi không chỉ để giữ cho kích thước hàng đợi trung
bình nằm trong khoảng minth và maxth mà còn giữ cho kích thước hàng
đợi trung bình nằm trong khoảng một nửa giữa minth và maxth.
maxp được thay đổi chậm, với khoảng thời gian lớn hơn thời gian khứ
hồi (round-trip time) và trong các bước nhỏ.
maxp phải được khống chế để duy trì trong miền [0.01, 0.5] (tương ứng
với [1%, 50%]).
Thay vì phải nhân lên nhiều lần khi tăng và giảm maxp, thuật toán sử
dụng chính sách tăng theo cấp số cộng giảm theo cấp số nhân (additiveincrease multiplicativedecrease - AIMD).
Nguyên tắc chính của A-RED là thay đổi các giá trị maxp không thường
22
b) Tham số α, β
Khi đề xuất các giá trị cho α và β, yêu cầu đặt ra là trong điều kiện bình
thường, nếu maxp có thay đổi 1 lần cũng không dẫn đến sự thay đổi của kích
thước hàng đợi trung bình hoặc ngược lại. Khi maxp được điều chỉnh, xác suất
loại bỏ gói ở trạng thái ổn định p vẫn giữ nguyên và kích thước hàng đợi trung
bình avg chỉ đơn giản là thay đổi để phù hợp với giá trị mới của maxp. Do đó p
< 0.2 hay β >0.83 . Giá trị mặc định
cho β là 0.9.
c) Thiết lập các tham số maxth và wq
Như đã mô tả ở trên, A-RED loại bỏ sự phụ thuộc của RED vào tham số
maxp. Để giảm nhu cầu điều chỉnh tham số khác cho RED, ta có thể tự động đặt
tối đa các tham số RED là maxth và wq. Giá trị maxth được khuyến nghị nên gấp
ba lần minth. .Trong trường hợp này, kích thước hàng đợi trung bình sẽ được tập
trung vào khoảng 2minth và do đó chỉ được xác định bởi tham số minth của RED.
23