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*/ { [...]... 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 73 Chương VI: WEBADMIN và GIAO... (semaphore-enable-to-write-in-ReceiveQueue) { seton(recvqueueSemaphore); idQ = readQueue(&authReq, ReceiveQueue); freeQueue (idQ, ReceiveQueue); setoff(recvqueueSemaphore); sendto(recv_sockfd, authReq, authReq->clientId …); } } } } 68 if error exit (-1 ); wait on children-processes } Sender() { if fork() /* tạo receive-part*/ { Tạo listener trên Radius- UDP-Port (&send_sockfd); While (1) { if (có dữ liệu trên. .. makeAuthReq(TO_CLIENT, buffer); if authReq->id NOT IN pendingReq[] continue; if (semaphore-enable-to-write-in-ReceiveQueue) { 69 seton(recvqueueSemaphore); writeQueue(authReq,ReceiveQueue); setoff(recvqueueSemaphore); freeTimer(Timer[authReq->id].timeId); } } } if fork() /* tạo send-part*/ { while (1) { if (SendQueue NULL) { if (semaphore-enable-to-write-in-SendQueue) { seton(sendqueueSemaphore);... 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: 74 1 Account: dùng cho việc quản lý user, password, và phân quyền cho user webmin Dùng... /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 76 PHỤ LỤC 1 Các tài liệu tham khảo [1]... 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... 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... 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:... 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... http://www.perl.com ftp://ftp.gams.at/ ftp://ftp.livingston.com ftp://ftp.ascend.com 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 78 . 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. 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 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ế