Hoạt động của Radius Server và WebAdmin trên WAN đơn giản - Chương 5&6 docx

58


Chương V:
XÂY DỰNG RADIUS PROXY

I. Giới thiệu:
Thông thường, khi Radius Server nhận một yêu cầu xác nhận quyền từ RAS, nó sẽ xử
lý và gửi trả kết quả trả lời trực tiếp về RAS đó. Tuy nhiên, mỗi Radius Server chỉ có
thể xác nhận quyền cho một số users hạn đònh. Nếu số lượng user của RAS tăng lên
nhiều, ta cần phải xây dựng một Radius Server mới. Để cho các Radius Server có thể
xác nhận quyền cho RAS, yêu cầu xây dựng Radius Proxy được đặt ra. Radius Proxy
sẽ nhận các yêu cầu từ RAS gửi đến, thiết lập yêu cầu mới, sau đó gởi đến Radius
Server tương ứng, chờ nhận kết quả trả lời từ Radius Server để gửi trả lại RAS.
59


Đề xuất phương pháp xây dựng Radius Proxy.

II. Phương pháp 1:

Client sẽ gởi Access-Request tới Radius Proxy. Radius Proxy vừa có trách nhiệm của một
Radius server, vừa có trách nhiệm của Radius Proxy. Nghóa là nó sẽ giải mã yêu cầu gởi
tới từ client để lấy ra được những thông tin đặc trưng cho yêu cầu đó, tra khảo những
thông tin này trong cơ sở dữ liệu nội bộ và xác nhận xem các thông tin này có hợp lệ hay
60

không (authenticating). Nếu sự xác nhận là thành công thì Access-Accept, chứa đựng các
thông tin về quyền và cách thức truy xuất cho phép vào các dòch vụ mạng (network
services) của user, sẽ được gởi trả về Client. Nếu sự xác nhận là thất bại tại bất cứ điều
kiện nào, Radius Proxy sẽ lưu lại những thông tin cần thiết của yêu cầu này, đồng thời xây

dựng một yêu cầu mới và gởi yêu cầu này tới Radius server được chỉ đònh để xác nhận và
chờ trả lời. Sau khi nhận được trả lời, Radius Proxy sẽ xây dựng một trả lời mới theo
những thông tin đã được lưu lại và gởi nó cho Client dưới dạng Access-Accept hay Access-
Reject.
Trong phương pháp này, ta dùng lại quá trình nhận yêu cầu từ Client của Radius Proxy
và quá trình gởi trả kết quả xác nhận về cho Client, chỉ bổ sung phần gởi yêu cầu /nhận
trả lời giữa Proxy và Server. đây ta dùng chế độ gởi và chờ (poolling) ở phần mã thêm
vào, nằm ở đầu quá trình gởi kết quả xác nhận về cho Client, do đó sẽ gây ra thời gian trễ.
Chương trình sẽ không ở chế độ thời gian thực (real-time), mặc dù đã dùng timer để tránh
lặp vô hạn.

61

Phần Radius Proxy được xây dựng như sau:
 Dùng lại:
+Nhận gói UDP từ Client: recvfrom (sockfd,recv_buffer,…)
+Phân tích gói UDP thành gói Radius và tạo ra cấu trúc Auth-Request:
aatv->recv(&authreq,…)
+Authenticate và gởi trả gói kết quả về Client:
rad_reply()
 Viết mới: chèn vào rad_reply()
