Giáo trình hướng dẫn phân tích những lỗi và cách khác phục trong mạng ảo phần 4 pps

504

•
S= a.b.c.d là
đ
ị
a
chỉ nguồn.
•
Đ
ị
a
chỉ nguồn a.b.c.d
đư
ợ
c
dịch sang w.x.y.z.
•
D=e.f.g.h là
đ
ị
a
chỉ
đ
ích.

•
Giá trị trong giấu ngoặc vuông là chỉ số danh
đ
inh
IP. Thông tin này có thể

sẽ hữu dụng vì dựa vào
đ
ó
chúng ta sẽ tìm
đư
ợ
c
những gói dữ liệu tương
ứ
ng
đư
ợ
c
phân tích từ những phần mền phân tích giao thức khác.
1.1.7. Những vấn đề của NAT

NAT có nh
ững
ư
u
đ
i
ể
m
sau:
•
Tiết kiệm
đ
ị
a

chỉ
đă
ng
ký hợp pháp bằng cách cho phép sử dụng
đ
ị
a
chỉ
riêng.
•
Tăng tính linh hoạt của các kết nối ra mạng công cộng. Chúng ta có thể triển
khai nhiều dải
đ
ị
a
chỉ chia tải
đ
ể

đ
ả
m
bảo
đ
ộ

tin cậy của kết nối mạng công
cộng.
•
Nhất quán hồ sơ

đ
ị
a
chỉ mạng nội bộ. Nếu mạng không sử dụng
đ
ị
a
chỉ IP
riêng và NAT mà sử dụng
đ
ị
a
chỉ công cộng thì khi thay
đ
ổ
i
đ
ị
a
chỉ công
cộng, toàn bộ hệ thống mạng phải
đ
ặ
t
lại
đ
ị
a
chỉ. Chi phí cho việc
đ

ặ
t
lại
đ
ị
a

chỉ toàn bộ các thiết bịi mạng nội bộ
đư
ợ
c
giữ nguyên khi thay
đ
ổ
i
đ
ị
a
chỉ
công cộng.
NAT c
ũng không phải là không có nhược
đ
i
ể
m.
Khi chuyển
đ
ổ
i

đ
ị
a
chỉ như vậy sẽ
làm mất
đ
i
một số chức năng
đ
ặ
c
biệt của giao thức và
ứ
ng
dụng có cần
đ
ế
n
các
thông tin
đ
ị
a
chỉ IP trong gói IP. Do
đ
ó
cần phải có thêm các hỗ trợ khác cho thiết
bị NAT.
NAT làm tăng th
ời gian trễ. Thời gian trễ chuyển mạch sẽ lớn hưon do

đ
ó
phải
chuyển
đ
ổ
i
từng
đ
ị
a
chỉ IP trong mỗi dữ liệu. Gói dữ liệu
đ
ầ
u
tiên luôn phải sử lý
chuyển mạch nên thời gian chuyển mạch nhanh hơnnếu có bộ
đ
ệ
m.

505

Hiệu suất hoạt
đ
ộ
ng
cũng là một vấn
đ
ề

cần
đư
ợ
c
quan tâm vì NAT
đư
ợ
c
thực hiện
trong tiến trình chuyển mạch. CPU phải
đư
ợ
c
kiểm tra từng gói dữ liệu
đ
ể

quyết
đ
ị
nh
gói dữ liệu
đ
ó
có cần chuyển
đ
ổ
i
đ

ị
a
chỉ hay không. CPU phải thay
đ
ổ
i
phần
gói IP của gói dữ liệu và cũng có htể phải thay cả phần
đ
óng
gói TCP hoặc UDP.
Một nhược
đ
i
ể
m
đ
áng
kể khi sử dụng NAT là sự mất
đ
i
khả nặng truy tìm
đ
ị
a
chỉ
IP
đ
ầ
u

cuối-đến-đầu cuối. Việc truy theo gói dữ liệu sẽ trở nên khó hơn do gói dữ
liệu thay
đ
ổ
i
đ
ị
a
chỉ nhiều lần qua nhiều trạm NAT. Hacker sẽ rất khó khăn khi
muốn xác
đ
ị
nh
đ
ị
a
chỉ nguồn hoặc
đ
ích
của gói dữ liệu.
NAT c
ũng làm cho một số
ứ
ng
dụng sử dụng
đ
ị
a
chỉ IP không hoạt
đ

