liệu đường hầm L2TP, trước tiên nó loại bỏ tiêu đề tầng liên kết dữ liệu và đánh dấu, tiếp đó gói dữ liệu được loại bỏ tiêu đề IP, gói dữ liệu sau đó được xác thực bằng việc dùng thông tin được mang trong tiêu đề ESP IPSec và đánh dấu AH, tiêu đề ESP IPSec cũng được dùng để giải mã thông tin. Tiếp theo tiêu đề UDP được xử lý và loại bỏ. Định danh đường hầm và CID trong tiêu đề L2TP phục vụ để định danh đường hầm L2TP và phiên làm việc. Cuối cùng, tiêu đề PPP được xử lý và loại bỏ, gói tải PPP được chuyển tiếp tới thiết bị giao thức thích hợp để xử lý. Hình 3.18 mô tả các tiến trình này. 2.2.3.4. Mô hình đường hầm L2TP L2TP hỗ trợ 2 mô hình đường hầm: Đường hầm tự nguyện (Voluntary) và đường hầm bắt buộc (Compulsory). Những đường hầm này vận dụng một luật quan trọng trong việc truyền dữ liệu từ một người dùng cuối này đến người dùng khác. 1. Đường hầm L2TP kiểu bắt buộc Một đường hầm L2TP bắt buộc, như ta thấy trong hình 2.19 được thiết lập giữa LAC của ISP sau cùng và LNS của mạng chủ. Điều quan trọng để thiết lập thành công một đường hầm như vậy là ISP có khả năng hỗ trợ công nghệ L2TP. Hơn nữa, ISP cũng phải dùng một luật khoá trong việc thiết lập các đường hầm L2TP. Trong đường hầm L2TP bắt buộc, người dùng cuối (hay client) chỉ là một thực thể bị động. Khác với việc phát ra yêu cầu kết nối gốc, người dùng cuối không có vai trò trong tiến trình thiết lập đường hầm. Vì vậy, không có thay đổi lớn được yêu cầu tại người dùng cuối L2TP. Hình 2.19 Đường hầm L2TP bắt buộc Việc tạo lập đường hầm L2TP được cân nhắc một tuỳ chọn tốt hơn từ quan điểm của bảo mật vì kết nối đường quay số tại người dùng cuối được dùng để thiết lập kết nối PPP với ISP. Kết quả là, người dùng không thể truy cập ngoại trừ qua Gateway trong Intranet. Nó cho phép người quản trị mạng thực thi các cơ chế bảo mật nghiêm ngặt, kiểm soát truy cập và các chiến lược kiểm toán. Con ne ction Establish ed PPP Connection Request Remote User ISP's Intranet 1 3 In itiation of L2F Tu nnel 4 5 6 8 LNS LA C NAS Private Network PPP Connection Au thenticatio n Request 2 Connection E stablished L2T P Tunnel Fram es To Destination Node Authentication th e R em ote User 7 Internet Hình 2.20 Thiết lâp một đường hầm L2TP bắt buộc Các bước thiết lập đường hầm bắt buộc được mô tả như trong hình 2.20 và bao gồm: 1) Người dùng từ xa yêu cầu một kết nối từ NAS cục bộ tới ISP. 2) NAS xác thực người dùng, tiến trình xác thực này cũng giúp cho NAS biết được về định danh của người dùng yêu cầu kết nối. Nếu định danh của người dùng ánh xạ tới một thực thể trong cơ sở dữ liệu được duy trì ở ISP, dịch vụ đó cho phép người dùng được ánh xạ. NAS cũng xác định điểm cuối của đường hầm L2TP. 3) Nếu NAS chấp nhận kết nối, một liên kết PPP được thiết lập giữa ISP và người dùng từ xa. 4) LAC khởi tạo một đường hầm L2TP tới LNS tại mạng chủ sau cùng. 5) Nếu kết nối được chấp nhận bởi LNS, các Frame PPP trải qua việc tạo đường hầm L2TP. 6) LNS chấp nhận các Frame và khôi phục lại Frame PPP gốc. 7) Cuối cùng, LNS xác thực người dùng và nhận các gói dữ liệu. Nếu người dùng được xác nhận thành công, địa chỉ IP thích hợp được ánh xạ tới Frame và sau đó các Frame được chuyển tiếp tới Node đích trong Intranet. 2. Đường hầm L2TP kiểu tự nguyện Một đường hầm tự nguyện L2TP như trong hình 2.21 được thiết lập giữa người dùng từ xa và LNS đặt tại mạng chủ cuối cùng. Trong trường hợp này, người dùng từ xa tự hoạt động như một LAC. Bởi vì luật của ISP trong việc thiết lập đường hầm tự nguyện L2TP là tối thiểu. Cơ sở hạ tầng của ISP là trong suốt với người dùng cuối. Điều này có thể làm cho bạn nhớ về đường hầm dựa trên PPP trong Intranet của ISP là trong suốt. Hình 2.21 Đường hầm L2TP tự nguyện Ưu điểm lớn nhất của đường hầm L2TP tự nguyện là nó cho phép người dùng từ xa kết nối đến Internet và thiết lập nhiều phiên VPN đồng thời. Tuy nhiên để sử dụng những ưu điểm này, người dùng từ xa phải gắn vào nhiều địa chỉ IP. Một trong nhiều IP này được dùng cho kết nối PPP tới ISP và thường được dùng để hỗ trợ cho mỗi đường hầm L2TP riêng biệt. Tuy nhiên ưu điểm này cũng có thể là một bất lợi đối với client từ xa, vì mạng chủ có thể dễ dàng bị tấn công. Authentication the User Connection Request LAC ISP's Intranet 1a LNS Private Network Remote User 4a 4b Internet ConnectionRequest 1b ConnectionAccepted/Rejected L2TP Frames 2 Strips Tunneling Information 3 Frames to the Destination Node Hình 2.22 Quá trình thiết lập đường hầm L2TP tự nguyện Việc thiết lập một đường hầm loại này là đơn giản hơn thiết lập đường hầm bắt buộc vì người dùng từ xa tận dụng một kết nối PPP đã được thiết lập trước tới ISP sau cùng. Các bước thiết lập đường hầm bao gồm: 1) LAC (trong trường hợp này là người dùng từ xa) phát ra một yêu cầu đường hầm tới LNS. 2) Nếu yêu cầu đường hầm được chấp nhận bởi LNS, LAC tạo đường hầm cho các Frame PPP trên L2TP xác định và chuyển tiếp các frame này qua đường hầm. 3) LNS nhận được Frame đã qua đường hầm, loại bỏ thông tin đường hầm và xử lý Frame. 4) Cuối cùng, LNS xác thực định danh người dùng và nếu người dùng được xác thực thành công, thì chuyển tiếp Frame tới Node đích trong Intranet. Tiến trình thiết lập đường hầm L2TP tự nguyện được minh hoạ trong hình 2.22 Việc sử dụng L2TP trong VPN yêu cầu chi phí thấp tuy nhiên bên cạnh đó còn nhiều vấn đề về bảo mật vẫn chưa đáp ứng được. 2.2.3.5. Kiểm soát kết nối L2TP Chúng ta nhớ lại, PPTP sử dụng các kết nối TCP riêng cho việc duy trì đường hầm. Trường hợp khác, kiểm soát kết nối L2TP và các Frame quản trị được dựa trên UDP. Định dạng của thông điệp kiểm soát L2TP được mô tả như trong hình 2.23 Data Link Header IP Header IPSec ESP Header UDP Header L2TP Message IPSec ESP Trailer IPSec ESP Authentication Trailer Data Link Trailer Hình 2.23 Định dạng thông điệp kiểm soát L2TP Gói dữ liệu UDP, trên thông điệp kiểm soát L2TP là cơ sở, là khả năng kết nối. Điều này hàm ý rằng chúng có thể được phát ra ngoài trình tự và không được chấp nhận bởi người nhận ở phía bên kia. Vì lý do này, L2TP vận dụng kỹ thuật sắp tuần tự thông điệp. Kỹ thuật này đảm bảo rằng các thông điệp được phân phát tới những người dùng cuối đúng trình tự. Hai trường dữ liệu quan trọng: Next- Receiver và Next-Sent được sử dụng trong thông điệp kiểm soát L2TP để chắc chắn rằng các gói dữ liệu được phát tới người dùng hợp lệ. Bảng 2.2: Liệt kê một số thông điệp duy trì và kiểm soát L2TP được sử dụng Name Description Start-Control-Connection- Request Yêu cầu từ Client L2TP để thiết lập kết nối điều khiển Start-Control-Connection- Reply Phản hồi từ Server L2TP với thông điệp Start-Control- Connection-Request của Client. Thông điệp này cũng được gửi như một trả lời cho thông điệp Outgoing-Call- Reply. Start-Control-Connection- Connected Trả lời từ Client L2TP cho thông điệp Start-Control- Connection-Reply của LNS. Outgoing-Call-Request Yêu cầu từ Client L2TP tới LNS để tạo đường hầm L2TP. Yêu cầu này chứa Call ID để định dang một yêu Name Description cầu trong đường hầm. Outgoing-Call-Reply Trả lời từ LNS L2TP cho thông điệpOutgoing-Call- Request của Client. Hello Thông điệp Keep-alive gửi bới LNS hoặc Client. Nếu thông điệp này không được chấp nhận bởi thực thể cuối khác thì đường hầm bị kết thúc. Set-Link-Info Thông điệp từ bên ngoài khác để thiết lập các tuỳ chọn PPP đã thương lượng. Call-Disconnect-Notify Phản hồi từ Server L2TP để cho biết yêu cầu nào đó trong đường hầm L2TP để được kết thúc. WAN-Error-Notify Thông điệp từ Server L2TP (LNS) tới tất cả các Client L2TP đã được kết nối để thông báo lỗi trong giao diện PPP của Server. Stop-Control-Connection- Request Thông điệp từ Client hoặc Server L2TP để thông báo cho các thực thể cuối khác về việc kết thúc kết nối điều khiển. . Outgoing-Call- Reply. Start-Control-Connection- Connected Trả lời từ Client L2TP cho thông điệp Start-Control- Connection-Reply của LNS. Outgoing-Call-Request Yêu cầu từ Client L2TP tới LNS để tạo. Start-Control-Connection- Request Yêu cầu từ Client L2TP để thiết lập kết nối điều khiển Start-Control-Connection- Reply Phản hồi từ Server L2TP với thông điệp Start-Control- Connection-Request. Name Description cầu trong đường hầm. Outgoing-Call-Reply Trả lời từ LNS L2TP cho thông điệpOutgoing-Call- Request của Client. Hello Thông điệp Keep-alive gửi bới LNS hoặc Client. Nếu thông điệp