Changes between Version 2 and Version 3 of HOWTO
- Timestamp:
- 07/25/14 07:41:38 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
HOWTO
v2 v3 75 75 == Mac OS X Notes == 76 76 77 Angelo Laub and Dirk Theisen have developed an OpenVPN GUI for OS X. 78 Other OSes 79 80 Some notes are available in the INSTALL file for specific OSes. In general, the 81 82 ./configure 83 make 84 make install 85 77 Angelo Laub and Dirk Theisen have developed an [http://code.google.com/p/tunnelblick/ OpenVPN GUI for OS X]. 78 79 == Other OSes == 80 81 Some notes are available in the [https://github.com/OpenVPN/openvpn/blob/master/INSTALL INSTALL] file for specific OSes. In general, the 82 {{{ 83 ./configure 84 make 85 make install 86 }}} 86 87 method can be used, or you can search for an OpenVPN port or package which is specific to your OS/distribution. 87 88 88 Determining whether to use a routed or bridged VPN 89 90 See FAQ for an overview of Routing vs. Ethernet Bridging. See also the OpenVPN Ethernet Bridging page for more notes and details on bridging.89 = Determining whether to use a routed or bridged VPN = 90 91 See the documentation [wiki:WikiStart front page] and [wiki:FAQ FAQ] for an overview of Routing vs. Ethernet Bridging. 91 92 92 93 Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis. … … 94 95 I would recommend using routing unless you need a specific feature which requires bridging, such as: 95 96 96 97 98 99 100 Numbering private subnets 97 * the VPN needs to be able to handle non-IP protocols such as IPX, 98 * you are running applications over the VPN which rely on network broadcasts (such as LAN games), or 99 * you would like to allow browsing of Windows file shares across the VPN without setting up a Samba or WINS server. 100 101 = Numbering private subnets = 101 102 102 103 Setting up a VPN often entails linking together private subnets from different locations. 103 104 104 105 The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets (codified in RFC 1918): 105 10.0.0.0 10.255.255.255 (10/8 prefix) 106 172.16.0.0 172.31.255.255 (172.16/12 prefix) 107 192.168.0.0 192.168.255.255 (192.168/16 prefix) 106 107 ||10.0.0.0||10.255.255.255||(10/8 prefix)|| 108 ||172.16.0.0||172.31.255.255||(172.16/12 prefix)|| 109 ||192.168.0.0||192.168.255.255||(192.168/16 prefix)|| 108 110 109 111 While addresses from these netblocks should normally be used in VPN configurations, it's important to select addresses that minimize the probability of IP address or subnet conflicts. The types of conflicts that need to be avoided are: 110 112 111 112 113 114 For example, suppose you use the popular 192.168.0.0/24 subnet as your private LAN subnet. Now you are trying to connect to the VPN from an internet cafe which is using the same subnet for its WiFi LAN. You will have a routing conflict because your machine won't know if 192.168.0.1 refers to the localWiFi gateway or to the same address on the VPN.113 * conflicts from different sites on the VPN using the same LAN subnet numbering, or 114 * remote access connections from sites which are using private subnets which conflict with your VPN subnets. 115 116 For example, suppose you use the popular 192.168.0.0/24 subnet as your private LAN subnet. Now you are trying to connect to the VPN from an internet cafe which is using the same subnet for its !WiFi LAN. You will have a routing conflict because your machine won't know if 192.168.0.1 refers to the local !WiFi gateway or to the same address on the VPN. 115 117 116 118 As another example, suppose you want to link together multiple sites by VPN, but each site is using 192.168.0.0/24 as its LAN subnet. This won't work without adding a complexifying layer of NAT translation, because the VPN won't know how to route packets between multiple sites if those sites don't use a subnet which uniquely identifies them. … … 120 122 And to avoid cross-site IP numbering conflicts, always use unique numbering for your LAN subnets. 121 123 122 Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients 123 Overview 124 = Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients = 125 126 == Overview == 124 127 125 128 The first step in building an OpenVPN 2.x configuration is to establish a PKI (public key infrastructure). The PKI consists of: 126 129 127 128 130 * a separate certificate (also known as a public key) and private key for the server and each client, and 131 * a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates. 129 132 130 133 OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established. … … 134 137 This security model has a number of desirable features from the VPN perspective: 135 138 136 137 138 139 139 * The server only needs its own certificate/key -- it doesn't need to know the individual certificates of every client which might possibly connect to it. 140 * The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection. 141 * If a private key is compromised, it can be disabled by adding its certificate to a CRL (certificate revocation list). The CRL allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt. 142 * The server can enforce client-specific access rights based on embedded certificate fields, such as the Common Name. 140 143 141 144 Note that the server and client clocks need to be roughly in sync or certificates might not work properly. 142 Generate the master Certificate Authority (CA) certificate & key 145 146 == Generate the master Certificate Authority (CA) certificate & key == 143 147 144 148 In this section we will generate a master CA certificate/key, a server certificate/key, and certificates/keys for 3 separate clients.
