s8001.info forum.php,Open××× HowTo文档

Open××× HowTo文档

In this section we will generate a master CA certificate/key, a server certificate/key, and certificates/keys for 3 separate clients.

If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the /usr/share/doc/packages/open*** or/etc/open***, before any edits, so that future Open××× package upgrades won't overwrite your modifications). If you installed from a .tar.gz file, the easy-rsa directory will be in the top level directory of the expanded source tree.

\\Program Files\\Open×××\\easy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting vars.bat and openssl.cnf files):Now edit the vars.bat on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don't leave any of these parameters blank.

. ./vars

./clean-all

./build-ca

vars

clean-all

build-ca

build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive

keys

subdirectory. Here is an explanation of the relevant files:FilenameNeeded ByPurposeSecret

ca.crtRoot CA certificatekey signing machine onlyYES

dh{n}.pemDiffie Hellman parametersserver onlyNO

server.keyServer Keyclient1 onlyNO

client1.keyClient1 Keyclient2 onlyNO

client2.keyClient2 Keyclient3 onlyNO

client3.keyClient3 Key.key file leave the hard drive of the machine on which it was generated.

Getting the sample config files

It's best to use the Open××× sample configuration files as a starting point for your own configuration. These files can also be found inthe sample-config-files directory in /usr/share/doc/open***-2.0 if you installed from an RPM package

server.conf andserver.o*** and Editing the server configuration file

The sample server configuration file is an ideal starting point for an Open××× server configuration. It will create a ××× using a virtual UDP port 1194 (Open×××'s official port number), and distribute virtual addresses to connecting clients from the ca, key, and PKI section above.

At this point, the server configuration file is usable, however you still might want to customize it further:

If you are using server-bridge

and server andproto tcpinstead of 10.8.0.0/24, you should modify the client-to-client directive if you would like connecting clients to be able to reach each other over the ×××. By default, clients will only be able to reach the server.If you are using Linux, BSD, or a Unix-like OS, you can improve security by uncommenting out thegroup nobody directives.

If you want to run multiple Open××× instances on the same machine, each using a different configuration file, it is possible if you:Use a different Start Menu -> All Programs -> Open××× -> Add a new TAP-Win32 virtual ethernet adapter.

If you are running multiple Open××× instances out of the same directory, make sure to edit directives which create output files so that multiple instances do not overwrite each other's output files. These directives include log-append, ifconfig-pool-persist.

client.conf on Linux/BSD/Unix or make sure that the TUN/TAP interface is not firewalled.

To simplify troubleshooting, it's best to initially start the Open××× server from the command line (or right-click on theopen*** [server config file]

A normal server startup should look like this (output will vary across platforms):

Sun Feb  6 20:46:38 2005 Open××× 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb  5 2005

Sun Feb  6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key

Sun Feb  6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]

Sun Feb  6 20:46:38 2005 TUN/TAP device tun1 opened

Sun Feb  6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500

Sun Feb  6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2

Sun Feb  6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]

Sun Feb  6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194

Sun Feb  6 20:46:38 2005 UDPv4 link remote: [undef]

Sun Feb  6 20:46:38 2005 MULTI: multi_init called, r=256 v=256

Sun Feb  6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62

Sun Feb  6 20:46:38 2005 IFCONFIG POOL LIST

Sun Feb  6 20:46:38 2005 Initialization Sequence Completed

Starting the client

As in the server configuration, it's best to initially start the Open××× server from the command line (or on Windows, by right-clicking on theopen*** [client config file]

A normal client startup on Windows will look similar to the server output above, and should end with thedev tun in the server config file), try:dev tap in the server config file), try to ping the IP address of a machine on the server's ethernet subnet.

If the ping succeeds, congratulations! You now have a functioning ×××.

for additional troubleshooting information.

Linux

If you install Open××× via an RPM package on Linux, the installer will set up an .conf configuration files in Windows

The Windows installer will set up a Service Wrapper, but leave it turned off by default. To activate it, go to Control Panel / Administrative Tools / Services, select the Open××× service, right-click on properties, and set the Startup Type to Automatic. This will configure the service for automatic start on the next reboot.

When started, the Open××× Service Wrapper will scan the .o*** configuration files, starting a separate Open××× process on each file.

