|
|
| Line 1: |
Line 1: |
| − | {{legacy}} | + | {{stub}} |
| − | {{procedure
| + | Apparently ''Wireguard'' is much slimmer and faster than ''OpenVPN'', and is supposedly very straight forward to set up, I have average Linux admin skills and have not managed to get it working though. I could connect with IPv4 and IPv6 to the server, but not beyond, I think that complicated routing rules must be required for this. |
| − | | description = Once a [[w:VPN|VPN]] has been set up with the [[install a new VPN]] procedure, all the workstations which are connected to the same VPN connection form part of a "virtual LAN" and they can all publish and use resources shared in that LAN such as shared directories, printers and services. They all show up in the normal "network places" or equivalent even though the hosts can be located in diverse locations around the internet, and all these connections are encrypted and secure.
| + | *https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-20-04 |
| − | | role = Sysop
| + | *https://www.ckn.io/blog/2017/11/14/wireguard-vpn-typical-setup/ |
| − | | status = in use
| + | *https://jakew.me/2020/10/19/wireguard-docker |
| − | }}
| |
| − | | |
| − | == Install OpenVPN ==
| |
| − | OpenVPN is a full-featured SSL VPN solution which can accomodate a wide range of configurations, including remote access, site-to-site VPNs, WiFi security, and enterprise-scale remote access solutions with load balancing, failover, and fine-grained access-controls. OpenVPN is a single program that is run on both the server hosting the share, and on the clients which will be accessing it. First install it on the server an Linux clients.
| |
| − | <source>
| |
| − | apt-get install openvpn
| |
| − | </source>
| |
| − | | |
| − | == Create the TUN/TAP device ==
| |
| − | A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link. Most Linux systems will have these devices set up by default, but some VPS hosts such as [http://www.vpslink.com VPSLink] do not (see the [http://forums.vpslink.com/linux/116-dev-net-tun-tun-tap-bridge-disabled-please-enable-it.html issue raised in their forum] and the [http://wiki.vpslink.com/index.php?title=TUN/TAP_device_with_OpenVPN_or_Hamachi solution added to their wiki] for more detail about this). If '''/dev/net/tun''' exists then you already have TUN/TAP set up and can move on to the OpenVPN configuration, otherwise do the following to create a TUN device.
| |
| − | <source>
| |
| − | mkdir -p /dev/net
| |
| − | mknod /dev/net/tun c 10 200
| |
| − | chmod 600 /dev/net/tun
| |
| − | </source>
| |
| − | | |
| − | == Server configuration ==
| |
| − | We'll go for a configuration which is as close to the default ''server.conf'' example file as possible to simplify the procedure. The certificate files must be specified with full pathnames, and the protocol must be changed to TCP rather than UDP which is the default. Here's all the required settings with comments removed for brevity.
| |
| − | <source>
| |
| − | port 1194
| |
| − | proto tcp
| |
| − | dev tun
| |
| − | | |
| − | ca /etc/openvpn/ca.crt
| |
| − | cert /etc/openvpn/server.crt
| |
| − | key /etc/openvpn/server.key
| |
| − | dh /etc/openvpn/dh1024.pem
| |
| − | cipher AES-128-CBC
| |
| − | | |
| − | server 10.8.0.0 255.255.255.0
| |
| − | push "dhcp-option WINS 10.8.0.1"
| |
| − | | |
| − | ifconfig-pool-persist ipp.txt
| |
| − | duplicate-cn
| |
| − | keepalive 10 120
| |
| − | comp-lzo
| |
| − | | |
| − | user nobody
| |
| − | group nogroup
| |
| − | | |
| − | persist-key
| |
| − | persist-tun
| |
| − | | |
| − | status openvpn-status.log
| |
| − | verb 4
| |
| − | </source>
| |
| − | *The ''server'' parameter is multi-client config running as a DHCP server
| |
| − | | |
| − | === Creating Keys ===
| |
| − | There's a utility called ''easy-rsa'' in ''/usr/share/doc/openvpn/examples/easy-rsa'' which should be copied to ''/etc/openvpn/easy-rsa''. The default values for all certificates generated can be updated in the ''vars'' file. First, configure ''easy-rsa'' with the following shell commands:
| |
| − | <source>
| |
| − | cp -pR /usr/share/doc/openvpn/examples/easy-rsa /etc
| |
| − | cd /etc/easy-rsa/2.0
| |
| − | mkdir keys
| |
| − | . ./vars
| |
| − | ./clean-all
| |
| − | </source>
| |
| − | | |
| − | | |
| − | Next we'll use ''easy-rsa'' to generate a master key, a server key, a shared client key and finally we'll build the [[w:Diffie-Hellman key exchange|Diffie Hellman key exchange parameters]]. Each of the commands requires a number of questions to be answered which can all be left as their defaults (which were set up in the ''vars'' file above), except for the ''common name'' setting which we'll set to "od-server" for the master key, "server" for the server key, and "client" for a generic keys shared by all the clients (the name "client" is the default name used on the windows sample client configuration and so requires no changes, but if you prefer you may like to create a separate client key for each based on the hostnames).
| |
| − | <source>
| |
| − | ./build-ca
| |
| − | ./build-key-server server
| |
| − | ./build-key client
| |
| − | ./build-dh
| |
| − | </source>
| |
| − | | |
| − | | |
| − | All the generated key files are in the ''easy-rsa/2.0/keys'' directory that was created above. All the files having the ''.key'' suffix are secret and should only be communicated over encrypted connections like ''SCP''. The ''ca.crt'' file belongs on the server in ''/etc/openvpn'' and all the client machines as well. The files that start with "client" or the client hostnames belong on the client machines.
| |
| − | | |
| − | == Client configuration ==
| |
| − | === Setting up Ubuntu workstations ===
| |
| − | First install OpenVPN and the configuration GUI using '''apt-get install openvpn network-manager-openvpn'''. The GUI adds a "VPN Connections" item to the network menu from the system tray which VPN's can be added, removed and configured from.
| |
| − | | |
| − | Add a new VPN and set its name (e.g. "Office LAN") and the ''gateway'' to the domain or IP address of the intranet. Set the authentication type to "Certificates (TLS)" and browse for the two ''.crt'' files and the ''.key'' file created above. Click the ''advanced'' button and tick "Use LZO compression" and set the cipher to "AES-128-CBC".
| |
| − | | |
| − | Currently you'll need to enter '''smb://10.8.0.1''' into a Nautilus window to gain access to the intranet shares because any NetBIOS names that are routed to the clients via DHCP are in terms of the intranets subnet not the VPN's.
| |
| − | | |
| − | === Setting up on Windows workstations ===
| |
| − | Download and install [http://openvpn.net/index.php/open-source/downloads.html OpenVPN] (note that if you're using Vista you'll need at least version 2.1), this will set up a new network adapter which you should rename appropriately for example to "office-lan".
| |
| − | | |
| − | Copy the ''ca.crt'', ''client.crt'' and ''client.key'' files generated on the server into ''Program Files\OpenVPN\Config'' on the client. Also copy the sample client config into that directory (and call it something like ''office.opvn'') and set the '''dev-node'' parameter to the name you gave to the new network adapter, and the ''remote'' parameter to the address (domain or IP) of your server. Here's a typical windows OpenVPN client configuration file:
| |
| − | <source>
| |
| − | client
| |
| − | dev tun
| |
| − | proto udp
| |
| − | | |
| − | dev-node office-lan
| |
| − | remote lan.foo.com 1194
| |
| − | | |
| − | resolv-retry infinite
| |
| − | nobind
| |
| − | persist-key
| |
| − | persist-tun
| |
| − | | |
| − | ca ca.crt
| |
| − | cert client.crt
| |
| − | key client.key
| |
| − | cipher AES-128-CBC
| |
| − | | |
| − | comp-lzo
| |
| − | verb 3
| |
| − | </source>
| |
| − | | |
| − | | |
| − | Right click on the VPN network icon in the system tray and select "connect", if all has been done correctly, the connection with the remote LAN should be made and an IP address obtained.
| |
| − | | |
| − | Currently you'll need to enter '''\\10.8.0.1''' into an Explorer window to gain access to the list of all available shares on the remote LAN because any NetBIOS names that are routed to the clients via DHCP are in terms of the intranets subnet not the VPN's.
| |
| − | | |
| − | You should add each share you want to have regular access to into your network places. To do this, go to "My Network Places" from the start menu, and then select "Add a network place", click next a couple of times and then enter the address where prompted, for example '''\\10.8.0.1\Documents''' and click OK, you can then enter a friendly name for the connection if you like such as "Office LAN documents". The items in your network places will remain there even after turning the computer off, but note that the VPN connection must be established before you can access them (by right-clicking the VPN network icon in the system tray and click "connect").
| |
| − | | |
| − | === Detailed procedure ===
| |
| − | For a detailed Windows XP/Vista procedure with screenshots, see: [[Set up and configure a VPN connection on Windows XP/Vista]]
| |
| − | | |
| − | == Notes ==
| |
| − | === Bridging/Routing ===
| |
| − | Ethernet bridging essentially involves combining an ethernet interface with one or more virtual TAP interfaces and bridging them together under the umbrella of a single bridge interface. Ethernet bridges represent the software analog to a physical ethernet switch. The ethernet bridge can be thought of as a kind of software switch which can be used to connect multiple ethernet interfaces (either physical or virtual) on a single machine while sharing a single IP subnet.
| |
| − | | |
| − | By bridging a physical ethernet NIC with an OpenVPN-driven TAP interface at two separate locations, it is possible to logically merge both ethernet networks, as if they were a single ethernet subnet. See the [http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html OpenVPN bridging information] for more detail.
| |
| − | | |
| − | === What is the principle behind OpenVPN tunnels? ===
| |
| − | Here is a brief summary of the principle behind OpenVPN from the [http://www.ossg.ru/docs/OpenVPN/faq.html OpenVPN FAQ].
| |
| − | | |
| − | Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.
| |
| − | | |
| − | Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.
| |
| − | | |
| − | Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).
| |
| − | | |
| − | The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the "long cable" analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won't work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don't need the special features of ethernet (such as bridging capability), it's better to use a tun device.
| |
| − | | |
| − | Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I've even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. The sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.
| |
| − | | |
| − | == See also ==
| |
| − | *[http://openvpn.net/index.php/open-source/faq.html OpenVPN FAQ] | |
| − | *[http://openvpn.net/index.php/open-source/documentation/install.html?start=1 OpenVPN Win32 Installation]
| |
| − | *[http://openvpn.se OpenVPN GUI for Windows] | |
| − | *[http://wiki.openvz.org/VPN VPN on OpenVZ] (our VPS's OS)
| |