ộ
ng
đư
ợ
c
vì
nó giấu
đ
ị
a
chỉ IP
đ
ầ
u
cuối-đến-đầu cuối. Những
ứ
ng
dụng sử dụng
đ
ị
a
chỉ vật lý
thay vì sử dụng tên miền sẽ không
đ
ế
n
đư
ợ
c
đ

ích
nằm sau router NAT.
Đ
ôi
khi, sự
cố này có thể tránh
đư
ợ
c
bằng cách ánh xạ NAT cố
đ
ị
nh.

Cisco IOS NAT hỗ trợ các loại lưu lượng sau:
•
ICMP
•
File Transfer Protocol (FTP), bao gồm lệnh PPRRT và PÁV.
•
Dịch vụ NetBIOS qua TCP/IP, gói dự liệu, tên và phiên giao tiếp.
•
RealNetworks’ RealAudio
•
White Pines’ CUSeeMe
•
Xing Technologies’ StreamWorks
•
DNS “A” and “PTR” queries
•

H.323/Microsoft NetMeeting, IOS versions 12.0(1)/ 12.0(1) T và sau
đ
ó.

•
VDOnet’s VDOLive, IOS version 11.3(4)11.3(4)T và sau
đ
ó.

•
VXtreme’s Web Theater, IOS versions 11.3(4)11.3(4)T và sau
đ
ó.

•
IP Multicast, IOS version 12.0(1)T chỉ chuyển
đ
ổ
i
đ
ị
a
chỉ nguồn.
Cisco IOS NAT không hỗ trợ các loại giao thức sau:
506

•
Thông tin cập nhật bảng
đ
ị

nh
tuyến.
•
Chuyển
đ
ổ
i
vùng DNS.
•
BOOTP
•
Giao thức talk and ntalk.
•
Giao thức quản lý mạng
đơ
n
giản – Simple Network Management Protocol
(SNMP)
1.2. DHCP

1.2.1. Giới thiệu DHCP

Giao thức cấu hình họat
đ
ộ
ng
(DHCP – Dynamic Host Configuration Protocol)
làm việc theo chế
đ
ộ

client-server. DHCP cho phép các DHCP client trong một
mạng IP nhận cấu hình IP của mình từ một DHCP server. Khi sử dụng DHCP thì
công việc quản lý mạng IP sẽ ít hơn vì phần lớn cấu hình IP của client
đ
ư
ợ
c
lấy về
từ server. Giao thức DHCP
đư
ợ
c
mô tả trong RFC 2131.
Một DHCP client có thể chạy hầu hết các hệ
đ
i
ề
u
hành Windows, Netvell Netửae,
Sun Solaris, Linux và MAC OS. Client yêu cầu server DHCP cấp một
đ
ị
a
chỉ cho
nó. Server này quản lý việc cấp phát
đ
ị
a
chỉ IP, sẽ gửi trả lời cấu hình IP cho client.

Một DHCP có thể phục vụ cho nhiều subnet khác nhau nhưng không phục vụ cho
cấu hình router, switch và các server khác vì những thiết bị này cần phải có
đ
ị
a
chỉ
IP cố
đ
ị
nh.

507

Hình 1.2.1.a.
Client gửi trực tiếp quảng bá một yêu cầu DHCP. Trường hợp
đơ
n

gi
ản nhất là có DHCP server nằm trong cùng subnet với client, server DHCP này
sẽ nhận
đư
ợ
c
gói yêu cầu. Server thấy phần GIADDR bỏ trống thì biết client nằm
trong cùng subnet với server.
Đ
ồ
ng
thời server sẽ

đ
ọ
c
đ
ị
a
chỉ vật lý (địa chỉ MAC)
của client.
Hình 1.2.1.b.
Server sẽ lấy một
đ
ị
a
chỉ IP trong dải
đ
ị
a
chỉ tương
ứ
ng
đ
ể

cấp cho
client. Sau
đ
ó
server dùng
đ
ị

