📜 ⬆️ ⬇️

Access terrain.

It is no secret that timely access to information, including that stored within the corporate network of a company, can be a decisive factor in the success of employees. It's about virtual private networks (VPN). Sometimes giving access is not so easy.


Access is always and everywhere.
Providing remote access to the internal network of the company has to take into account many factors. Among which there is also the impossibility of establishing a connection between the client and the server. The reason may be simple - the system administrators of the guest network, from which an employee of the company is trying to connect, have closed all outgoing connections, and access to web resources through a "transparent" proxy server. In such a situation, establishing a VPN connection using standard solutions like pptp and IPsec is simply not possible.

The second big trouble for any mobile user may be the banal loss (or theft) of a laptop. It’s not necessary to explain what the stranger’s access to the corporate network for the company will turn into if the finder finds a laptop to take advantage of this opportunity. Of course, mobile users are obliged (usually at the corporate standard level) not to set the password storage option on the VPN access account, but ... have you seen many such users? I have not had a chance. Therefore, it is preferable to introduce additional security features for accessing the company's internal network. In other words, use two-factor user authentication in software and hardware. We are talking about eToken keys that can be used to securely store certificates for encrypting and decrypting data or authorizing different systems.
')
And the last (by the way, but not least) that I would like to mention - the possibility of obtaining access not only to files on the company's servers, but also to other resources. For example, to the mail server (in many companies, the use of external connections via pop3, imap and smtp protocols is prohibited). The problem may lie in the fact that the mail server is, for example, outside the company's local network. Next, we consider a comprehensive solution to all the problems indicated.
How we will solve the problem.
We will use the following software and hardware:
• OpenVPN, running under Linux, as a provider of secure private communication channel;
• htc and hts programs for organizing http tunnel through a proxy server;
• eToken PRO from Alladin.
You can use the same keys of any other manufacturers, the key of this company was just at my fingertips.

So, we consider each item separately.

OpenVPN.
The OpenVPN system [1] was chosen to implement the solution not by chance. This software is very actively updated by developers. OpenVPN allows you to implement almost any task on the organization of VPN channels.

Among the advantages of the system:
• support of almost all possible operating systems - Linux, Windows versions 2000 / XP and higher, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris;
• the ability to use all available OpenSSL encryption, authentication and certificate methods to protect your private channel;
• The ability to create entire server farms with load balancing thousands of incoming VPN connections;
• using a static key for encryption or a public key system;
• the ability to create a secure connection type "bridge" (ethernet bridges);
• the ability to use both udp and tcp for the VPN channel.

And this is not a complete listing of the OpenVPN functionality. The system is constantly being finalized, the number of opportunities increases.

Http tunnel using htc and hts.
These are small programs, one of which runs on the server, and the other, respectively, on the client. They do not need special settings and run a simple command line. Below we consider them in more detail.

eToken key.
For our purposes, any hardware key designed for secure storage of digital certificates is suitable. eToken PRO is a secure device designed for strong authentication, secure storage of secret data, performing cryptographic calculations and working with asymmetric keys and digital certificates. The USB key is architecturally implemented as a USB card reader with a smart card chip (chip) built into it. The key is made in the form of a keychain and is directly connected to the USB port of the computer, and does not require any additional devices for its operation.

There is a huge variety of similar hardware on the market and everyone can choose the most optimal device for their purposes. A nice feature of the keys is that you do not have to use them to solve only one task. The same key can allow authorization for Wi-Fi access to the network, for establishing a VPN connection and for encrypting data on a hard disk.

You only need the key itself and a free utility to work with it.

So, we proceed to the solution of the problem.

Installing OpenVPN server.
Let's use Gentoo Linux to install the OpenVPN system. But before we proceed with the installation, make sure that the Linux kernel contains all the necessary modules. To do this, go to our kernel configurator and pay attention to the entry relating to TUN / TAP drivers.

Device Drivers --->
Network device support --->
<*> Universal TUN / TAP device driver support