Running on Linux/BSD/Unix

Open××× accepts several signals:

SIGHUP -- Hard restart

SIGTERM, writepid directive to write the Open××× daemon's PID to a file, so that you know where to send the signal (if you are starting open*** with an --writepid directive on the Running on Windows as a GUI

file) and selecting "Start Open××× on this config file".

Once running in this fashion, several keyboard commands are available:

F2 -- Show connection statistics

F4 -- Exit

10.66.0.0/24

and the ××× IP address pool uses server directive in the Open××× server configuration file.

First, you must 10.66.0.0/24 subnet to ××× clients as being accessible through the ×××. This can easily be done with the following server-side config file directive:10.8.0.0/24) to the Open××× server (this is only necessary if the Open××× server and the LAN gateway are different machines).

Make sure that you've enabled TUN/TAP forwarding on the Open××× server machine.

ethernet bridging is that you get this for free without needing any additional configuration.

192.168.4.0/24 subnet, and that the ××× client is using a certificate with a common name of client2. Our goal is to set up the ××× so that any machine on the client LAN can communicate with any machine on the server LAN through the ×××.

Before setup, there are some basic prerequisites which must be followed:The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the ××× by the server or any other client sites which are using the same subnet. Every subnet which is joined to the ××× via routing must be unique.

The client must have a unique Common Name in its certificate ("client2" in our example), and theIP and

In the above directive, /etc/open*** and on Windows it is usually client2 in theiroute 192.168.4.0 255.255.255.0

This will tell the Open××× server that the 192.168.4.0/24 subnet should be routed to ccd/client2 file):route and route controls the routing from the kernel to the Open××× server (via the TUN interface) while client-to-client

push "route 192.168.4.0 255.255.255.0"

This will cause the Open××× server to isthe gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the Open××× server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the ××× (when the ××× server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all ××× subnets to the ××× server machine.

Similarly, if the client machine running Open××× is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the ××× to the Open××× client machine.

System administrators -- full access to all machines on the networkContractors -- access to a special server only

The basic approach we will take is (a) segregate each user class into its own virtual IP address range, and (b) control access to machines by setting up firewall rules which key off the client's virtual IP address.

In our example, suppose that we have a variable number of employees, but only one system administrator, and two contractors. Our IP allocation approach will be to put all employees into an IP address pool, and then allocate fixed IP addresses for the system administrator and contractors.

Note that one of the prerequisites of this example is that you have a software firewall running on the Open××× server machine which gives you the ability to define specific firewall rules. For our example, we will assume the firewall is Linux

10.8.0.0/24[variable]System AdministratorsEntire 10.66.4.0/24 subnet10.8.2.0/24contractor1, contracter2

Next, let's translate this map into an Open××× server configuration. First of all, make sure you've followed the steps tun

interface, so that we will be able to refer to it later in our firewall rules:server 10.8.0.0 255.255.255.0

Add routes for the System Administrator and Contractor IP ranges:client-config-dir ccd

Now place special configuration files in the ccd/sysadmin1

ccd/contractor1

ccd/contractor2

ifconfig-push addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Win32 driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]

[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]

[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]

[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]

[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]

[101,102] [105,106] [109,110] [113,114] [117,118]

[121,122] [125,126] [129,130] [133,134] [137,138]

[141,142] [145,146] [149,150] [153,154] [157,158]

[161,162] [165,166] [169,170] [173,174] [177,178]

[181,182] [185,186] [189,190] [193,194] [197,198]

[201,202] [205,206] [209,210] [213,214] [217,218]

[221,222] [225,226] [229,230] [233,234] [237,238]

[241,242] [245,246] [249,250] [253,254]

iptables syntax:This will tell the Open××× server to validate the username/password entered by clients using the open***-auth-pam plugin, because it has several advantages over the About dual-factor authentication

This standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced "crypto-key" and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token.

Source: RSA Security Inc.

You should have Open××× 2.1 or above in order to use the PKCS#11 features.

$ open*** --show-pkcs11-ids /usr/lib/pkcs11/

The following objects are available for use.

Each object shown below may be used as parameter to

--pkcs11-id option please remember to use single quote mark.

Certificate

DN:             /CN=User1