a
chỉ của vật lý của client
đ
ể

gửi gói trả lời lại cho
client.
508

Hình 1.2.1.c.
Hệ
đ
i
ề
u
hành trên DHCP client sẽ dùng những thông tin nhận
đư
ợ
c

trong gói trả lời server
đ
ể

cấu hình IP cho client
đ
ó.

Server chạy DHCP thực hiện tiến trình xác
đ

ị
nh
đ
ị
a
chỉ IP cấp cho client. Client sử
dụng
đ
ị
a
chỉ
đư
ợ
c
cấp từ server trong một khoảng thời gian nhất
đ
ị
nh
do người
quản trị mạng quy
đ
ị
nh.
Khi thời này hết hạn thì client phải yêu cầu cấp lại
đ
ị
a
chỉ
mới mặc dù thông thường client sẽ vẫn
đư

ợ
c
cấp lại
đ
ị
a
chỉ cũ.
Các nhà quản trị mạng thường sử dụng dịch vụ DHCP vì giải pháp này giúp quản
lý hệ thống mạng dễ và có khả năng mở rộng. Cisco router có thể sử dụng Cisco
IOS có hỗ trợ Easy IP
đ
ể

làm DHCP server. Mặc
đ
ị
nh
, Easy IP cấp cấu hình IP
cho client sử dụng trong 24 tiếng. Cơ chế này rất tiện lợi cho các văn phòng nhỏ
hoặc những văn phòng tại nhà, người sử dụgn tại nhà có thể tận dụng diạhc vụ
DHCP và NAT của router mà không cần phải có thêm một server NT hoặc UNIX.
Ngư
ời quản trị mạng cài
đ
ặ
t
dải
đ
ị
a

chỉ cho DHCP server còn có thể cung cấp
nhiều thông tin khác như
đ
ị
a
chỉ DNS server,
đ
ị
a
chỉ WINS server và tên miền.
Hầu hết các DHCP server
đ
ề
u
cho phép người quản trị mạng khai báo những
đ
ị
a

chỉ MAC nào cần phục vụ và tự
đ
ộ
ng
cấp cho những
đ
ị
a
chỉ MAC này
đ
ị

a
chỉ IP
không thay
đ
ổ
i
mỗi lần chúng yêu cầu.
DHCP sử dụng giao thức UDP (User Datagram Protocol) làm giao thức vận
chuyển của nó. Client gửi thông
đ
i
ệ
p
cho server trên port 67. Server gửi thông
đ
i
ệ
p

cho client trên port 68.
509

1.2.2. Những điểm khác nhau giữa BOOTP và DHCP
Đ
ầ
u
tiên cộng
đ
ồ
ng

Internet phát triển giao thức BOOTP
đ
ể

cấu hình cho máy trạm
không có
ổ

đ
ĩ
a.
BOOTP
đư
ợ
c
đ
ị
nh
nghĩa trong RFC 951 vào năm 1985. Là một
phiên bản
đ
i
trước của DHCP nên BOOTP cũng có nhiều
đ
ặ
c
đ
i
ể
m

họat
đ
ộ
ng

tương tự như DHCP. Cả hai giao thức này
đ
êgu
dựa trên cơ sở client-server và sử
dụng port UDP 67, 68. Hai port này hiện vẫn
đư
ợ
c
biết
đ
ế
n
như là port BOOTP.
Một cấu hình IP cơ bản bao gồm 4 thông tin sau:
•
Đ
ị
a
chỉ IP.
•
Đ
ị
a
chỉ Gateway.
•

Subnet mask.
•
Đ
ị
a
chỉ DNS server.
BOOTP không tự
đ
ộ
ng
cấp phát
đ
ị
a
chỉ IP cho một host. Khi client yêu cầu một
đ
ị
a
chỉ IP, BOOTP server tìm trong bảng
đ
ã
đư
ợ
c
cấu hình trước xem có hàng nào
tương
ứ
ng
với
đ

ị
a
chỉ MAC của client hay không.Nếu có thì
đ
ị
a
chỉ IP tương
ứ
ng

sẽ
đư
ợ
c
cung cấp cho client.
Đ
i
ề
u
này có nghĩa là
đ
ị
a
chỉ MAC và
đ
ị
a
chỉ IP tương
ứ
ng