If support is installed, then everything is fine and you can continue. If not, set the required value and recompile the kernel of your system.

If you do not plan to use hardware keys for two-factor authentication in the future, the installation of the OpenVPN system itself is extremely simple and is done in one command.

# USE = 'ssl examples' emerge openvpn


With the current version of ebuild, the system will install OpenVPN version 2.0.6 for you. To use eToken you will have to go through the ports tree and force a newer version (currently 2.1_beta14).

# echo net-misc / openvpn >> /etc/portage/package.keywords
# USE = "ssl example" emerge openvpn


In addition, you may need to install the necessary additional packages. Therefore, at the time of installation, I recommend simply uncommenting the ACCEPT_KEYWORDS option of the desired architecture in your /etc/make.conf (in my case it is “~ x86”), allowing the system to install everything you need.
The SSL option is required to support OpenSSL, and examples installs examples of OpenVPN configuration files. Otherwise, there will be no examples and the configuration files will have to be written, as they say, from scratch.

Creating server keys and clients.
After the system is compiled, it will be necessary (for convenience) to copy the sample configuration files into / etc / openvpn and copy the scripts there to generate keys and certificates.

Both are in the / usr / share / openvpn directory. The easy-rsa subdirectory contains scripts for all occasions, allowing you to create:

root certificate (build-ca);
server key and certificate (build-key-server);
simple keys for clients (build-key);
password-protected client keys (build-key-pass);
PKCS keys for the ability we need to use eToken (build-key-pkcs12).

Initially, we will create all the necessary certificates and keys for the server.

# cd / etc / openvpn / easy-rsa
# source ./vars
# ./clean-all
# ./build-ca
# ./build-key-pkcs12 - server server
# ./build-dh
# ./build-key-pkcs12 –-pkcs12 client1


The last command creates PKCS12 keys for the user. Where client1 is an example of a username. The team must be executed for each prospective client. Please note that when creating a key, you can protect it with an additional password.

Configure OpenVPN.
The OpenVPN configuration file (called the default server.conf) is provided with very detailed comments and allows you to set up all the necessary settings without any problems practically without using any additional documentation.

First, we will indicate to what address and on which port our server will work:

local H.H.H.H
port 443

The choice of port is not accidental, I will explain later when we configure the client and server parts of the http tunnel.

The second thing to choose is tcp or udp, our VPN will work. For this there is a corresponding option:

proto tcp
or
proto udp

Since we are going to make access via the proxy web server of the guest system possible, we will choose proto tcp.

Next, select the type of network device to be used.

dev tun0 - in the case of organizing a normal VPN, or
dev tap0 - if you want to use a bridge connection.

Using the second option, remember about the need for a sufficient pool of free network addresses on your local network, which will occasionally be handled by remote users when connecting via VPN.

In the key description section we will write the full path to our key:

pkcs12 /etc/openvpn/easy-rsa/keys/server.p12
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

Note that only one pkcs12 key or the “standard” ca, cert and key can be used at the same time. If overlapping options are set, the system will refuse to start.

If you decide to use a regular VPN, specify the address space in which it will work and from which it will assign them to clients.
server 192.168.4.0 255.255.255.0

If you are going to use a bridge connection, you will need another option (the server parameter must be commented out, since the server can only work in one quality at a time):

server-bridge 192.168.1.73 255.255.255.0 192.168.1.61 192.168.1.63

Where:

• the first and second parameters - the address and mask of the local network server card;
• the third and fourth parameters - a pool of addresses for issuing to external clients.

Option we missed

ifconfig-pool-persist /etc/openvpn/ipp.txt

contains the name of the file in which the correspondences of customers will be stored (by the names of their keys) and their internal addresses, which the OpenVPN system gives them.

The following very important options indicate which address spaces will be available to clients and will automatically be added to the routing table when connected.

push "route 192.168.1.0 255.255.255.0"
push "route ... 255.255.255.255"

The first option adds the ability to use our local network, and the second adds a single external address where our mail server is located, to which clients should also have access under any circumstances.

