Tiểu luận Tổng quan về công nghệ VPN

Phần1. Đề tài và mục đích thực hiện đề tài 3

1.1 Đề Tài 4

1.2 Mục đính thực hiện 4

Phần 2: Tổng quan về mạng VPN 5

2.1 Giới thiệu về công nghệ VPN 5

2.2 Khái niệm 5

2.3 Các loại VPN 6

VPN truy cập từ xa 6

VPN điểm-nối-điểm 7

2.4 Các yêu cầu đối với VPN 7

2.4.1 Bảo mật trong VPN 8

Máy chủ AAA 9

2.4.2 Tính sẵn sàng và tính tin cây. 9

2.4.3 Chất lượng dịch vụ 9

2.4.4 Khả năng quản trị 10

2.4.5 Khả năng tương thích 10

2.4.6 Sản phẩm công nghệ dành cho VPN 11

2.5 Các kĩ thuật trong mạng VPN 11

2.5.1 Kỹ thuật Tunneling trong mạng VPN điểm-nối điểm 12

2.5.2 Kỹ thuật Tunneling trong mạng VPN truy cập từ xa 12

2.6 Các thành phần trong mạng VPN 12

2.6.1 Các thành phần của một tunning 12

2.6.2 Định dạng gói dữ liệu VPN. 13

2.7 Hoạt động của VPN 14

Phần 3: Công Nghệ Mạng Riêng Ảo (VPN) 16

3.1 Point-to-Point Protocol (PPP). 16

3.1.1 Quá trình hoạt động PPP 17

3.1.2 PPP Packet Format 18

3.1.3 PPP Link Control 18

3.2 Point-to-Point Tunneling Protocol (PPTP) 19

3.2.1 Vai trò của PPP trong giao dịch PPTP 20

3.2.2 Các thành phần của quá trình giao dịch PPTP 21

3.2.3 Quá trình xữ lý PPTP 22

Phần 4: Triển khai hệ thống VPN 26

4.1 Mô tả mô hình 26

4.2 Thiết lập máy chủ CA (Certificate Authority) cho máy chủ OpenVPN và các máy khách 26

4.3 Cấu hình cho máy chủ và máy khách kết nối VPN 29

4.3.1 Tệp cấu hình cho máy chủ 29

4.3.2 Tệp cấu hình cho máy khách 34

4.3.3 Kết quả: 37

Phần 5: Kết luận 39

5.1.1 Thuận lợi 39

5.1.2 Bất lợi 39

 