phải
đư
ợ
c
cấu hình trước trên BOOTP server.
Sau
đ
ây
là hai
đ
i
ể
m
khác nhau cơ bản giữa BOOTP và DHCP:
•
DHCP cấp một
đ
ị
a
chỉ IP cho một client trong một khoảng thời gian nhất
đ
ị
nh.
Hết khoảng thời gian này
đ
ị
a
chỉ IP có thể
đư
ợ

c
cấp cho client khác.
Client có thể lấy
đ
ị
a
chỉ mới hoặc vẫn có thể tiếp tục giữ
đ
ị
a
chỉ cũ.
•
DHCP cung cấp cho client nhiều thông tin cấu hình IP khác như
đ
ị
a
chỉ
WINS server, tên miền.
510

BOOTP

DHCP

Ánh xạ cố
đ
ị
nh
giữ
đ

ị
a
chỉ MAC và Ánh xạ tự
đ
ộ
ng
giữa
đ
ị
a
chỉ MAC và
đ
ị
a
chỉ IP dải
đ
ị
a
chỉ IP tương
ứ
ng.

Cấp cố
đ
ị
nh
Cấp trong một khoảng thời gian nhất
định

Chỉ cung cấp 4 thông tin cơ bản của Có thể cung cấp hơn 30 thông tin cấu

cấu hình IP hình IP
1.2.3. Những đỉểm chính của DHCP

Có 3 cơ chế dùng
đ
ể

cấp phaqst một
đ
ị
a
chỉ IP cho client:
•
Cấp phát tự
đ
ộ
ng
– DHCP tự
đ
ộ
ng
chọn một
đ
ị
a
chỉ IP trong dải
đ
ị
ach
ỉ

đư
ợ
c

cấu hình và cấp
đ
ị
a
chỉ IP
đ
ó
cố
đ
ị
nh,
không thay
đ
ổ
i
cho một client.
•
Cấp phát cố
đ
ị
nh
–
Đ
ị
a

chỉ IP của một client do người quản trị mạng quyết
đ
ị
nh.
DHCP chỉ truyền
đ
ị
a
chỉ này cho client
đ
ó.

•
Cấp phát
đ
ộ
ng
– DHCP cấp và thu hồi lại một
đ
ị
a
chỉ IP của client theo một
khoảng thời gian giới hạn.
Trong phần này chúng ta tập trung vào cơ chế cấp phát
đ
ộ
ng.
Một số thông số cấu
hình
đư

ợ
c
liệt kê trong IÈT RFC 1533 là:
•
Subnet mask
•
Router
•
Tên miền
•
Server DNS
•
WINS server
Chúng ta có thể tạo trên DHCP server nhiều dải
đ
ị
a
chỉ IP và thông số như trên
tương
ứ
ng.
Mỗi một dải
đ
ị
a
chỉ dành riêng cho một subnet IP.
Đ
i
ề
u

này cho phép
511

có thể có nhiều DHCP cùng trả lời và IP client có thể di
đ
ộ
ng.
Nếu có nhiều server
cùng trả lời thì client có thể chọn một trả lời duy nhất.
Hình 1.2.3
1.2.4. Họat động của DHCP
Quá trình DHCP client lấy cấu hình DHCP diễn ra theo các bước sau:
1. Client phải có cấu hình DHCP khi bắt
đ
ầ
u
tiến trình tìm các thành viên trong
mạng. Client gửi một yêu cầu cho server
đ
ể

yêu cầu cấu hình IP.
Đ
ôi
khi
client có thể
đ
ề

nghị trước

đ
ị
a
chỉ IP mà nó muốn, ví dụ như khi nó hết thời
gian sử dụng
đ
ị
a
chỉ IP hiện tại và muốn gia hạn thêm thời gian. Client sẽ
xác
đ
ị
nh
đư
ợ
c
DHCP server bằng cách gửi gói quảng bá gọi là
DHCPDISCOVER.
2. Khi server nhận
đư
ợ
c
gói quảng bá, nó sẽ tìm trong cơ sở dữ liệu của nó và
quyết
đ
ị
nh
là có trả lời
đư
ợ