Most of the options that follow are necessary to realize the possibilities beyond the scope of this material.

Options
push "dhcp-option DNS 192.168.1.1"
client-to-client

They indicate what DNS clients should use to convert names to ip addresses inside our local network, and whether to allow VPN clients to interact with each other. This can be useful if there is a need for file sharing between two users.

If for some reason you need to allow two independent VPN clients to use identical certificates at the same time - uncomment the duplicate-cn option.
The last thing you should now pay attention to is the name of the file and the path to it, where the OpenVPN log file will be written, as well as the number of valid users of the system at the same time.

Configure the LAN gateway.
If your OpenVPN server is not the main gateway of the local network, you will need to add routing for the VPN subnet. Since my network uses the Cisco 2621 as the main gateway, I added a route on it with the following command:
ip route 192.168.4.0 255.255.255.0 192.168.1.73

where the first and second parameters are the address and mask of the virtual subnet, and the last is the address of the internal interface of the OpenVPN server. (Do not forget about the need to enable interactive mode on cisco before entering a command, as well as recording changes in the device’s memory after adding a route.)

Adding a route to the Linux gateway is done with the command:

# route add -net 192.168.4.0/24 gw 192.168.1.73


where the first address is our virtual subnet, and the second is the address of the internal interface of the OpenVPN server.

If you do not do the above steps, packets from the local network will not be able to find a “way” to the VPN client.

Providing access to an external resource for VPN clients.
In order to allow VPN clients to get to our mail server, located in the outside world relative to our working network, we will use the services of iptables.

Creating a rule, I did not specify the allowed connection ports for the simple reason that, on an external server, in addition to the mail service, there are other services running on non-standard ports, which are often closed in the guest systems for connection. You can specify which ports will be available for connections to VPN clients.

In addition, if the rules on your firewall are configured according to the principle “prohibit everything you need to allow”, then do not forget to add permissions to forward packets from the tun0 interface.

We start the server
After all the necessary settings have been made, it's time to start the OpenVPN server and see what will be in the log file. Note that by default, the /etc/init.d/openvpn script is configured to work with the /etc/openvpn/openvpn.conf configuration file, and not the server.conf that goes in the examples at all. So, we start our server:

# /etc/init.d/openvpn start


In the log file you should see something like:

Sat Jun 17 22:54:42 2006 us = 295361 OpenVPN 2.0.6 i686-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jun 15 2006
Sat Jun 17 22:54:42 2006 us = 569088 Diffie-Hellman initialized with 1024 bit key
Sat Jun 17 22:54:42 2006 us = 798824 TLS-Auth MTU parms [L: 1544 D: 140 EF: 40 EB: 0 ET: 0 EL: 0]
Sat Jun 17 22:54:42 2006 us = 799346 TUN / TAP device tun0 opened
Sat Jun 17 22:54:42 2006 us = 799376 TUN / TAP TX queue length set to 100
Sat Jun 17 22:54:42 2006 us = 799409 / sbin / ifconfig tun0 192.168.4.1 pointopoint 192.168.4.2 mtu 1500
Sat Jun 17 22:54:42 2006 us = 824310 / sbin / route add-net 192.168.4.0 netmask 255.255.255.0 gw 192.168.4.2
Sat Jun 17 22:54:42 2006 us = 827291 Data Channel MTU parms [L: 1544 D: 1450 EF: 44 EB: 135 ET: 0 EL: 0 AF: 3/1]
Sat Jun 17 22:54:42 2006 us = 912828 GID set to nobody
Sat Jun 17 22:54:42 2006 us = 912911 UID set to nobody
Sat Jun 17 22:54:42 2006 us = 912950 Listening for incoming TCP connection on H.H.H.H: 443
Sat Jun 17 22:54:42 2006 us = 913000 Socket Buffers: R = [87380-> 131072] S = [16384-> 131072]
Sat Jun 17 22:54:42 2006 us = 913028 TCPv4_SERVER link local (bound): XXXX: 443
Sat Jun 17 22:54:42 2006 us = 913042 TCPv4_SERVER link remote: [undef]
Sat Jun 17 22:54:42 2006 us = 913072 MULTI: multi_init called, r = 256 v = 256
Sat Jun 17 22:54:42 2006 us = 913136 IFCONFIG POOL: base = 192.168.4.4 size = 62
Sat Jun 17 22:54:42 2006 us = 913348 MULTI: TCP INIT maxclients = 10 maxevents = 14
Sat Jun 17 22:54:42 2006 us = 913382 Initialization Sequence Completed


