Hệ thống viễn thông với công nghệ mới

truyền qua môi trường không tin cậy. Giao thức bảo mật giao thức Internet (IPSec) cung cấp những tính năng an ninh cao cấp như các thuật toán mã hóa tốt hơn, quá trình thẩm định quyền đăng nhập toàn diện hơn. IPSec có hai cơ chế mã hóa là Tunnel và Transport. Tunnel mã hóa tiêu đề (header) và kích thước của mỗi gói tin còn Transport chỉ mã hóa kích thước. Chỉ những hệ thống nào hỗ trợ IPSec mới có thể tận dụng được giao thức này. Ngoài ra, tất cả các thiết bị phải sử dụng một mã khóa chung và các tường lửa trên mỗi hệ thống phải có các thiết lập bảo mật giống nhau. IPSec có thể mã hóa dữ liệu giữa nhiều thiết bị khác nhau như router với router, firewall với router, PC với router, PC với máy chủ. Máy chủ AAA AAA là viết tắt của ba chữ Authentication (thẩm định quyền truy cập), Authorization (cho phép) và Accounting (kiểm soát). Các server này được dùng để đảm bảo truy cập an toàn hơn. Khi yêu cầu thiết lập một kết nối được gửi tới từ máy khách, nó sẽ phải qua máy chủ AAA để kiểm tra. Các thông tin về những hoạt động của người sử dụng là hết sức cần thiết để theo dõi vì mục đích an toàn. 2.4.2 Tính sẵn sàng và tính tin cây. Tính sẵn sàng chỉ tổng thời gian tối đa mà người dùng có thể truy cập vào mạng. trong các mạng riêng và mạng Intranet thời gian này tương đối cao vì toàn bộ cơ sở hạ tầng mạng thuộc quyền sở hữu riêng và do tổ chức tự quản lý. Mặc dù vậy VPN sử dụng các mạng tương tác trung gian như Internet vì vậy các các thiết lập dựa trên VPN phụ thuộc nhiều vào mạng trung gian. Mà nhân tố then chốt trong trường hợp này chính là tính sẵn sàng của các ISP. Tính tin cậy cũng là một yêu cầu quan trọng của mạng VPN và nó gắn chặt với nhân tố tính sẵn sàng. Tính tin cậy trong VPN bảo đảm rằng những người dùng cuối được phân phối dữ liệu trong mọi hoàn cảnh. Cũng như hầu hết các thiết lập mạng khác, tinh tin cậy trong môi trường dựa trên VPN có thể thể đạt được bằng cách chuyển mạch các gói dữ liệu trên các đường dẫn khác nếu liên kết đã tạo hoặc thiết bị trong đường bị lỗi. Toàn bộ quá trình này trong suốt với người dùng cuối. Và có thể đạt được bằng việc thực hiện dư thừa kết nối. 2.4.3 Chất lượng dịch vụ Chất lượng dịch vụ là khả năng phản hồi trong các hoàn cảnh tới hạn bằng cách gán một tỉ lệ phần trăm cao của băng thông mạng và các tài nguyên giới hạn lỗi cho các ứng dụng nhạy cảm với độ trễ và giới hạn của băng thông. Ví dụ như các ứng dụng hội nghị trực tuyến, giao dịch tài chính…rất nhạy cảm với độ trễ và yêu cầu băng thông lớn đáp ứng liên tục, ổn định . Chất lượng dịch vụ bao gồm hai yếu tố: Góc trễ và Thông lượng. Góc trễ là độ trễ trong một quá trình truyền thông đang tiếp diễn và rất quan trọng với các ứng dụng âm thanh và video. Thông lượng liên quan đến tính sẵn có của băng thông thích hợp cho tất cả các ứng dụng. Trong VPN QoS đảm bảo nhiều ứng dụng khác nhau có thể chạy trên VPN. Trong cấu trúc VPN, một chính sách thường được dùng để phân loại ứng dụng, người dùng hoặc nhóm người dùng dựa vào quyền ưu tiên đã xác định. 2.4.4 Khả năng quản trị Việc kiểm soát hoàn toàn các hoạt động và tài nguyên trong mạng, cùng với việc quản trị thích hợp là rất quan trọng đặt ra với các đơn vị tổ chức có mạng kết nối toàn cầu. Hầu hết mạng của các tổ chức ngày nay kết nối với các nguồn tài nguyên của thế giới bằng sự trợ giúp của các ISP dẫn đến việc không thể kiểm soát được các đầu cuối trong mạng Intranet của một đơn vị vì phải qua mạng trung gian của các ISP. Nhờ có mạng VPN mà công việc quản trị có thể được phân chia giữa các tổ chức và ISP. 2.4.5 Khả năng tương thích VPN sử dụng mạng công cộng để kết nối các đầu cuối ở xa, các mạng trung gian này có thể dựa trên IP như Internet hoặc cũng có thể trên các công nghệ khác như FR, ATM. Kết quả là VPN có thể sử dụng tất cả các kiểu công nghệ và các giao thức cơ sở. Trong trường hợp mạng tương tác trung gian dựa trên IP, VPN phải có khả năng dùng địa chỉ IP và các ứng dụng IP, để đảm bảo khả năng tương thích với cơ sở hạ tầng trên nền IP, các phương pháp sau phải được tích hợp vào VPN. Sử dụng Gateway IP: Gateway IP dịch chuyển các các giao thức không dựa trên IP thành các giao thức IP. Các thiết bị này có thể là các thiết bị mạng chuyên dụng hoặc các phần mềm ứng dụng. Gateway IP được cài đặt trên mọi Server thường được dùng để chuyển đổi dòng lưu lượng. Sử dụng đường hầm: Tạo đường hầm là kĩ thuật đóng gói các gói dữ liệu không IP thành các gói IP để truyền trên một hạ tầng IP. Các thiết bị cuối khác khi nhân được các gói dữ liệu đã đóng gói này sẽ xử lý và loại bỏ phần tiêu đề IP để lấy lại dữ liệu gốc. Sử dụng định tuyến IP ảo (VIPR): VIPR làm việc bằng cách phân vùng logic một router vậ lý tại vị trí nhà cung cấp dịch vụ sau cùng (Thuộc ISP). Mỗi một phân vùng được cấu hình quản trị như một Router vật lý để hỗ trợ một VPN. Như vậy ta có thể hiểu mỗi một phân vùng logic được coi như một router với đầy đủ các chức năng của nó. Kết quả là, phân vùng Router logic có thể hỗ trợ nhiều giao thức và có khả năng chứa địa chỉ IP riêng. Với các công nghệ và giao thức không dựa trên IP như ATP, công nghệ đường điện thoại riêng VPT được sử dụng. VPT tương thích với nhiều giao thức và dựa trên công nghệ chuyển mạch gói. Vì vậy nó sử dụng các kênh cố định ảo PVC và kênh chuyển mạch ảo SVC cho việc truyền dữ liệu. Các PVC thường được dùng cho việ liên kết các site trong một mạng riêng hoặc Intranet. SVC thì ngược lại được dùng để liên kết các site trong một Extranet. 2.4.6 Sản phẩm công nghệ dành cho VPN Tùy vào loại VPN (truy cập từ xa hay điểm-nối-điểm), bạn sẽ cần phải cài đặt những bộ phận hợp thành nào đó để thiết lập mạng riêng ảo. Đó có thể là: Phần mềm cho desktop của máy khách dành cho người sử dụng từ xa. Phần cứng cao cấp như bộ xử lý trung tâm VPN hoặc firewall bảo mật PIX. Server VPN cao cấp dành cho dịch vụ Dial-up. NAS (máy chủ truy cập mạng) do nhà cung cấp sử dụng để phục vụ người sử dụng từ xa Mạng VPN và trung tâm quản lý. 2.5 Các kĩ thuật trong mạng VPN Hầu hết các VPN đều dựa vào kỹ thuật gọi là Tunneling để tạo ra một mạng riêng trên nền Internet. Về bản chất, đây là quá trình đặt toàn bộ gói tin vào trong một lớp header (tiêu đề) chứa thông tin định tuyến có thể truyền qua hệ thống mạng trung gian theo những "đường ống" riêng (tunnel). Khi gói tin được truyền đến đích, chúng được tách lớp header và chuyển đến các máy trạm cuối cùng cần nhận dữ liệu. Để thiết lập kết nối Tunnel, máy khách và máy chủ phải sử dụng chung một giao thức (tunnel protocol). Giao thức của gói tin bọc ngoài được cả mạng và hai điểm đầu cuối nhận biết. Hai điểm đầu cuối này được gọi là giao diện Tunnel (tunnel interface), nơi gói tin đi vào và đi ra trong mạng. Kỹ thuật Tunneling yêu cầu 3 giao thức khác nhau: Giao thức truyền tải (Carrier Protocol) là giao thức được sử dụng bởi mạng có thông tin đang đi qua. Giao thức mã hóa dữ liệu (Encapsulating Protocol) là giao thức (như GRE, IPSec, L2F, PPTP, L2TP) được bọc quanh gói dữ liệu gốc. Giao thức gói tin (Passenger Protocol) là giao thức của dữ liệu gốc được truyền đi (như IPX, NetBeui, IP). Người dùng có thể đặt một gói tin sử dụng giao thức không được hỗ trợ trên Internet (như NetBeui) bên trong một gói IP và gửi nó an toàn qua Internet. Hoặc, họ có thể đặt một gói tin dùng địa chỉ IP riêng (không định tuyến) bên trong một gói khác dùng địa chỉ IP chung (định tuyến) để mở rộng một mạng riêng trên Internet. 2.5.1 Kỹ thuật Tunneling trong mạng VPN điểm-nối điểm  Trong VPN loại này, giao thức mã hóa định tuyến GRE (Generic Routing Encapsulation) cung cấp cơ cấu "đóng gói" giao thức gói tin (Passenger Protocol) để truyền đi trên giao thức truyền tải (Carier Protocol). Nó bao gồm thông tin về loại gói tin mà bạn đang mã hóa và thông tin về kết nối giữa máy chủ với máy khách. Nhưng IPSec trong cơ chế Tunnel, thay vì dùng GRE, đôi khi lại đóng vai trò là giao thức mã hóa. IPSec hoạt động tốt trên cả hai loại mạng VPN truy cập từ xa và điểm- nối-điểm. Tất nhiên, nó phải được hỗ trợ ở cả hai giao diện Tunnel. 2.5.2 Kỹ thuật Tunneling trong mạng VPN truy cập từ xa Với loại VPN này, Tunneling thường dùng giao thức điểm-nối-điểm PPP (Point-to-Point Protocol). Là một phần của TCP/IP, PPP đóng vai trò truyền tải cho các giao thức IP khác khi liên hệ trên mạng giữa máy chủ và máy truy cập từ xa. Nói tóm lại, kỹ thuật Tunneling cho mạng VPN truy cập từ xa phụ thuộc vào PPP. Các giao thức dưới đây được thiết lập dựa trên cấu trúc cơ bản của PPP và dùng trong mạng VPN truy cập từ xa. L2F (Layer 2 Forwarding) được Cisco phát triển. L2 F dùng bất kỳ cơ chế thẩm định quyền truy cập nào được PPP hỗ trợ. PPTP (Point-to-Point Tunneling Protocol) được tập đoàn PPTP Forum phát triển. Giao thức này hỗ trợ mã hóa 40 bit và 128 bit, dùng bất kỳ cơ chế thẩm định quyền truy cập nào được PPP hỗ trợ. L2TP (Layer 2 Tunneling Protocol) là sản phẩm của sự hợp tác giữa các thành viên PPTP Forum, Cisco và IETF. Kết hợp các tính năng của cả PPTP và L2F, L2TP cũng hỗ trợ đầy đủ IPSec. L2TP có thể được sử dụng làm giao thức Tunneling cho mạng VPN điểm-nối-điểm và VPN truy cập từ xa. Trên thực tế, L2TP có thể tạo ra một tunnel giữa máy khách và router, NAS và router, 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 bước tương tự như cách trên. Tạo certificates & keys cho 3 clients Trên Linux ./build-key test1 ./build-key test2 ./build-key test3 Trên Windows: build-key test1 build-key test2 build-key test3 Tạo tham số Diffie Hellman Tham số Diffie Hellman phải được tạo ra trên máy chủ OpenVPN. Trên Linux ./build-dh Trên Windows: build-dh Đầu ra: ai:easy-rsa # ./build-dh Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .................+........................................... ...................+.............+.................+......... ...................................... Tệp keys Bảng dưới đây mô tả các tệp key, vị trí chức năng của chúng. Tên tệp Phục vụ cho Mục đích Giữ bí mật ca.crt server + all clients Root CA certificate NO ca.key key signing machine only Root CA key YES dh{n}.pem server only Diffie Hellman parameters NO server.crt server only Server Certificate NO server.key server only Server Key YES test1.crt test1 only Test1 Certificate NO test1.key test1 only Test1 Key YES test2.crt test2 only Test2 Certificate NO test2.key test2 only Test2 Key YES test3.crt test3 only Test3 Certificate NO test3.key test3 only Test3 Key YES Bước cuối cùng trong quá trình tạo key là copy tất cả các tệp tới các máy khách có yêu cầu kết nối đến server Openvpn. 4.3 Cấu hình cho máy chủ và máy khách kết nối VPN 4.3.1 Tệp cấu hình cho máy chủ sample-config-files/server.conf ################################################# # Sample OpenVPN 2.0 config file for # # multi-client server. # # # # This file is for the server side # # of a many-clients one-server # # OpenVPN configuration. # # # # OpenVPN also supports # # single-machine single-machine # # configurations (See the Examples page # # on the web site for more info). # # # # This config should work on Windows # # or Linux/BSD systems. Remember on # # Windows to quote pathnames and use # # double backslashes, e.g.: # # "C:\\Program Files\\OpenVPN\\config\\foo.key" # # # # Comments are preceded with '#' or ';' # ################################################# # Which local IP address should OpenVPN # listen on? (optional) ;local a.b.c.d # Which TCP/UDP port should OpenVPN listen on? # If you want to run multiple OpenVPN instances # on the same machine, use a different port # number for each one. You will need to # open up this port on your firewall. port 1194 # TCP or UDP server? ;proto tcp proto udp # "dev tun" will create a routed IP tunnel, # "dev tap" will create an ethernet tunnel. # Use "dev tap0" if you are ethernet bridging # and have precreated a tap0 virtual interface # and bridged it with your ethernet interface. # If you want to control access policies # over the VPN, you must create firewall # rules for the the TUN/TAP interface. # On non-Windows systems, you can give # an explicit unit number, such as tun0. # On Windows, use "dev-node" for this. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap dev tun # Windows needs the TAP-Win32 adapter name # from the Network Connections panel if you # have more than one. On XP SP2 or higher, # you may need to selectively disable the # Windows firewall for the TAP adapter. # Non-Windows systems usually don't need this. ;dev-node MyTap # SSL/TLS root certificate (ca), certificate # (cert), and private key (key). Each client # and the server must have their own cert and # key file. The server and all clients will # use the same ca file. # # See the "easy-rsa" directory for a series # of scripts for generating RSA certificates # and private keys. Remember to use # a unique Common Name for the server # and each of the client certificates. # # Any X509 key management system can be used. # OpenVPN can also use a PKCS #12 formatted key file # (see "pkcs12" directive in man page). ca ca.crt cert server.crt key server.key # This file should be kept secret # Diffie hellman parameters. # Generate your own with: # openssl dhparam -out dh1024.pem 1024 # Substitute 2048 for 1024 if you are using # 2048 bit keys. dh dh1024.pem # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, # the rest will be made available to clients. # Each client will be able to reach the server # on 10.8.0.1. Comment this line out if you are # ethernet bridging. See the man page for more info. server 10.8.0.0 255.255.255.0 # Maintain a record of client virtual IP address # associations in this file. If OpenVPN goes down or # is restarted, reconnecting clients can be assigned # the same virtual IP address from the pool that was # previously assigned. ifconfig-pool-persist ipp.txt # Configure server mode for ethernet bridging. # You must first use your OS's bridging capability # to bridge the TAP interface with the ethernet # NIC interface. Then you must manually set the # IP/netmask on the bridge interface, here we # assume 10.8.0.4/255.255.255.0. Finally we # must set aside an IP range in this subnet # (start=10.8.0.50 end=10.8.0.100) to allocate # to connecting clients. Leave this line commented # out unless you are ethernet bridging. ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 # Push routes to the client to allow it # to reach other private subnets behind # the server. Remember that these # private subnets will also need # to know to route the OpenVPN client # address pool (10.8.0.0/255.255.255.0) # back to the OpenVPN server. ;push "route 192.168.10.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" # To assign specific IP addresses to specific # clients or if a connecting client has a private # subnet behind it that should also have VPN access, # use the subdirectory "ccd" for client-specific # configuration files (see man page for more info). # EXAMPLE: Suppose the client # having the certificate common name "Thelonious" # also has a small subnet behind his connecting # machine, such as 192.168.40.128/255.255.255.248. # First, uncomment out these lines: ;client-config-dir ccd ;route 192.168.40.128 255.255.255.248 # Then create a file ccd/Thelonious with this line: # iroute 192.168.40.128 255.255.255.248 # This will allow Thelonious' private subnet to # access the VPN. This example will only work # if you are routing, not bridging, i.e. you are # using "dev tun" and "server" directives. # EXAMPLE: Suppose you want to give # Thelonious a fixed VPN IP address of 10.9.0.1. # First uncomment out these lines: ;client-config-dir ccd ;route 10.9.0.0 255.255.255.252 # Then add this line to ccd/Thelonious: # ifconfig-push 10.9.0.1 10.9.0.2 # Suppose that you want to enable different # firewall access policies for different groups # of clients. There are two methods: # (1) Run multiple OpenVPN daemons, one for each # group, and firewall the TUN/TAP interface # for each group/daemon appropriately. # (2) (Advanced) Create a script to dynamically # modify the firewall in response to access # from different clients. See man # page for more info on learn-address script. ;learn-address ./script # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # the TUN/TAP interface to the internet in # order for this to work properly). # CAVEAT: May break client's network config if # client's local DHCP server packets get routed # through the tunnel. Solution: make sure # client's local DHCP server is reachable via # a more specific route than the default route # of 0.0.0.0/0.0.0.0. ;push "redirect-gateway" # Certain Windows-specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # ;push "dhcp-option DNS 10.8.0.1" ;push "dhcp-option WINS 10.8.0.1" # Uncomment this directive to allow different # clients to be able to "see" each other. # By default, clients will only see the server. # To force clients to only see the server, you # will also need to appropriately firewall the # server's TUN/TAP interface. ;client-to-client # Uncomment this directive if multiple clients # might connect with the same certificate/key # files or common names. This is recommended # only for testing purposes. For production use, # each client should have its own certificate/key # pair. # # IF YOU HAVE NOT GENERATED INDIVIDUAL # CERTIFICATE/KEY PAIRS FOR EACH CLIENT, # EACH HAVING ITS OWN UNIQUE "COMMON NAME", # UNCOMMENT THIS LINE OUT. ;duplicate-cn # The keepalive directive causes ping-like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. keepalive 10 120 # For extra security beyond that provided # by SSL/TLS, create an "HMAC firewall" # to help block DoS attacks and UDP port flooding. # # Generate with: # openvpn --genkey --secret ta.key # # The server and each client must have # a copy of this key. # The second parameter should be '0' # on the server and '1' on the clients. ;tls-auth ta.key 0 # This file is secret # Select a cryptographic cipher. # This config item must be copied to # the client config file as well. ;cipher BF-CBC # Blowfish (default) ;cipher AES-128-CBC # AES ;cipher DES-EDE3-CBC # Triple-DES # Enable compression on the VPN link. # If you enable it here, you must also # enable it in the client config file. comp-lzo # The maximum number of concurrently connected # clients we want to allow. ;max-clients 100 # It's a good idea to reduce the OpenVPN # daemon's privileges after initialization. # # You can uncomment this out on # non-Windows systems. ;user nobody ;group nobody # The persist options will try to avoid # accessing certain resources on restart # that may no longer be accessible because # of the privilege downgrade. persist-key persist-tun # Output a short status file showing # current connections, truncated # and rewritten every minute. status openvpn-status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log-append to override this default. # "log" will truncate the log file on OpenVPN startup, # while "log-append" will append to it. Use one # or the other (but not both). ;log openvpn.log ;log-append openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 # Silence repeating messages. At most 20 # sequential messages of the same message # category will be output to the log. ;mute 20 4.3.2 Tệp cấu hình cho máy khách sample-config-files/client.conf ############################################## # Sample client-side OpenVPN 2.0 config file # # for connecting to multi-client server. # # # # This configuration can be used by multiple # # clients, however each client should have # # its own cert and key files. # # # # On Windows, you might want to rename this # # file so it has a .ovpn extension # ############################################## # Specify that we are a client and that we # will be pulling certain config file directives # from the server. client # Use the same setting as you are using on # the server. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. ;dev tap dev tun # Windows needs the TAP-Win32 adapter name # from the Network Connections panel # if you have more than one. On XP SP2, # you may need to disable the firewall # for the TAP adapter. ;dev-node MyTap # Are we connecting to a TCP or # UDP server? Use the same setting as # on the server. ;proto tcp proto udp # The hostname/IP and port of the server. # You can have multiple remote entries # to load balance between the servers. remote my-server-1 1194 ;remote my-server-2 1194 # Choose a random host from the remote # list for load-balancing. Otherwise # try hosts in the order specified. ;remote-random # Keep trying indefinitely to resolve the # host name of the OpenVPN server. Very useful # on machines which are not permanently connected # to the internet such as laptops. resolv-retry infinite # Most clients don't need to bind to # a specific local port number. nobind # Downgrade privileges after initialization (non-Windows only) ;user nobody ;group nobody # Try to preserve some state across restarts. persist-key persist-tun # If you are connecting through an # HTTP proxy to reach the actual OpenVPN # server, put the proxy server/IP and # port number here. See the man page # if your proxy server requires # authentication. ;http-proxy-retry # retry on connection failures ;http-proxy [proxy server] [proxy port #] # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. ;mute-replay-warnings # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate .crt/.key file pair # for each client. A single ca # file can be used for all clients. ca ca.crt cert client.crt key client.key # Verify server certificate by checking # that the certicate has the nsCertType # field set to "server". This is an # important precaution to protect against # a potential attack discussed here: # # # To use this feature, you will need to generate # your server certificates with the nsCertType # field set to "server". The build-key-server # script in the easy-rsa folder will do this. ;ns-cert-type server # If a tls-auth key is used on the server # then every client must also have the key. ;tls-auth ta.key 1 # Select a cryptographic cipher. # If the cipher option is used on the server # then you must also specify it here. ;cipher x # Enable compression on the VPN link. # Don't enable this unless it is also # enabled in the server config file. comp-lzo # Set log file verbosity. verb 3 # Silence repeating messages ;mute 20 4.3.3 Kết quả: Kết quả trên server OpenVPN. Kết quả phía client: Phần 5: Kết luận Mục đích mong muốn của công nghệ VPN là việc sử dụng Internet và tính phổ cập của nó. Tuy nhiên, do Internet là nguồn thông tin công cộng nên có thể được truy cập từ bất kỳ ai, bất kỳ lúc nào, bất kỳ nơi đâu, việc trao đổi thông tin có thể bị nghe trộm dễ dàng, sự truy cập bất hợp pháp và phá hoại dữ liệu khi trao đổi dữ liệu. Mục đích chính của VPN là cung cấp bảo mật, tính hiệu quả và độ tin cậy trong mạng trong khi vẫn đảm bảo cân bằng giá thành cho toàn bộ quá trình xây dựng mạng. VPN được hiểu là phần mở rộng của một mạng Intranet được kết nối thông qua mạng công cộng nhằm bảo đảm an toàn và tăng hiệu quả giá thành kết nối giữa hai đầu nối. Cơ chế và độ giới hạng bảo mật tinh vi cũng được sử dụng để bảo đảm tính an toàn cho việc trao đổi những dữ liệu dễ bị đánh cắp thông qua một môi trường không an toàn. 5.1.1 Thuận lợi Giãm thiểu chi phí triển khai : Chi phí cho VPNs ít hơn đáng kể so với cách giải quyết truyền thống Giãm chi phí quản lý. Cải thiện kết nối. An toàn trong giao dịch. Hiệu quả về băng thông. Enhanced scalability.  5.1.2 Bất lợi Phụ thuộc trong môi trường Internet. Thiếu sự hổ trợ cho một số giao thức kế thừa.