Serial:         490B82C4000000000075

Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

pkcs11-id option using single quote marks.

A typical set of Open××× options for PKCS#11

Advanced Open××× options for PKCS#11

pkcs11-id option, and use the management interface in order to query passwords. The daemon will resume into hold state on the event when token cannot be accessed. The token will be used for 300 seconds after which the password will be re-queried, session will disconnect if management session disconnects.PKCS#11 implementation considerations

Many PKCS#11 providers make use of threads, in order to avoid problems caused by implementation of LinuxThreads (setuid, chroot), it is highly recommend to upgrade to Native POSIX Thread Library (NPTL) enabled glibc if you intend to use PKCS#11.

option) works well as long as you don't run Open××× as a service. If you wish to run Open××× in an administrative environment using a service, the implementation will not work with most smart cards because of the following reasons:

Most smart card providers do not load certificates into the local machine store, so the implementation will be unable to access the user certificate.

If the Open××× client is running as a service without direct interaction with the end-user, the service cannot query the user to provide a password for the smart card, causing the password-verification process on the smart card to fail.

Using the PKCS#11 interface, you can use smart cards with Open××× in any implementation, since PKCS#11 does not access Microsoft stores and does not necessarily require direct interaction with the end-user.

Overview

By default, when an Open××× client is active, only network traffic to and from the Open××× server site will pass over the ×××. General web browsing, for example, will be accomplished with direct connections that bypass the ×××.

In certain cases this behavior might not be desirable -- you might want a ××× client to tunnel all network traffic through the ×××, including general internet web browsing. While this type of ××× configuration will exact a performance penalty on the client, it gives the ××× administrator more control over security policies when a client is simultaneously connected to both the public internet and the ××× at the same time.

push "redirect-gateway def1"

If your ××× setup is over a wireless network, where all clients and the server are on the same wireless subnet, add thepush "redirect-gateway local def1"

Pushing theiptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

10.8.0.0/24 (taken from the eth0.

Whenpush "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

Caveats

Redirecting all network traffic through the ××× is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:Many Open××× client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The Issues exist with respect to pushing DNS addresses to Windows clients.

Web browsing performance on the client will be noticably slower.

For more information on the mechanics of the manual page.

dyndns.org.

The next step is to set up a mechanism so that every time the server's IP address changes, the dynamic DNS name will be quickly updated with the new IP address, allowing clients to find the server at its new IP address. There are two basic ways to accomplish this:Use a NAT router appliance with dynamic DNS support (such as the ddclient to update the dynamic DNS address whenever the server IP address changes. This setup is ideal when the machine running Open××× has multiple NICs and is acting as a site-wide firewall/gateway. To implement this setup, you need to set up a script to be run by your DHCP client software every time an IP address change occurs. This script should (a) run remote directive which references a dynamic DNS name. The usual chain of events is that (a) the Open××× client fails to receive timely keepalive messages from the server's old IP address, triggering a restart, and (b) the restart causes the DNS name in the FAQ.

Connecting to an Open××× server via an HTTP proxy.

Open××× supports connections through an HTTP proxy, with the following authentication modes:No proxy authentication

Basic proxy authentication

NTLM proxy authentication

First of all, HTTP proxy usage requires that you use TCP as the tunnel carrier protocol. So add the following to both client and server configurations:proto udp lines in the config files are deleted.

Next, add the manual page for a full description of this directive).

For example, suppose you have an HTTP proxy server on the client LAN at 1080. Add this to the client config:http-proxy 192.168.4.1 1080 stdin basic

Suppose the HTTP proxy requires NTLM authentication:stdin with a filename, and place the username on line 1 of this file and the password on line 2.

dev tun tunnel. If you are ethernet bridging (dev tap), you probably don't need to follow these instructions, as Open××× clients should see server-side machines in their network neighborhood.