It is also worth paying attention to the output of the ifconfig command, which should show that a new network device tun0 has appeared in the system.

tun0 Link encap: UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr: 192.168.4.1 PtP: 192.168.4.2 Mask: 255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU: 1500 Metric: 1
RX packets: 0 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 0 errors: 0 dropped: 0 overruns: 0 carrier: 0
collisions: 0 txqueuelen: 100
RX bytes: 0 (0.0 b) TX bytes: 0 (0.0 b)

If the device does not appear, then carefully review the log and configuration file.

Do not forget to add the OpenVPN service to the list of automatically launched ones, as well as save the new iptables rules in your list.

Installing and configuring an OpenVPN client.
Now that the first half of our system setup is complete, it's time to start installing the client part of the program. I will review clients for Linux and Windows systems.

Installing a Linux VPN client.
A client on a Linux system may be required here in which case. Suppose you have a remote intranet server whose resources you would like to use on your local network. Nothing is easier! We simply connect these systems to our VPN and use. This can be especially useful if the server is local to some remote network.

As in the case of setting up a server system, make sure that the necessary modules are available in the kernel.

In Linux, the client part from the server part differs only in the configuration file. This file is much shorter and also has very detailed comments.

The first parameters indicate to the OpenVPN service that it is a client on the system. What network device and protocol are used, as well as what server IP address and what port is used by the OpenVPN service.

client
dev tun
proto tcp
remote openvpn.domain.ru 443

Copy the keys and certificates required for the work to the client system:

ca.crt, client1.crt, client1.key

and specify them in the configuration file

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/client1.crt
key /etc/openvpn/easy-rsa/keys/client1.key

This completes our client system setup and we can use it. You can run it by simply renaming the file from client.conf in openvpn.conf or by using the command line.

# openvpn /etc/openvpn/client.conf


The first time I would recommend to run from the command line. Since the protocol will be displayed directly on the screen, this will help ensure that everything is normal.
If everything went well, then at the end of the output you will see something like:

Sun Jun 18 20:32:02 2006 TUN / TAP device tun0 opened
Sun Jun 18 20:32:02 2006 / sbin / ifconfig tun0 192.168.4.30 pointopoint 192.168.4.29 mtu 1500
Sun Jun 18 20:32:02 2006 / sbin / route add-net 192.168.1.0 netmask 255.255.255.0 gw 192.168.4.29
Sun Jun 18 20:32:02 2006 / sbin / route add -net ... netmask 255.255.255.255 gw 192.168.4.29
Sun Jun 18 20:32:02 2006 / sbin / route add-net 192.168.4.0 netmask 255.255.255.0 gw 192.168.4.29
Sun Jun 18 20:32:02 2006 GID set to nobody
Sun Jun 18 20:32:02 2006 UID set to nobody
Sun Jun 18 20:32:02 2006 Initialization Sequence Completed


Do not forget to add the service to the list of automatically launched.

Install Windows OpenVPN client.
OpenVPN in Windows system has a graphical user interface (GUI), which greatly simplifies working with it for users. At address [2] you can always find the latest version of the program. I recommend at least the first time to download the full installation package (at the moment it is openvpn-2.0.7-gui-1.0.3-install.exe), as it contains drivers for TUN / TAP interfaces. Later, you can download updates only the program itself. (Application only by reference.)

Among the advantages and convenience of the client are:

• display of the program icon in the system tray;
• minimizing the connection log window immediately after establishing a session;
• view the connection log (call from the context menu);
• change configuration file settings (call from the context menu);
• using OpenVPN as a system service;
• a window for entering a password for a digital certificate for server authentication;
• additional protection of the program for the operation of the connection (your own password);
• password change to a secure key (including PKCS # 12);
• configuration of the proxy server used;
• use of proxy server settings from Internet Explorer options;
• script execution (bat) before and / or after connecting to the OpenVPN server;
• indication of the connection status in the system tray.

Remember that in versions of Windows younger than 2000 / XP the OpenVPN client will not work. But I think in our time, such versions of operating rooms are rare.

After installing the client, the OpenVPN item appears in the program menu with a rich selection:
• link to the folder with configuration files;
• on the folder with examples;
• static key generation program;
• a program for creating a certificate and forming a request for its signature;
• OpenVPN client program itself;
• links to various documentation.

The configuration file, like all previous ones, is provided with comments and is no different from the file for the Linux client system. The difference is only in the file extension. If it was “conf” in Linux, then opvpn in Windows. Therefore, it makes no sense to describe the settings, you can safely borrow them from the previous example.

Let's stop only on the description of keys and certificates. As you remember, we decided to use two-factor authentication for mobile users. To do this, copy to the client system from the server only two files - ca.crt and the certificate corresponding (by name) to this client with the extension p12.

Now we need to import our certificate into the Alladin eToken in our location. To do this, download (if not already installed) software for working with the RTE key using the link [3].

After installing the received program, we will have an eToken folder in the program menu with a single link to the program eToken properties.

Figure 1. The program for working with the key.
Figure 1. The program for working with the key.

Having inserted our key into the USB port, we will see it in the program window. Turning to the key icon and selecting "Advanced", enter the PIN code to access the key. This will allow you to import a certificate.

Figure 2. Certificate import window.
Figure 2. Certificate import window.

If a password was used when creating a certificate on the server (immediately after signing it), here we will be asked to enter it again and you can dispose of this certificate.

Now we can make sure that the certificate is known to our Windows system, and at the same time find out how the OpenVPN client will contact it. To do this, proceed to the "Control Panel", where we select "Internet Options". In this window, we are only interested in the "Content" tab and the "Certificates" button.

Figure 3. List of available certificates.
Figure 3. List of available certificates.

Select our certificate and click on “View”, in the opened window select “Composition”. Here we are interested in the field "Fingerprint", which we copy to the clipboard.

The received information about the certificate thumbprint will be entered into the configuration file of our OpenVPN client.

cryptoapicert "THUMB: ed 38 ac 63 ..."
ca ca.crt

Now that the initial configuration of the client is complete, it's time to try it out in action. To do this, it is enough to select a connection in the context menu. If the eToken access was completed correctly, a PIN code entry window will appear for access to the key.


Figure 4, 5. Luck and defeat.

In case of error, make sure that the key is inserted into the USB port, and the previous steps are correct.

After confirming access to the key, the log of connection to the server will be displayed in the same input window. The window will automatically hide as soon as the connection is successfully established. You can always return to the log by selecting “View log” in the context menu. It remains to try to ping to any of the computers on the remote LAN and make sure that everything is working correctly.

Now that everything is set up and working, it’s time to return to the situation when access to the outside world is limited by web resources. And to provide it, transparent proxying is used.

hts and htc.
As mentioned above, these two programs are easy to install and even easier to use. The essence of their work is that the first one “listens” to the port indicated by it (in our case it will be 80, access to which is everywhere) and in the case of initiating the connection, creates the http tunnel.

The second one, on the contrary, listens to port 443 and initiates a connection through port 80 with the remote htc.

Installing htc on Gentoo Linux on the server is done with a simple command:

# emerge httptunnel


For Windows systems, you can download httptunnel from the project page by reference [4].

Using httptunnel is very, very simple. To run on the server, the command is enough:

# hts --forward-port H.H.H.H: 443 80


Where is the ip address and port on which the tunnel should be established in case of access to port 80. The command is executed without any output on the screen. The results of its implementation can be found only in the system log. (For example, / var / log / messages.)

Jun 18 01:47:28 admin hts [27389]: hts (httptunnel) 3.3 started with arguments:
Jun 18 01:47:28 admin hts [27389]: me = hts
Jun 18 01:47:28 admin hts [27389]: device = (null)
Jun 18 01:47:28 admin hts [27389]: port = 80
Jun 18 01:47:28 admin hts [27389]: forward_port = 443
Jun 18 01:47:28 admin hts [27389]: forward_host = H.H.H.H
Jun 18 01:47:28 admin hts [27389]: content_length = 102400
Jun 18 01:47:28 admin hts [27389]: strict_content_length = 0
Jun 18 01:47:28 admin hts [27389]: use_std = 0
Jun 18 01:47:28 admin hts [27389]: debug_level = 0
Jun 18 01:47:28 admin hts [27389]: pid_filename = (null)


The netstat team confirms to us that hts really works and "listens" to port 80.

# netstat -napl | grep 80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 27389 / hts


It remains to make the windows script (bat) for launching the client part of the httptunnel. We will create this file in the c: \ program files \ openvpn \ config folder and name it hts_pre.bat. And in the file itself add only one line:

C: \ httptunnel \ htc.exe -F 443 -P 192.168.1.1:37128 XXXX: 80


Where:
-F 443 indicates the port that is the final recipient.
-P 192.168.1.180128 ip address and port of the proxy server of the guest system.
XXXX: 80 is the actual address of the server side httptunnel.

The choice of location and file name for the script is not accidental. As mentioned above, OpenVPN for Windows is able to execute bat files before connection, immediately after connection and after session termination. For this it is enough to fulfill only two conditions. Create a bat file in the OpenVPN configuration file directory and name the file as follows:

• Name the file xxx_pre.bat to run the script just before the connection.
• Call xxx_up.bat to execute immediately after the connection is established.
• Call xxx_down.bat for the session terminating script.

We are interested in the first type of script. By the way, after executing the command from our bat file, the system will not close the window and it will have to be done manually. This will not stop our tunnel, but it will save you from having an open window on your desktop. I suppose there is a tool to avoid this “always open” window, but I didn’t find it right away (maybe because I’m not good at writing scripts for Windows). If you know the way, so much the better.

As you noticed, to establish the tunnel, we needed to know the ip address and port on which the proxy server of the guest system is running. This information, of course, is not written in large print upon entering the building, but nevertheless (usually) is easily recognized by the system administrator. Cases when the sysadmin refused to report the proxy settings to me (perhaps for now) are not known.

Now our system is fully configured and ready to work in almost any conditions. A sort of the most secure all-terrain vehicle on the Internet!

How mobile can be OpenVPN.
, OpenVPN . ( ), , «» . (). (, Windows Mobile Symbian) VPN , .

However, due to the use of the OpenVPN TUN / TAP system, simple connection methods will not work. And to find them for devices of this class, alas, is not yet possible. Surveys on the Internet gave only information about the ongoing development of the implementation of the use of OpenVPN. (Now a link to information about this is already on the main page of the project. [5])

However, there is one exception. If you own a Sharp Zaurus PDA and have long been planning to install Linux on it, then you can use your VPN. Drivers and the necessary software for this can be found on the Internet. It is used by many people. The necessary files can be taken, for example, here [6].

Final word
OpenVPN , Windows , . eToken, , . , . eToken . , , Windows ( ).

References:
[1] — openvpn.net
[2] — openvpn.se/files/install_packages
[3] — www.alladin.ru/support/download/category177
[4] — userpages.umbc.edu/~tmoses1/hypertunnelNT.zip
[5] — www.ziggurat29.com/OVPNPPCAlpha/OVPNPPCAlpha.htm
[6] — users.skynet.be/isa-et-pep/pep/zaurus/feed

(c) akeeper Korshunov Alexey.
« .

Source: https://habr.com/ru/post/5401/


All Articles