if ((result == EV_ACK) /* result là kết quả của quá trình authentication*/
{ /* Làm bình thøng: trả về gói Access-Accept*/ }
…. Send_reply(authreq,…)
else if (result == EV_NAK)
{
/* Thay vì trả về gói Access-Reject ta sẽ làm như sau*/
/* Xây dựng cấu trúc SendData từ cấu trúc Auth-Request*/
if (construct_request ( authreq, data ) != 0)
{

/* Nếu xây dựng không được thì trả về gói Access-Reject*/
62

result = EV_NAK;
goto failed_label;
}
else
{
/* Gởi SendData tới Radius Server, chờ nhận gói trả về (pooling),
Khôi phục lại cấu trúc Auth-Request với những thông số được
Cập nhật*/
if (send_to_server ( data, sockfd, authreq, msg) == 0)
{
result == EV_ACK;
}
else
{
/* Nếu không gởi được hoặc không nhận được gói trả lời hoặc gói trả về
không hợp lệ thì trả về gói Access-Reject*/
result == EV_NAK;
goto failed_label;
}
63

}
goto passed_label;
}
failed_lable:
Send_reply(authreq,…)
Passed_label: /* Tiếp tục bình thường*/

Cách này dùng chế độ pooling nên sẽ không ưu việt khi user mong muốn làm việc ở chế
real-time (login trong một khoảng thời gian rất ngắn, nếu không được sẽ báo ngay –
message sẽ được truyền đi ngay khi tới Proxy và quay về ngay mà không cần chờ hồi đáp
từ server (NON_BLOCK)). Thực tế khi chạy chương trình, nếu chất lượng mạng kém hay
tình trạng tải cao, pooling sẽ làm cho process chiếm CPU trong toàn bộ khung thời gian
mà hệ điều hành dành cho nó mà không làm gì cả ngoài việc đợi gói trả về từ server. Nếu
số lượng yêu cầu từ proxy không được server trả lời là cao thì hệ thống sẽ chạy rất chậm
và hầu như bò timeout.

III. Phương pháp 2:
Radius Proxy được xây dựng tách biệt Radius Server. Nghóa là nó chỉ có trách nhiệm nhận
yêu cầu từ Client gởi tới, giải mã yêu cầu này để nhận biết các thông tin cần thiết như
Request ID, Client-ID, User-Name, Password, Shared Secret… ; Sau đó lưu lại các thông
tin của yêu cầu và xây dựng một yêu cầu mới (sinh ra Request-ID, Client-ID mới), gởi
yêu cầu mới này tới Radius Server. Radius Server sẽ xác nhận các thông tin của yêu cầu
64

và trả lời kết quả cho Radius Proxy mà tới phiên nó sẽ cập nhật lại một số thông tin của
yêu cầu ban đầu cho gói trả lời và gởi nó về cho Client tương ứng.
Trong phương pháp này không dùng lại mã nguồn của Radius Server mà xây dựng một
chương trình có khả năng giải mã một phần các gói và trung chuyển các gói này đến
Radius Server và Client chỉ đònh. Chương trình này không hoạt động ở chế độ gọi/chờ
(poolling) mà ở chế độ thời gian thực (Real Time). Đồng thời ta cũng dùng Timer cho các
yêu cầu từ Client tới để tránh cho Client phải chờ vô hạn. Mỗi yêu cầu từ Client tới sẽ
được Timer của Radius Proxy đánh dấu lại thời điểm này (Time-stamp). Nếu sau một
khoảng thời gian nhất đònh mà Proxy không nhận được gói trả lời tương ứng cho yêu cầu
này từ Radius Server thì Timer sẽ yêu cầu Proxy gởi Access-Reject thông báo cho Client
biết rằng yêu cầu xác nhận quyền (Authentication Request) đã quá thời gian hạn đònh
(timeout), đồng thời xóa thông tin gói yêu cầu trong bộ đệm của Proxy.

Ta có thể xây dựng giải thuật chương trình như sau:
/* đònh nghóa hai queue gởi/nhận tónh, toàn cục để các process đều có thể tham khảo hoặc
cập nhật*/
Static AUTH_REQ SendQueue[MAX_QUEUE];
Static AUTH_REQ RecvQueue[MAX_QUEUE];
65

Static TIMER Timer[MAX_TIMER];
Static PENDING_REQUESTS pendingReq[MAX_REQ];
Static int send_sockfd, recv_sockfd;
Static int numPending = 0;

Main()
{
/* taïo process TimerThread*/
if fork()
{
/* process TimerThread*/
Timerthread ();
}
/* Taïo process Receiver*/
if fork()
{
/* process Receiver*/
Receiver();
66

}
/* Tạo process Sender*/
if fork()
{
/* Process Sender*/
Sender();
}
if error exit(1);
/* Chờ các process con kết thức*/
wait on childred-processes
exit(0);
}

Receiver()
{
if fork() /* tạo receive-part*/
{
Tạo listener trên Radius-UDP-Port (&recv_sockfd);
67

While (1)
{
if (coự dửừ lieọu treõn recv_sockfd)
recvfrom(recv_sockfd, ANY_ADDR, buffer,);
authReq = makeAuthReq(TO_SERVER, buffer);
pendingReq[numPending++] = authReq->id;
if (semaphore-enable-to-write-in-SendQueue)
{
seton(sendqueueSemaphore);

writeQueue(authReq,SendQueue);
setoff(sendqueueSemaphore);
timerID = setTimer(authReq->id);

}
}
}
if fork() /* taùo send-part*/
{
68

while (1)
{
if (ReceiveQueue <> NULL)
{
if (semaphore-enable-to-write-in-ReceiveQueue)
{
seton(recvqueueSemaphore);
idQ = readQueue(&authReq,
ReceiveQueue);
freeQueue (idQ, ReceiveQueue);
setoff(recvqueueSemaphore);
sendto(recv_sockfd, authReq,
authReq->clientId …);
}

}
}
}
69

if error exit(-1);
wait on children-processes
}

Sender()
{
if fork() /* taùo receive-part*/
{
Taùo listener treõn Radius-UDP-Port (&send_sockfd);
While (1)
{
if (coự dửừ lieọu treõn send_sockfd)
recvfrom(send_sockfd, ANY_ADDR, buffer,);
authReq = makeAuthReq(TO_CLIENT, buffer);
if authReq->id NOT IN pendingReq[]
continue;
if (semaphore-enable-to-write-in-ReceiveQueue)
{
70

seton(recvqueueSemaphore);
writeQueue(authReq,ReceiveQueue);
setoff(recvqueueSemaphore);
freeTimer(Timer[authReq->id].timeId);
}
}
}
if fork() /* taïo send-part*/
{

while (1)
{
if (SendQueue <> NULL)
{
if (semaphore-enable-to-write-in-SendQueue)
{
seton(sendqueueSemaphore);
idQ = readQueue(&authReq,SendQueue);
freeQueue (idQ, SendQueue);
71

setoff(sendqueueSemaphore);
sendto(send_sockfd, authReq,…);
}

}
}
}
if error exit(-1);
wait on children-processes
}

TimerThread ()
{
while (1)
{
for ( n = 0; n < MAX_TIMER;n++)
{
if Timer[n].timeId < 0 continue;
72

if Timer[n].numClock == 0
freeTimer(Timer[n].timeId);
else
Timer[n].numClock ;
}
}
}

Khi thực hiện phương pháp này, ta tránh được pooling nhưng phải trả giá thực hiện khó
Timer và sempahore. Việc coding sẽ phức tạp và dễ sinh lỗi nhưng kết quả nếu thu được
sẽ tốt hơn phương pháp một. Chương trình sẽ chạy càng tốt ở trạng thái tải mạng cao khi
Semaphore và Timer được thực hiện chính xác và tối ưu.

IV. Phương Pháp 3:
Phương pháp này giống phương pháp hai ở chỗ xây dựng một Radius Proxy Server độc lập với
source code của Radius Server. Tuy nhiên trong phương pháp này, ta không xây dựng 2
process chính là Receiver và Sender cùng các queues của chúng, mà chỉ xây dựng một
process chính receiver có nhiệm vụ nhận các requests gởi đến và xử lý các requests này. Mỗi
lần nhận được request từ client, receiver sẽ tạo ra một process mới chòu trách nhiệm riêng cho
request đó. Các requests từ client do đó không phải chờ đợi tới phiên mình được xử lý trên
queue. Số requests bò timeout tương ứng cũng giảm đi.
73

Các process con tương ứng với mỗi request sẽ phân tích dạng request; kiểm tra xem
thông tin của request đã có trong cache chưa, nếu có thì sẽ tạo gói trả lời cho client mà không
cần phải xác nhận với Radius Server, nếu không có thì sẽ tiến hành xác nhận với Radius
Server, chờ nhận trả lời trả về và tạo gói trả lời cho client.
Mỗi lúc Radius Proxy gởi request tới Radius Server, timer sẽ được tạo ra. Trong một
thời gian nhất đònh, request nào không thể gởi được sẽ bò timeout.

Do sự đơn giản và hiệu quả của nó, phương pháp này được chọn để phát triển thành
mã nguồn.







74

Chương VI:
WEBADMIN và GIAO DIỆN QUẢN LÝ

I. Giới thiệu về Webadmin

Các mạng thông tin hiện nay không còn giới hạn ở mạng cục bộ (Local) như trước mà đã phát
triển thành mạng diện rộng (WAN) lớn hơn và phức tạp hơn trước rất nhiều. Do đó yêu cầu về
quản trò các mạng này với gánh nặng chi phí tối thiểu, thời gian và độ phức tạp thấp nhưng với
độ tin cậy cao và hiệu quả đã được đặt ra nhằm hỗ trợ cho các nhà quản trò hệ thống. Chương
trình Webadmin cho phép các nhà quản trò hệ thống có thể quản trò mạng từ xa (remote
administration) thông qua các trình duyệt web (Web browser) trong việc quản lý hệ thống
mạng của mình.

1. Webdmin –0.64:
Chương trình Webadmin được viết trên ngôn ngữ Perl5 và CGI. Đây là chương trình cho phép
quản trò các dòch vụ trên hệ thống như account, Internet Service, DNS, file sharing trên môi
trường UNIX.

a. Cấu trúc chương trình:

Các module chính của chương trình như sau:
75

1. Account: dùng cho việc quản lý user, password, và phân quyền cho user webmin.
Dùng thư viện acl.pl.
2. DNS: dùng cho việc quản lý DNS. Dùng thư viện dns-lib.pl
3. Export: dùng cho việc export các nfs (network file system). Dùng thư viện export-lib.pl
4. Fdisk:
 dstatus-pl dùng để hiển thò trình trạng, kiểu và mount của các thiết bò.
 Fdisk-lib.pl: dùng để quản lý đóa mhư tạo, xoá partition
Kết hợp các các CGI như fsck.cgi , mkfs.cgi
1. File: dùng để quản lý file trên linux. Dùng thư viện file-lib.pl kết hợp với các CGI cho
phép tạo, sao chép, xoá, phân quyền, hiển thò cấu trúc thư mục…
2. Format: cho phép quản lý đóa trên solaris
3. Inetd: cho phép quản lý file inet.conf và file services
4. Init: dùng cho việc boot và shutdown
5. Lpadmin: dùng cho việc quản lý máy in. Dùng thư viện linux-lib.pl (cho Linux) hoặc
solaris-lib.pl (cho solaris)
6. Mount: dùng để hiển thò, tạo các mount point.
7. Proc: dùng cho việc xuất ps. Dùng thư viện freebsd-lib.pl
8. Sendmail: dùng cho việc gửi và nhận mail.
9. Useradmin: dùng cho việc quản lý user.
76

10. Webmin: dùng cho việc quản lý webserver như thay đổi thông tin cấu hình web.

Các thư viện trên sử dụng thư viện web-lib.pl là thư viện chứa các lệnh chuẩn như đọc fiel
,viết file, thay đổi đòa chỉ ip, sao chép dữ liệu.
b. Cài đặt: chạy setup.sh trong thư mục Webmin. Phần setup này sẽ chỉ ra các thông tin cấu
hình cần cài đặt như:

 /etc/webmin : thư mục chứa tập tin config.
 /usr/sbin/perl: đường dẫn của ngôn ngữ Perl.
 hostname: tên Webserver.
 Port: ta có thể dùng port mặc đònh.
c. Khởi động Webadmin: /etc/webmin/start
II. Xây dựng module quản lý Radius Proxy
Chương trình Webmin dùng thuận tiện cho việc quản trò hệ thống. Module quản lý Radius
Proxy được tích hợp vào chương trình Webmin cho phép khởi động (start) và kết thúc (stop)
Radius Proxy.


77

PH LC

1. Cỏc ti liu tham kho

[1] Security in Computing; Charles P. Pfleeger; AT&T Bell Laboratories; Prentice Hall
International Editions.
[2] UNIX Sytem V Release 4 Programmers Guide: Networking Interface ; AT&T Bell
Laboratories; Prentice Hall International Editions.
[3] Advanced Unix Programming; Marc J. Rochkind; Prentice Hall International Editions.
[4] The KornShell Command and Programming Language; Mrris I. Bolsky David G. Korn;
AT&T Bell Laboratories; Prentice Hall International Editions.
[5] Unix System V/386 Programmers Guide; AT&T Bell Laboratories; Prentice Hall
International Editions.
[6] Data Networks Concepts, Theory, and Practice; Uyless D. Black; Prentice Hall
International Editions.

1. Caực ủũa chổ taứi lieọu tham khaỷo:

78








2. Các RFC

RFC #768 – về mô hình phân lớp của mạng
RFC #2058 - công bố bởi IETF 1996 về chuẩn RADIUS
RFC #2138 – công bố bởi Livingston 1997 về RADIUS Accounting
RFC #2139 – công bố bởi Livingston 1997 về RADIUS Server