doc39 trang | Chia sẻ: lethao | Lượt xem: 3923 | Lượt tải: 1download
Bạn đang xem trước 20 trang tài liệu Tiểu luận Tổng quan về công nghệ VPN, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
r, router và router. So với PPTP thì L2TP có nhiều đặc tính mạnh và an toàn hơn. 2.6 Các thành phần trong mạng VPN 2.6.1 Các thành phần của một tunning Mạng đích. Là mạng trong đó có chứa tài nguyên, dữ liệu mà người dùng từ xa cần truy cập đê sử dụng, là những người khởi tạo ra phiên yêu cầu VPN. Nút khởi tạo. Người dùng khách hoặc máy chủ tạo phiên kết nối VPN. Nút khởi tạo có thể là một phần của mạng cục bộ hoặc có thể là người dùng di động. HA (Home Agent). Chương trình này thường chú tại các nút mạng (Router) trong mạng đích và làm nhiệm vụ xác nhận những yêu cầu gửi đến để xác thực chúng từ những host đã được ủy quyền. Khi xác nhận thành công, HA cho phép thiết lập tunnel. FA (Foreign Agent). Chương trinh thường cư chú tại các nút khởi tạo hoặc ở các nút truy cập mạng của hệ thống mạng. Các nút khởi tạo dùng FA để yêu cầu một phiên VPN từ HA ở mạng đích. 2.6.2 Định dạng gói dữ liệu VPN. Như đã được mô tả ở phần trước, trước khi gói dữ liệu nguyên gốc được phân phát đến mạng đích thông qua tunnel, nó đã được mã hóa bởi FA. Gói dữ liệu mã hóa này được đề cập như một tunneled packet. Định dạng của một tunneled packet được mô tả theo hình bên dưới. Hình 4: Định dạng của tunneled packet Như đã thấy ở hình 4, một tunneled packet bao gồm 3 phần: Header of the routable protocol. Phần đầu chứa địa chỉ nguồn (FA) và đích (HA). Bởi vì quá trình giao dịch thông qua Internet chủ yếu là dựa trên cơ sở IP, phần đầu này là phần IP header chuẩn phổ biến và chứa địa chỉ IP của FA, HA  tham gia trong qua trinh giao dịch. Tunnel packet header. Phần đầu này chứa 5 phần sau : Protocol type. Trường này chỉ ra loại giao thức của gói dữ liệu nguyên gốc (hoặc pay-load). Kiểm tra tổng (Checksum). Phần này chứa thông tin kiểm tra tổng quát liệu gói dữ liệu có bị mất mát trong suốt qua trình giao dịch. Thông tin này tùy chọn. Khóa (Key). Thông tin này được dùng để nhận dạng hoặc xác nhận nguồn thực của dữ liệu (bộ khởi tạo). Số tuần tự (Sequence number). Trường này chứa đựng 1 con số mà chỉ ra số tuần tự của gói dữ liệu trong một loạt các gói dữ liệu đãvà đang trao đổi. Source routing. Trường này chứa đựng thêm thông tin định tuyến, phần này tuỳ chọn. Payload. Gói dữ liệu nguyên gốc được gửi đến FA bởi bộ khởi tạo. Nó cũng chứa đựng phần đầu nguyên gốc. 2.7 Hoạt động của VPN Quá trình tạo đường hầm được chia làm hai giai đoạn cơ bản sau: Giai đoạn I. Nút khởi tạo (hoặc người dùng từ xa) yêu cầu một phiên làm việc VPN và được xác nhận bởi HA tương ứng. Giai đoạn II. Dữ liệu thực sự được chuyễn qua mạng thông qua tunnel. Trong giai đoạn I , một kết nối yêu cầu được khởi tạo và những tham số phiên được đàm phán. (Giai đoạn này cũng có thể được xem như là giai đoạn thiết lập tunnel.) nếu yêu cầu được chấp nhận và tham số phiên được đàm phán thành công, một tunnel được thiết lập giữa hai nút thông tin đầu cuối. Điều này xảy ra qua những việc chính sau : Nút khởi tạo gửi yêu cầu kết nối đến vị trí FA trong mạng. FA xác nhận yêu cầu bằng cách thông qua tên truy cập và mật khẩu được cung cấp bởi người dùng. (Thông thường FA sử dụng các dịch vụ của một máy chủ Remote Access Dial-Up Services (RADIUS) để xác nhận sự thống nhất của các nút khởi tạo.) Nếu tên truy cập và mật khẩu cung cấp bởi người dùng không hợp lệ, yêu cầu phiên làm việc VPN bị từ chối. Ngược lại, nếu quá trình xác nhận sự thống nhất của FA thành công, nó sẽ chuyễn yêu cầu đến mạng đích HA. Nếu yêu cầu được HA chấp nhận, FA gửi login ID đã được mã hóa và mật khẩu tương ứng đến nó. HA kiểm chứng thông tin đã được cung cấp. Nếu quá trình kiểm chứng thành công, HA gửi những Register Reply, phụ thuộc vào một số tunnel đến FA. Một tunnel được thiết lập khi FA nhận Register Reply và số tunnel.  Ghi chú : Nếu 2 điểm đầu cuối không sử dụng cùng giao thức tunneling, một số tham biến cấu hình tunnel như mã hóa, tham số nén, và cơ chế duy trì tunnel cũng được đàm phán. Với việc thiết lập tunnel, giai đoạn I được xem như đã xong và giai đoạn II, hay giai đoạn chuyễn giao dữ liệu, bắt đầu. Quá trình giao dịch trong giai đoạn II này thực hiện qua các bước sau : Nút khởi tạo bắt đầu chuyển hướng các gói dữ liệu đến FA. FA tạo tunnel header và chèn nó vào từng gói dữ liệu. Thông tin header của giao thức định tuyến (được đàm phán trong giai đoạn I) sau đó được gắn vào gói dữ liệu. FA chuyển hướng các gói dữ liệu đã mã hóa đến HA bằng cách sử dụng tunnel number đã được cung cấp. Trong quá trình nhận thông tin mã hóa, HA cởi bỏ tunnel header và header của giao thức định tuyến, đưa gói dữ liệu trở về dạng nguyên bản của nó. Dữ liệu nguyên gốc sau đó được chuyển hướng đến nút mong muốn cần đến trong mạng.   Hình 5: Quá trình truyền dữ liệu qua tunnel Phần 3: Công Nghệ Mạng Riêng Ảo (VPN) Như phần trên đã trình bày, việc tạo ra đường hầm và hỗ trợ của nó trong việc đảm bảo an toàn bảo mật cho các giao dịch qua mạng trung gian không an toàn. Phần này sẽ trình bày về các giao thức cho phép và hỗ trợ các công nghệ đường hầm này. Giao thức đường hầm là cơ sở để xây dựng VPN và bảo mật các giao dịch qua mạng VPN. Chức năng tạo giao thức đường hầm hầu hết được thực thi tại lớp 2 của mô hình OSI. 3.1 Point-to-Point Protocol (PPP). PPP là một giao thức đóng gói dữ liệu thuận tiện trong việc vận chuyển lưu thông mạng thông qua các kết nối nối tiếp point-to-point. Thuận lợi lớn nhất của PPP là nó có thể hoạt động đem lại hiệu quả cho bất kỳ Data Terminal Equipment (DTE) hoặc Data Connection Equipment (DCE) bao gồm EIA/TIA-232-C và ITU-T V.35. một điểm yêu thích nữa của PPP là nó không giới hạn tỉ lệ giao dịch. Cuối cùng, chỉ thiết bị PPP có thể cho một kết nối kép (2 chiều) có thể đối xứng hoặc không đối xứng và có thể thao tác theo phương thức chuyễn mạch hoặc chuyên dụng. Chú ý : EIA/TIA-232-C trước đây được hiểu là RS-232C. Ngoài việc đóng gói dữ liệu IP và non-IP và nó vận chuyễn qua các kết nối nối tiếp, PPP cũng đảm nhiệm một số chức năng sau đây : Chỉ định và quản lý từ các địa chỉ IP đến các gam dữ liệu non-IP. Cấu hình và kiểm tra các kết nối đã được thiết lặp. Đóng gói không đồng bộ và đồng bộ các gam dữ liệu. Phát hiện lỗi trong suốt quá trình giao dịch. Trộn các đa giao thức ở tầng 2. Đàm phán các tham số cấu hình tuỳ chọn, như nén và đánh địa chỉ dữ liệu. PPP thực hiện chức năng này bằng 3 tiêu chuẩn : Tiêu chuẩn cho việc đóng gói những gói dữ liệu qua các nối kết điểm-điểm. Chú ý : Tiêu chuẩn cho việc đóng gói các gói dữ liệu thông qua các kết nối điểm-điểm là phương thức lỏng lẻo trong giao thức High-Level Data Link Control (HDLC). Ngoài ra, cũng có sự khác nhau giữa 2 chuẩn. Ví dụ : HDLC phân chia gói dữ liệu ra thành frame, PPP thì không. Tiêu chuẩn cho việc thiết lặp, cấu hình, và kiểm tra kết nối điểm-điểm với sự giúp đở của Link Control Protocol (LCP) Tiêu chuẩn cho việc thiết lặp và cấu hình một số các giao thức tầng mạng và phát hiện lỗi trong suốt quá trình giao dịch dưới hình thức của Network Control Protocol (NCP) phù hợp. 3.1.1 Quá trình hoạt động PPP Các hoạt động của PPP được tiến hành theo những phương cách sau : 1.    Sau khi đóng gói các gói dữ liệu, nút nguồn (hay bộ khởi tạo) gửi LCP frame thông qua liên kết điểm-điểm đến nút cần đến. 2.   Những frame này được dùng để cấu hình kết nối theo tham số xác định và kiểm tra các kết nối đã được thiết lặp nếu có. 3.   Sau khi nút đích chấp nhận yêu cầu kết nối và một kết nối được thiết lặp thành công, những tùy chọn thuận lợi được đã đàm phán, được xác định bời LCPs. 4.   Sau đó nút nguồn gửi các frame NCP để lựa chọn và cấu hình các giao thức tầng mạng. 5.   Sau khi các giao thức  tầng mạng đã được cấu hình , 2 điểm cuối bắt đầu trao đổi dữ liệu cho nhau. Hình 6: Khởi tạo một liên kết PPP và trao đổi dữ liệu Khi một kết nối được thiết lặp, nó sẽ tồn tại cho đến khi LCP hay NCP frame báo hiệu điểm cuối liên kết. Nối kết sẽ bị ngắt trong trường hợp nối kết không thành công hoặc có sự can thiệp của người dùng. 3.1.2 PPP Packet Format Có 6 trừơng cấu thành một PPP frame : Flag. Trường này chỉ định phần đầu và phần đuôi của 1 frame. Chiều dài của trường này là 1 byte. Address. Bởi vì sử dụng kết nối điểm-điểm, PPP không dùng địa chỉ của các nút riêng lẻ. Do đó, trường này chứa một chuổi số nhị phân 11111111, là địa chỉ broadcast. Chiều dài của trường này là 1 byte. Control. Trường này chứa dãy số nhị phân 00000011, có nghĩa là frame đang mang dữ liệu của người dùng là một frame thiếu trình tự  chỉ ra tính chất quá trình giao dịch không kết nối của PPP. Chiều dài của trường này là 1 byte. Protocol. Trường này chỉ ra giao thức của dữ liệu đã được đóng gói trong trường dữ liệu của frame. Giao thức trong trường này được xác định theo con số đính kèm trong bộ RFC 3232. chiều dài của trường này là 2 byte. The length of the field is two bytes. Tuy nhiên, cũng có thể là 1 byte nếu cả hai ngang cấp. Data. Trường này chứa đựng thông tin hiện tại được trao đổi giữa các nút nguồn và đích. Chiều dài của trường này rất khác nhau, tuy nhiên chiều dài tối đa của trường này có thể lên đến 1500 byte. FCS (Frame Check Sequence). Trường này chứa đựng trình tự kiểm tra giúp người nhậ xác nhận chính xác thông tin vừa nhận trong trường dữ liệu. Thông thường, chiều dài của trường là 2 byte. Tuy nhiên, việc triển khai PPP có thể đạt đến 4 byte FCS nhằm mục đích tăng khả năng phát hiện lỗi. Hinh7: Định dạng của PPP frame. 3.1.3 PPP Link Control Để tăng khả năng thành công khi trao đổi dữ liệu giữa 2 nút, PPP cũng đảm nhiệm chức năng điều khiển kết nối được thiết lặp giữa hai thông tin đầu cuối. PPP sử dụng LCP trong mục đích này, sau đây là những chức năng của LCP : Giúp đỡ thiết lặp nối kết PPP. Cấu hình các nối kết đã được thiết lặp nhằm đáp ứng các yêu cầu của các bên thông tin. Thực hiện chức năng bảo trì thường xuyên các kết nối PPP. Kết thúc nối kết nếu dữ liệu trao đổi giữa hai đầu cuối hoàn thành. Chú ý : Trong PPP, thuật ngữ “link” (nối kết) đại diện cho kết nối điểm-điểm. LCP dựa trên điều khiển kết nối xảy ra trong 4 giai đoạn, giai đoạn thiết lặp kết nối và đàm phán, giai đoạn xác định chất lượng kết nối, giai đoạn đàm phán giao thức tầng mạng, và giai đoạn kết thúc kết nối. Mô tả dưới đây tổng kết lại 4 giai đoạn điều khiển kết nối : Link establishment and negotiation. Trước khi có bất kỳ sự trao đổi dựa trên PPP có thể xảy ra giữa 2 nút nguồn và đích, LCP phải thiết lặp (mở) kết nối giữa 2 đầu cuối và đàm phán các tham số cấu hình. LCP dùng Link-establishment frames cho mục đích này. Khi mỗi đầu cuối trả lại với chính Configuration-Ack frame của nó, giai đoạn này kết thúc. Link quality determination. Giai đoạn này là giai đoạn tùy chọn, nhằm xác định xem chất lượng của kết nối đã sẵn sàng cho các giao thức tầng mạng không. Network-layer protocol negotiation. Trong giai đoạn này, dữ liệu của giao thức tầng dưới (tầng Network) mà đã được đóng gói trong trường Protocol của PPP frame được đàm phán. Link termination. Đây là giai đoạn cuối cùng của LCP và dùng để kết thúc kết nối PPP đã thiết lặp trước giữa hai đầu cuối. Công việc kết thúc kết nối có thể diễn ra suôn sẽ, tế nhị và cũng có thể đột ngột, bất thình lình. Sự ngắt kết nối tế nhị xảy ra sau khi dữ liệu trao đổi giữa hai đầu cuối hoàn thành, hoặc ở yêu cầu của một trong hai bên (đầu cuối). Một sự kiện vật lý, như mất người vận chuyễn hoặc hết thời hạn của một khoảng thời gian nhàn rổi, sự ngắt kết nối bất thình lình sẽ xảy ra. Link-termination frames được trao đổi giữa các bên có liên quan trước khi bị ngắt kết nối. Ngoài Link-establishment và Link-termination frames, PPP sử dụng một loại frame thứ 3 được gọi là Link-maintenance frames. Những frame này, giống như tên gợi ra, được trao đổi trong những vấn đề có liên  kết nối và dùng để quản lý và debug các kết nối PPP. Ngày nay mặc dù không được sử dụng như VPNs, công nghệ PPP là nguyên tắc cơ bản cho các giao thức tunneling khác sử dụng rộng rãi trong VPNs. Thật vậy, tất cả các giao thức tunneling phổ biến  đều dựa trên PPP và đóng gói PPP frames vào IP hay các datagram khác cho việc giao dịch thông qua mạng trung gian. 3.2 Point-to-Point Tunneling Protocol (PPTP) PPTP là một giải pháp độc quyền cung cấp khả năng bảo mật giữa remote client và enterprise server bằng việc tạo ra một VPN thông qua một IP trên cơ sở mạng trung gian. Được phát triển bởi PPTP Consortium (Microsoft Corporation, Ascend Communications, 3COM, US Robotics, và ECI Telematics), PPTP được đưa ra dựa trên yêu cầu VPNs thông qua mạng trung gian không an toàn. PPTP không những tạo điều kiện dễ dàng cho việc bảo mật các giao dịch thông qua TCP/IP trong môi trường mạng chung, mà còn qua mạng riêng intranet. Chú ý: Khi Microsoft sử dụng vai trò khóa trong sự phát triển của PPTP, tất cả các sản phẩm về mạng của Microsoft, như  Windows NT 4.0 (server và workstation editions) và Windows 2000, hổ trợ  PPTP natively. Công dụng của PSTNs (Public Switched Telephone Networks). PPTP cho phép sử dụng PSTNs cho việc triển khai VPNs. Kết quả là, quá trình xử lý sự phát triển VPN đặc biệt đơn giản và tổng chi phí cho việc triển khai thì khá thấp. Đối với những doanh nghiệp có kết nối mạng diện rộng dựa trên các đường thuê bao leased line được loại bỏ. Hỗ trợ giao thức Non-IP. PPTP cũng hổ trợ một số giao thức triển khai mạng thông thường khác như  TCP/IP, IPX, NetBEUI, và NetBIOS. 3.2.1 Vai trò của PPP trong giao dịch PPTP PPTP là phần mở rộng của PPP, nó không thay đổi công nghệ PPP. Nó chỉ định nghĩa một phương pháp mới trong việc vận chuyển lưu lượng VPN thông qua một mạng chung không an toàn. Khá giống PPP, PPTP cũng không hổ trợ đa kết nối, tất cả các kết nối PPTP đều ở dạng  điểm-điểm. PPP thực hiện một số chức năng giao dịch dựa trên PPP : Thiết lặp và kết thúc các kết nối vật lý giữa 2 đầu cuối thông tin. Xác thực PPTP clients. Mã hóa IPX, NetBEUI, NetBIOS, TCP/IP datagrams để tạo ra PPP datagrams và bảo mật dữ liệu trao đổi giữa các bên có liên quan. Chú ý: PPP có thể sử dụng một số cơ chế xác nhận như cleartext, encrypted, hoặc Microsoft-encrypted cho việc xác nhận các PPTP clients. Hình 8: The three responsibilities of PPP in a PPTP transaction. Chú ý: vai trò của PPP rất giống L2F và L2TP trong quá trinh giao dịch. 3.2.2 Các thành phần của quá trình giao dịch PPTP Bất kỳ quá trình giao dịch nào dựa trên PPTP triển khai ít nhất 3 thành phần, các thành phần đó là : PPTP client Network Access Server (NAS) PPTP server Hình 9: A PPTP tunnel and the three components of PPTP-based transactions. 3.2.2.1  PPTP Clients Một PPTP client là một nút mạng hổ trợ PPTP và có thể yêu cầu những nút khác cho một phiên VPN. Nếu kết nối được yêu cầu từ một remote server. PPTP client phải sử dụng dịch vụ của ISP’s NAS. Vì lý do đó, client phải dùng modem để kết nối vào kết nối PPP tới nhà ISP.  PPTP client cũng phải được kết nối vào thiết bị VPN để có thể tunnel yêu cầu (và dữ liệu tiếp theo, nếu yêu cầu được chấp nhận) đến thiết bị VPN trên mạng từ xa. Kết nối đến các thiết bị VPN từ xa sử dụng kết nối quay số đầu tiên đến ISP’s NAS để thiết lặp một tunnel giữa hai thiết bị VPN thông quan Internet hoặc các mạng trung gian khác. Không giống những yêu cầu cho các phiên kết nối VPN từ xa, yêu cầu cho một phiên VPN đến một mạng cục bộ không yêu cầu một kết nối đến ISP’s NAS. Cả client và server đều đã được kết nối về mặt vật lý, việc tạo ra một kết nối đến ISP’s NAS là không cần thiết. Client, trong trường hợp này, chỉ yêu cầu các phiên kết nối  quay số bằng thiết bị VPN trên server. Khi các gói dữ liệu yêu cầu định tuyến cho một yêu cầu từ xa và một yêu cầu kết nối cục bộ khác nhau, gói dữ liệu được gắn kèm với 2 yêu cầu được xử lý khác nhau. Gói dữ liệu PPTP đến một server cục bộ mà được đặt trên thiế bị vật lý trung gian gắn kèm card mạng của PPTP client. Ngược lại, gói dữ liệu PPTP đến remote server được định tuyến thông qua phương tiện truyền thông vật lý được gắn kèm trong thiết bị thông tin, chẳng hạn như router. 3.2.2.2  PPTP Servers PPTP Servers là những nút mạng hổ trợ PPTP và có khả năng duy trì cá            c yêu cầu cho các phiên VPN từ những nút khác  (từ xa hoặc nội bộ). Để đáp lại những yêu cầu từ xa, những server phải hổ trợ khả năng định tuyến 3.2.2.3  PPTP Network Access Servers (NASs) PPTP NASs được đặt tại nhà cung cấp dịch vụ ISP và cung cấp kết nối Internet đến các client sử dụng PPP để quay số. Khả năng có nhiều client đồng thời đưa ra yêu cầu phiên một VPN là rất cao, những server phải có khả năng hổ trợ đồng thời nhiều client. Hơn nữa, PPTP client không bị hạn chế với các hệ điều hành không phải của Microsoft. Do đó, PPTP NASs có khả năng xữ lý dùng nhiều hệ điều hành khác nhau như  Microsoft's Windows, Unix, và Apple's Macintosh. 3.2.3 Quá trình xữ lý PPTP PPTP tận dụng 3 quá trình xữ lý để bảo đảm cho thông tin liên lạc PPTP thông qua môi trường không an toàn. Những quá trình đó là : Quá trình thiết lặp kết nối PPP Điều khiển kết nối PPTP tunneling và trao đổi dữ liệu 3.2.3.1  Điều khiển kết nối PPTP Sau khi kết nối PPP giữa PPTP client và server được thiết lặp, quá trình điều khiển PPTP bắt đầu. Như hình 5-7, PPTP connection control được thiết lặp dựa trên cơ sở địa chỉ IP của client và server, sử dụng cổng TCP động và chiếm giữ cổng TCP 1723. Sau khi quá trình điều khiển kết nối được thiết lặp, các thông tin điều khiển và quản lý sẽ được trao đổi giữa các bên có liên quan trong quá trình giao tiếp. Những thông tin đảm nhiệm vai trò bảo trì, quản lý và kết thúc PPP tunnel. Những thông điệp này là những thông điệp có định kỳ bao gồm "PPTP-Echo-Request, PPTP-Echo-Reply" dùng để giúp đỡ trong việc dò tìm các kết nối PPTP hư hỏng giữa server và client. Hình 10: Exchanging PPTP control messages over a PPP connection. Một số thông điệp phổ biến được dùng trong việc điều khiển PPTP được thể hiện ở bảng sau : Bảng 3-1 : một số thông điệp phổ biến trong PPTP Control Tên Mô tả Start-Control-Connection-Request Yêu cầu từ PPTP client để thiết lặp kết nối điều khiển. Start-Control-Connection-Reply Hồi đáp từ PPTP server đến thông điệp Start-Control-Connection-Request từ client. Outgoing-Call-Request Yêu cầu từ PPTP client đến server để thiết lặp một PPTP tunnel. Outgoing-Call-Reply Hồi đáp từ PPTP server đến thông điệp Outgoing-Call-Request của client. Echo-Request Cơ chế duy trì của client hoặc server. Nếu bên đối diện không hồi đáp lại thông điệp, tunnel sẽ được ngắt. Echo-Reply Hồi đáp lại thông điệp Echo-Request từ bên yêu cầu. Set-Link-Info Thông điệp tùy chọn từ một bên có liên quan PPP. Call-Clear-Request Thông điệp từ PPTP client khởi tạo quá trình kết thúc của tunnel. Call-Disconnect-Notify Hồi đáp từ server đến Call-Clear-Request của client. Nó cũng được xem là thông điệp từ server khởi tạo quá trình kết thúc tunnel. WAN-Error-Notify Thông điệp từ PPTP server đến tất cả các PPTP client nhằm thông báo lỗi trong PPP interface của server. Stop-Control-Connection-Request Thông điệp từ PPTP client hoặc server thông báo một sự kết thúc khác trong qua trình kết thúc kết nối điều khiển. Stop-Control-Connection-Reply Hồi đáp từ phíaa đối diện đến thông điệp Stop-Control-Connection-Request. As depicted in Figure 5-8, PPTP control messages are encapsulated in TCP datagrams. Therefore, after the establishment of a PPP connection with the remote server or client, a TCP connection is established. This connection is subsequently used to exchange PPTP control messages. Hình 11: PPTP control in the TCP datagram. 3.2.3.2  Quá trình tạo đường hầm dữ liệu và xữ lý PPTP. Một gói dữ liệu PPTP phải trãi qua nhiều giai đoạn đóng gói, bao gồm những giai đoạn sau: 1.   Quá trình đóng gói dữ liệu. Thông tin nguyên bản (tối đa) được mã hóa và được đóng gói bên trong một PPP frame. Một PPP header được thêm vào frame. 2.   Quá trình đóng gói các PPP frame. Tổng hợp các PPP frame sau đó đóng gói bên trong một Generic Routing Encapsulation (GRE) đã được sửa đổi. GRE header chứa trường 4-byte Acknowledgement và một bit Acknowledgement hồi đáp. Ngoài ra, trường khóa trong GRE frame được thay thế bằng trường 2 byte long gọi chiều dài tối đa và 2 byte long được xem là ID. PPTP client xây dựng những trường này khi nó tạo ra PPTP tuunel. 3.   Quá trình đóng gói GRE. Kết tếp, một IP header đã được đóng gói bên trong gói GRE được thêm vào PPP frame. Phần IP header này chứa dựng địa chỉ IP nguồn của PPTP client và đích của server. 4. Quá trình đóng gói tầng Data Link. PPTP là một giao thức tạo đường hầm nằm ở tầng 2. Vì vậy, phần header của Data Link và phần đuôi giữ vai trò quan trọng trong việc tạo đường hầm cho dữ liệu. Trước khi được đặt vào môi trường truyền thông, tầng Data Link thêm phần đầu và đuôi của nó vào gói dữ liệu. Nếu gói dữ liệu được truyền qua PPTP tunnel cục bộ, gói dữ liệu được đóng gói bằng phần đầu và đuôi theo công nghệ LAN (như Ethernet). Ơû một khía cạnh khác, nếu tunnel được đáp lại thông qua một kết nối WAN, phần đầu và đuôi mà được thêm vào gói dữ liệu một lần nữa thì không thay đổi. Hình 12: The process of PPTP data tunneling. Chú ý : GRE là một cơ chế đóng gói đơn giản, nhẹ cân, đa năng cho dữ liệu trên cơ sở. GRE thường được dùng bởi nhà cung cấp ISPs dùng để chuyển hướng thông tin định tuyến bên trong mạng Intranet của họ. Tuy nhiên, các internet backbone router trong mạng Intranet của ISP trích lọc lưu lượng GRE này. Do đó, PPTP tunnel đã được thiết lặp có thể bảo đảm và bí mật chuyển đến cho người nhận. Khi dữ liệu PPTP được chuyển thành công đến người nhận mong muốn, người nhận phải xữ lý gói dữ liệu đã tunnel trích ra thành dữ liệu nguyên bản. Quá trình xữ lý trích xuất PPTP-tunneled data một cách chính xác công việc phục hồi dữ liệu PPTP đã tạo hầm. Như hình 5-10, để nhận được dữ liệu nguyên gốc người nhận theo những bước sau : Người nhận xữ lý và gở bỏ phần đầu và phần đuôi của tầng Data Link header mà đã được thêm vào bởi người gửi. Kế tiếp, phần đầu GRE được gở bỏ. Phần đầu IP được xữ lý và được gở bỏ. Phần đầu PPP được xữ lý và được gở bỏ. Cuối cùng, thông tin nguyên bản được giải mã (nếu yêu cầu). Phần 4: Triển khai hệ thống VPN 4.1 Mô tả mô hình Mô hình triển khai VPN sử dụng phần mềm nguồn mở OPENVPN theo kiểu client/server sử dụng mật mã X509 PKI (Mã công khai sử dụng chứng chỉ và mã dành riêng). Sử dụng 2 tùy chọn routed và bridged VPN. Xét một các tổng quan thì lựa chọn chế độ Routing là phù hợp với số đông người sử dụng bởi khả năng dễ dàng trong triển khai và cài đặt hơn chế độ bridging. Chế độ Routing cũng cung cấp khả năng tuyệt với cho việc điều khiển truy cập của client. Chế độ briding chỉ nên được lựa chọn trong một số trường hợp đặc biệt như thực hiện kết nối trên các loại giao thức khác IP như là IPX, ứng dụng trên mạng VPN yêu cầu sử dụng địa chỉ quảng bá (broadcast) để yêu cầu thông tin truyền thông (Lan Game) và trong trường hợp bạn mong muốn sử dụng các dịch vụ Samba hoặc WINS. 4.2 Thiết lập máy chủ CA (Certificate Authority) cho máy chủ OpenVPN và các máy khách. Bước đầu tiên là cấu hình OpenVPN kết hợp với PKI (public key infrastructure). PKI bao gồm: Chuẩn bị một chứng nhận điện tử ( Biết đến như là khóa công khai) và một khóa dành riêng cho máy chủ và các máy khách. Tạo một chứng nhật điện tử chủ (CA) và một khóa làm mật hiệu cho mỗi chứng nhận của máy chủ và khách. OpenVPN hỗ trợ khả năng xác thực hai chiều dựa trên chứng nhật điện tử, có nghĩa rằng máy khách phải xác thực với máy chủ và ngược lại may chủ cũng phải xác thực lại với máy khách trước khi một kết nối an toàn được khởi tạo. 4.2.2 Tạo Certificate Authority (CA) certificate & key Trong bài Lab này chúng ta sẽ sinh một chứng chỉ gốc (Master Certificate Authority), một chứng nhận cho máy chủ và 3 chứng nhận cho máy khách.. Giả sử máy chủ là Linux và Windows ta thực hiện các bước sau để sinh key. Tạo CA certificate và key Trên Linux . ./vars ./clean-all ./build-ca Trên Windows: vars clean-all build-ca Câu lệnh cuối cùng để tạo CA certificate và key bằng việc kết hợp với câu lệnh openssl . ai:easy-rsa # ./build-ca Generating a 1024 bit RSA private key ............++++++ ...........++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [KG]: State or Province Name (full name) [NA]: Locality Name (eg, city) [BISHKEK]: Organization Name (eg, company) [OpenVPN-TEST]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:OpenVPN-CA Email Address [me@myhost.mydomain]: Chú ý: Các tùy chọn đưa ra có thể đặt theo mặc định hoặc do người dùng tự quy định. Duy nhất một tham số yêu cầu phải nhập vào một cách rõ ràng là Common Name “FNC-CA” Tạo certificate & key cho server Trên Linux ./build-key-server server Trên Windows: build-key-server server Thực hiện

Các file đính kèm theo tài liệu này:

  • docHệ thống viễn thông với công nghệ mới.doc