c
yêu cầu này không. Nếu server không trả lời
yêu cầu thì nó sẽ gửi gói trả lời trực tiếp bằng DHCPOFFER về cho client,
trong
đ
ó
mời client sử dụng cấu hình IP của server. Trong DHCPOFER có
512

thể có các thôngtin cho client về
đ
ị
a
chỉ IP,
đ
ị
a
chỉ DNS server và thời gian
sử dụng
đ
ị
a
chỉ này.
3. Nếu client nhận thấy lời mời của server phù hợp thì nó sẽ gửi quảng bá một
DHCPREQUEST
đ
ể

yêu cầu cung cấp những thông cố cụ thể của cấu hình
IP. Tại sao lúc này client lại gửi quảng bá mà nó không gửi trực tiếp cho

server? Do thông
đ
i
ệ
p
đ
ầ
u
tiên là DHCPDISCOVER
đ
ã
đư
ợ
c
gửi quảng bá
nên thông
đ
i
ệ
p
này có thể sẽ
đ
ế
n
đư
ợ
c
nhiều server DHCP khác nhau. Khi
đ
ó,

có thể sẽ có nhiều server cùng mời một client chấp nhận. Thông thường
lời mời mà client nhận
đư
ợ
c
đ
ầ
u
tiên sẽ
đư
ợ
c
chấp nhận.
4. Server nào nhận
đư
ợ
c
DHCPREQUEST cho biết client
đ
ã
chấp nhận sử
dụng cấu hình IP mà server
đ
ã
mời thì server
đ
ó
sẽ gửi trả lời trực tiếp cho
client một gói DHCPACK. Rất hiếm khi nhưng cũng có thể server sẽ không
gửi DHCPACK vì có thể cấu hình IP

đ
ó
đ
ã
đư
ợ
c
cấp cho client khác rồi.
5. Sau khi client nhận
đư
ợ
c
DHCPACK thì có thể bắt
đ
ầ
u
sử dụng
đ
ị
a
chỉ IP
ngay.
6. Nếu client phát hiện rằng
đ
ị
a
chỉ IP này
đ
ã
đư

ợ
c
sử dụng trong cùng mạng
nội bộ với nó thì client sẽ gửi thông
đ
i
ệ
p
DHCPDECLINE và bắt
đ
ầ
u
tiến
trình DHCP lại từ
đ
ầ
u.
Hoặc nếu client nhận
đư
ợ
c
thông
đ
i
ệ
p
DHCPNAK từ
server trả lời cho thông
đ
i

ệ
p
DHCPREQUEST thì sau
đ
so
client cũng bắt
đ
ầ
u
tiến trình lại từ
đ
ầ
u.

7. Nếu client không cần sủ dụng
đ
ị
a
chỉ IP này nữa thì client guiử thống
đ
i
ệ
p

DHCPRELEASE cho server.
513

Hình 1.2.4.a.
Tiến trình hoạt
đ

ộ
ng
DHCP
Tùy theo quy
đ
ị
nh
của mỗi tổ chức, công ty, người quản trị mạng có thể cấp cố
đ
ị
nh
cho một
đ
ị
a
chỉ IP nằm trong dải
đ
ị
a
chỉ của một DHCP server. Cisco IOS
DHCP server luôn luôn phải kiểm tra một
đ
ị
a
chỉ IP
đ
ã
đư
ợ
c

sử dụng trong mạng
hay chưa trước khi mời client sử dụng
đ
ị
a
chỉ IP
đ
ó.
Server sẽ phát một yêu cầu
ICMP echo, hay còn gọi là ping,
đ
ế
n
các
đ
ị
a
chỉ IP nằm trong dải
đ
ị
a
chỉ của mình
trước khi gửi DHCPOFFER cho client. Số lượng ping mặc
đ
ị
nh
đư
ợ
c
sủ dụng

đ
ể

kiểm tra một
đ
ị
a
chỉ IP là 2 gói và chúng ta có thể cấu hình con số này
đư
ợ
c
.

Hình 1.2.4.b.
Thứ tự các thông
đ
i
ệ
p
DHCP
đư
ợ
c
gửi
đ
i
trong tiến trình DHCP.