For this example, we will assume that:the server-side LAN uses a subnet of 10.8.0.0/24 (as cited in the 10.66.0.4, and

the Samba server has already been configured and is reachable from the local LAN.

If the Samba and Open××× servers are running on different machines, make sure you've followed the section on smb.conf). Make sure the 10.8.0.0/24 subnet to connect. For example:interfaces directive in the 10.8.0.0/24:

\\\\10.8.0.1\\\\sharename

If the Samba and Open××× servers are on different machines, use folder name:net use z: \\\\10.66.0.4\\sharename /USER:myusername

Client

The Open××× client configuration can refer to multiple servers for load balancing and failover. For example:remote-random

If you would also like DNS resolution failures to cause the Open××× client to move to the next server in the list, add the following:60 parameter tells the Open××× client to try resolving each remote smp-server1.mydomain 8000

remote smp-server1.mydomain 8001

remote smp-server2.mydomain 8000

remote smp-server2.mydomain 8001

If your servers are multi-processor machines, running multiple Open××× daemons on each server can be advantageous from a performance standpoint.

Open××× also supports the A records in the zone configuration for the domain. In this case, the Open××× client will randomly choose one of the Server

The simplest approach to a load-balanced/failover configuration on the server is to use equivalent configuration files on each server in the cluster, except use a different virtual IP address pool for each server. For example:

server 10.8.0.0 255.255.255.0

server 10.8.1.0 255.255.255.0

server 10.8.2.0 255.255.255.0

tls-auth

The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:DoS attacks or port flooding on the Open××× UDP port.

Port scanning to determine which server UDP ports are in a listening state.

Buffer overflow vulnerabilities in the SSL/TLS implementation.

SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:ta.key. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA .crt files.

In the server configuration, add:tls-auth ta.key 1

proto udp

user nobody

group nobody

dev tunX/tapX

iproute /usr/local/sbin/unpriv-ipPlease note that you must select constant X and specify tun or tap not both.

As root add persistant interface, and permit user and/or group to manage it, the following create tunX (replace with your own) and allow user1 and group users to access it.chroot (non-Windows only)

The chroot jail, where the daemon would not be able to access any part of the host system's filesystem except for the specific directory given as a parameter to the directive. For example,jail subdirectory on initialization, and would then reorient its root filesystem to this directory so that it would be impossible thereafter for the daemon to access any files outside of chroot reorients the filesystem (from the perspective of the daemon only), it is necessary to place any files which Open××× might need after initialization in the Example

As an example, we will revoke the easy-rsa directory as you did in the "key generation" section above. On Linux/BSD/Unix:vars

revoke-full client2

You should see output similar to this:Using configuration from /root/open***/20/open***/tmp/easy-rsa/openssl.cnf

DEBUG[load_index]: unique_subject = \"yes\"

Revoking Certificate 04.

Data Base Updated

Using configuration from /root/open***/20/open***/tmp/easy-rsa/openssl.cnf

DEBUG[load_index]: unique_subject = \"yes\"

client2.crt: /C=KG/ST=NA/O=Open×××-TEST/CN=client2/emailAddress=me@myhost.mydomain

error 23 at 0 depth lookup:certificate revoked

revoke-full script will generate a CRL (certificate revocation list) file called keyssubdirectory. The file should be copied to a directory where the Open××× server can access it, then CRL verification should be enabled in the server configuration:

CRL Notes

When the management interface and explicitly kill the specific client instance object on the server without disturbing other clients.

While the clients shouldn't be accepting direct connections from other clients in the first place.

The CRL file is not secret, and should be made world-readable so that the Open××× daemon can read it after root privileges have been dropped.

If you are using the 

Important Note on possible "Man-in-the-Middle" attack if clients do not verify the certificate of the server they are connecting to.

To avoid a possible Man-in-the-Middle attack where an authorized client tries to connect to another client by impersonating the server, make sure to enforce some kind of server certificate verification by clients. There are currently five different ways of accomplishing this, listed in the order of preference:ModeExtended key usageClientTLS Web Client AuthenticationkeyAgreementdigitalSignature, keyAgreementServerTLS Web Server AuthenticationdigitalSignature, keyAgreement

You can build your server certificates with the easy-rsadocumentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:[Open××× 2.0 and below] Build your server certificates with the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by settingns-cert-type server

This will block clients from connecting to any server which lacks the ca file in the Open××× configuration file.

Use the tls-verify script or plugin to accept/reject the server connection based on a custom test of the server certificate's embedded X509 subject details.

Sign server certificates with one CA and client certificates with a different CA. The client configuration ca directive should reference the client-signing CA file.