查看文章 |
原文地址: http://www.natecarlson.com/linux/ipsec-l2tp.php This document describes how to set up a VPN with Openswan combined with L2TPD. This provides for a more user-friendly experience than a standard IPSec VPN on many client operating systems. Note that for most site<->site VPN's, you will still want straight IPSec. If you're not sure if IPSec is right for you, I have written a quick document about some of the various types of VPN available under Linux. It is available at: http://www.natecarlson.com/linux/linux-vpn.php. I hope this helps clear up some questions. This page is heavily based on my basic IPSec configuration page, located at http://www.natecarlson.com/linux/ipsec-x509.php. The l2tpd configuration side is based on Jacco de Leeuw's page, which is the definitive source for anything related to Openswan and L2TP. I'm just trying to simplify things for the average Linux geek -- if you need more detailed information, or information about any clients other than Windows, check out his page. If you have any difficulties with this process, please e-mail the Openswan mailing list, or if you can't get help from there, e-mail me at: ipsec@natecarlson.com. All of my examples on this page are based on a Debian Sarge system, since all the packages required are readily available. Most examples are readily portable to other distributions; you will just need to get the required software for that distribution. NOTE: I do occasionally post notes about new VPN options and such on my blog; see the VPN category at: http://www.natecarlson.com/blog/category/geek-stuff/vpn. Contents: If you find this page helpful, and would like to help keep me motivated to update this site, feel free to donate with the button below. Any little bit helps!
Setting up your Certificate Authority Now, on to the good stuff - let's start setting up our own CA. 1) Install openssl. On Debian, 'apt-get install openssl' will take care of this. Debian: /etc/ssl/openssl.cnf Open this file in your favorite editor. We will need to change the following options: 'default_days': This is the length of time, in days, that your certificates will be valid for, and defaults to 365 days, or 1 year. I recommend setting this to '3650', as that will give you 10 years of validity on your certificates. Since this is for internal use, I am ok with the security ramifications of having a certificate valid for a long time - if you lose it or whatnot, you can revoke it without a problem. '[ req_distinguished_name ]' section: You don't really *need* to change the options below req_distinguished_name; they just set the default options (such as location, company name, etc) for certificate generation. I find it's easier to set them here than re-type them for every certificate. 3) Create a directory to house your CA. I generally use something like /var/sslca; you can really use whatever you want. Change the permissions of the directory to 700, so that people will not be able to access the private keys who aren't supposed to. 4) Find the command 'CA.sh' (some distributions rename it to just 'CA'; don't ask me why.) Locations on various distributions: Debian: /usr/lib/ssl/misc/CA.sh Edit this file, and change the line that says 'DAYS="days 365"' to a very high number (this sets how long the certificate authority's certificate is valid.) Be sure that this number is higher than the number is Step 1; or else Windows may not accept your certificates. Note that if this number is too high, it can cause problems - I generally set it for 15-20 years. 5) Run the command 'CA.sh -newca'. Follow the prompts, as below. Example input is in red, and my comments are in blue. Be sure to not use any non-alphanumeric characters, such as dashes, commas, plus signs, etc. These characters may make things more difficult for you. nate@example:~/sslca$ /usr/lib/ssl/misc/CA.sh -newca Let's also generate a crl file, which you'll need on your gateway boxes: That's it, you now have your own certificate authority that you can use to generate certificates. Generating a Certificate Again, we'll be using the CA.sh script. Except this time, instead of telling it to create a new Certificate Authority, we're telling it to request, then sign a certificate: nate@example:~/sslca$ /usr/lib/ssl/misc/CA.sh -newreq Please enter the following 'extra' attributes What we just did is generate a Certificate Request - this is the same type of request that you would send to Thawte or Verisign to get a generally-accepted SSL certificate. For our uses, however, we'll sign it with our own CA: nate@example:~/sslca$ /usr/lib/ssl/misc/CA.sh -sign 1 out of 1 certificate requests certified, commit? [y/n]y(enter) Next, move the output files to names that make a bit more sense for future reference. nate@example:~/sslca$ mv newcert.pem host.example.com.pem That's all that's required for Openswan boxes - you'll need these two files, along with the file 'cacert.pem' from the 'demoCA' directory, and the 'crl.pem' file you generated earlier. Installing Openswan If you are running Debian, there are binary packages available in Sarge and above. For RedHat or Fedora, ATrpms provides binary packages. I can't vouch for the quality of these packages, but I do know many people have used them with good success. See http://atrpms.net. If you want to build it from scratch, you can download it from http://www.openswan.org/code, and follow the installation directions included with the package. I recommend the most recent version in the 2.2 series, until 2.3.1 is available - 2.3.0 has some critical bugs. You now have two options for which IPSec stack you want to install in the kernel - you can either use Openswan's IPSec stack (KLIPS), or use the built-in IPSec stack in the 2.6 kernel (26sec). If you are running on a stock 2.4 kernel, the only option is KLIPS. You'll need to patch NAT Traversal support into your kernel (if you intend to use it), and build the ipsec.o kernel module. Otherwise, if you are using a 2.6 kernel or a 2.4 kernel with backported 26sec support (such as the kernel Debian provides), you don't need to touch the kernel-land at all - you can just install the Openswan user-land utilities and go. With Openswan 2.3.1, we will also have support for KLIPS on 2.6, but without NAT Traversal support (until someone gets around to fixing it!) My current recommendation (and my only tested configuration) is to use a stock kernel, patched with NAT Traversal and with KLIPS added. If you bug me, I'll probably provide patched up Debian packages. :) I have heard stories about l2tpd not working with the kernel stack. Once you've selected and set up your IPSec stack and installed the user-land programs, you're ready to move on to configuring Openswan. Installing the Certificate on your Gateway 1) Install the files in their proper locations (if installing to a remote machine, please be sure to copy the files in a secure manner): $ cp /var/sslca/host.example.com.key /etc/ipsec.d/private
: RSA host.example.com.key "password" The password above should be the password you entered while generating the SSL certificate. 2) Configuring ipsec.conf version 2.0 config setup conn %default conn roadwarrior-net conn roadwarrior-all conn roadwarrior conn roadwarrior-l2tp conn roadwarrior-l2tp-oldwin conn block conn private conn private-or-clear conn clear-or-private conn clear conn packetdefault The 'roadwarrior-*' lines allow roadwarriors (IE, regular IPSec clients) to connect to your IPSec gateway itself, the network behind it, and to tunnel all traffic to the 'net at large through it. The roadwarrior-l2tp entries allow both older and newer versions of Windows to connect to an l2tpd daemon running on the same host as your Openswan gateway. Anyone will a valid certificate signed by your CA will be able to connect to your gateway. This configuration also includes NAT Traversal configuration that will allow anyone a host behind a NAT gateway using RFC1918 private addresses (defined in the 'virtual_private' line) to connect. The 'auto=ignore' lines are there to disable Opportunistic Encryption, which can cause problems if not configured properly. Configuring l2tpd on the Gateway Machine 1) Install l2tpd. On Debian (assuming you have 'unstable' in your sources.list), you can just 'apt-get install l2tpd'; on other distributions, you can find a binary distribution, or grab the source from http://www.l2tpd.org. If building from source, you proably want to build from the CVS version. 2) Configure l2tpd. On Debian, you'll need to edit the file '/etc/l2tpd/l2tpd.conf'. Here's an example: [global] You'll need to change the IP range to a block of unused addresses on your internal network that you would like to hand out to L2TP clients. The 'Local IP' should be the local IP address of your box. The 'pppoptfile' specifies which options file to use. 3) Configure your PPP options. From the example above, this is located at /etc/ppp/options.l2tpd.lns.
You'll need to change ms-dns and ms-wins to match your internal DNS and WINS servers. I've got the MTU set rather low so that packets won't be fragmented - if you leave the MTU at 1500, you may find that things like SMB shares don't work properly. 4) Set up your authentication file. This is at /etc/ppp/chap-secrets.
You can define multiple users with this method. If it's not obvious, 'username' is the username that will be used for authentication, and 'password' is the password. If you'd like to give a user a static IP, you can specify it in the fourth column, 'IP Addresses'. That's it for the server side! Just start l2tpd with '/etc/init.d/l2tpd start', and you're set to go on to the clients. Client Setup: Windows XP This section covers configuring your Windows XP client to connect to the server with L2TP over IPsec. First of all, please ensure that Windows XP SP2, or the NAT-Traversal patches are installed. This will help your ability to connect while behind a NAT gateway and such. Also, be sure to be logged in as a user with administrator privileges. 1) The first step is to import a certificate on your Windows box. For sake of simplicity, I'll have you import the certificate using Xelerance's 'certimport.exe' tool. - Download certimport from ftp://ftp.openswan.org/openswan/windows/certimport/, extract it, and install certimport.exe somewhere easy to get at. certimport.exe -p password certificate.p12 2) Set up your L2TP over IPSec connection, as follows. - Start->Settings->Network Connections 3) Connect! The VPN should come up nicely - if not, check the Linux side for errors. Client Setup: Real IPSec Clients I'm just covering setting up L2TP over IPSec connections on this page, but if you would like to set up Openswan or Windows IPSec clients, please see my other page at http://www.natecarlson.com/linux/ipsec-x509.php. Note that the server configuration above is alreadty set up to accept normal IPSec connections along with the L2TP connections. |