Not quite a normal VPN connection using conventional tools.
I was looking for an interesting topic that deserves attention in order to get an invite to Habrohabre and I found it. I had to implement such a special case recently.
Here we will talk about two networks that need to be combined, one of which I will call “my office network”, and the other “remote network”.
The system administrator of the remote network refuses to make the smallest changes to connect, and the only thing that can be done is to place its equipment in the remote network. Internet access from this network is made through the gateway, which natit into the world. It is necessary to build a tunnel, between the two offices, so that the nodes of my office network can access the nodes of the remote network, with minimal changes from both sides.
To perform the task of combining two networks and building a virtual tunnel you need to use the Virtual Private Network. In the search for a suitable connection option, for myself I divided the VPN into two types: client-server option and peer. The following points are the fundamental difference:
Note1: In both options, one of the conditions must be met (for the client-server option, only for the server):
')
Examples of VPN protocols:
Client-server VPN:
Peer VPN:
Thus, the choice of the option - Client-server VPN becomes obvious. So how to change from the client does not need anything in this version.
And the first thing that comes to mind is the good old PPTP. He has a lot of security flaws, although there are more advanced, newer versions. Despite security flaws, PPTP has another very unpleasant feature - the GRE protocol used by the PPTP client to establish a connection to the server. If a connection is established according to the scheme specified in Note1.B, the equipment that performs port forwarding (Port Forwarding) must be able to pass a PPTP connection (often located in the Application Level Gateway section) through itself (The function is often called pass through PPTP). and translates to skip PPTP through itself). This is due to the peculiarities of the protocol and the fact that PPTP was not originally designed to work through NAT. If there is no such function, then in this scheme the VPN channel will not be established for the simple reason that the server will not see the incoming connection request.
PPPoE, L2TP and PPTP use the far from perfect authorization protocols pap, chap, mscap1 and mscap2.
Fortunately, the OpenVPN protocol is devoid of most of the above drawbacks, does not use the GRE protocol and was specifically designed taking into account the characteristics of networks using NAT.
A little about Open VPN: Works on port 1194, can use both TCP and UDP protocols. Application level protocol, based on OSI model.
Thus, the choice of these protocols has also become obvious - OpenVPN . Of course, it is not perfect and not a panacea, but for this case it will work best.
We will use the OpenVPN server from my office network (where I can change something, by and large I can change everything, I just don’t want to) the server, and from the remote network there will be a client. In order not to greatly change the scheme of your office network, in which the firewall is a hardware device (and which does not have a built-in OpenVPN server), you need to put a device with an OpenVPN server behind it and forward port 1194 to it.
Now we present how the connection between the client and the server will be established, but how will the nodes of the network of my office be able to see the nodes of the remote network?
In order not to make changes to the remote network routers, we will hide the network of my office by NAT. From my office, on the router, we will write down the route to the remote network through the VPN tunnel.
The disadvantage of masking, in this case, may be, not being able to gain access from the nodes of the remote network to the nodes of my office, which in this case is rather an advantage.
The diagram in red shows the tunnel established by the client to the server, the black dotted line shows the packet route from the node from my office to the node from the remote office through the tunnel.
On the proxy server 192.168.0.1-192.168.100.3 the following routes were added:
Here we wrap all the packets addressed to the 192.168.1.0/30 and 10.0.0.0/8 networks on the 192.168.100.2-192.168.1.1 router. OpenVPN Server runs on the same router. All packets by default are sent to the Internet through the gateway 192.168.100.1-Real_1, and for the network 10.0.0.0/8 are sent via a virtual channel built on the Internet to the OpenVPN Client 192.168.1.2-10.1.1.2.
For the normal operation of OpenVPN Server, on port 192.168.100.1-Real_1, port 1194 is forwarded to it.
The address from the remote subnet 10.1.1.2 is registered on the OpenVPN Client. The default gateway for it is 10.1.1.1. The client establishes a connection to the Internet through the real IP address Real_1. For the network 192.168.100.0/24, the route through 192.168.1.1-192.168.100.2 is registered in order for the packets that come from my office to return safely. Here, on the client, a rule is set in the firewall (NAT table): packets that come from the 192.168.100.0/24 network are masked (masquerading) as an address from this subnet (10.1.1.2).
So the packets from my network will get to the remote network and back according to the rules:
Packets sent by node 192.168.0.123 from my office to the remote network 10.0.0.0/8 to node 10.0.0.123 will be masked by the gateway 192.168.0.1-192.168.100.3 under the address 192.168.100.3 and will be directed to the router 192.168.100.2-192.168. 1.1, from where they will be redirected through the address 192.168.1.1 to the address of the router 192.168.1.2-10.1.1.2, where they will again be disguised as the address 10.1.1.2, from where they will safely reach the addressee 10.0.0.123. The address 10.0.0.123 will send the answer 10.1.1.2-192.168.1.2, which will send the answer from the address 192.168.1.2 to the address 192.168.1.1-192.168.100.2, which will return the packet from the address 192.168.100.2 to the server 192.168.100.3-192.168.0.1, which will transfer the packet back to 192.168.0.123 from the address 192.168.0.1.
This detailed packet tracing procedure was needed to make sure that all the settings were made correctly and nothing was missed.
You can use a regular computer with an installed * nix system and an OpenVPN software package.
And you can use specialized equipment. It so happened that I had two Mikrotik RB450.
The fact is that the first time I tried to test everything on PPTP, but the client could not connect to the server, although it was possible to establish a connection from a Windows computer.
Only from version 3.25 or higher you can upgrade to 4.20, as it is written on the official website www.mikrotik.com/download.html#2.php .
Therefore, in the download section, select our system, and in the Software section, select Legacy. Here I chose the latest release 3.30, which is placed on top of 3.22 without any questions:
Made by analogy with the article www.asp24antenna.com.ua/obnovlenie-s-328-os-na-routeros-40 .
Open WinBOX go to files, drag the firmware file 3.30 there, reboot and wait for a double peak - all the firmware is already there. Then we go to System> License and click update (the router must be connected to the Internet with configured DNS at this time). After the update, we download again only the new firmware and throw it into the router, reboot - all of us have the newest firmware! I was busy with updating both RB450 microtics from version 3.22 to 3.30 and then at 4.20, but this did not help and did not fix the situation with PPTP :(
According to the leadership of this article, wiki.mikrotik.com/wiki/OpenVPN I created certificates and imported them. For details, see this article. I will describe only the key points or those that caused difficulties.
Created an account on CAcert.org , although it is not at all necessary, you can issue a self-signed certificate.
On the router, which will be an OpenVPN server, we execute the commands:
Open the certificate-request.pem file, copy its contents (copy to a computer, for example, via FTP or drag to the desktop from WinBOX) and paste into a form on the CAcert.org website (registration is required) Server Certificates> New, received answer we copy in the file certificate-response.pem (it is necessary to fill in on OpenVPN server).
Now import certificates into WinBOX:
After that, the added certificate will be marked KR. If instead you see QR, import private-key.pem again (it helped me).
Now we are starting to create a server (do not forget to change it for your needs):
It is interesting to note that, theoretically, it is possible to establish a VPN connection, without having a single real IP address. The analogue of such a connection is installed by voice Internet messenger like Skype. The essence of such a connection is that there are several nodes and one server. Each node is connected to the server, but when node1 wants to establish a communication session with node2, it requests the parameters of the established connection to the server of node2, from the server, after which it “wedges in” instead of the server until the connection is broken and establishes it directly. This is implemented using SIP (Session Initiation Protocol). That is why Skype servers are not loaded with intermediate traffic generated by clients. The result of such surveys of the installation of the VPN connection of the tunnel using SIP control resulted in the link www.ietf.org/mail-archive/web/sipping/current/msg10092.html . Unfortunately, this idea did not become widespread, despite the fact that there are sketches of VPN-SIP from IETF and there is also a description from ETSI TS 185 010 V2.1.1 (2009-07) (It is necessary to enter "TS 185 010" and be registered member of ETSI to read the document).
Example of setting up a VPN connection using SIP control:
Fig.1 Remote access to the home network.
Still, there are closed, programs with similar functionality, such as Hamachi , Teamviewer , which, quite possibly, use exactly this idea.
Just imagine how the world would be transformed if it had a common and standardized protocol through which a VPN connection could be established using SIP control!
Task setting: Get access to the nodes of the remote network.
Here we will talk about two networks that need to be combined, one of which I will call “my office network”, and the other “remote network”.
The system administrator of the remote network refuses to make the smallest changes to connect, and the only thing that can be done is to place its equipment in the remote network. Internet access from this network is made through the gateway, which natit into the world. It is necessary to build a tunnel, between the two offices, so that the nodes of my office network can access the nodes of the remote network, with minimal changes from both sides.
To perform the task of combining two networks and building a virtual tunnel you need to use the Virtual Private Network. In the search for a suitable connection option, for myself I divided the VPN into two types: client-server option and peer. The following points are the fundamental difference:
- In a peer VPN using the global Internet, you need to have one real IP address for each of the nodes (at least 2 nodes). Here the connection can be initiated by each of the parties (that is why I called him, equal), there can be more than two of them.
- In the client-server version using the global Internet, you need only one real IP address for the server. The connection here occurs at the request of the client, the server always expects, there can be more than one client.
Note1: In both options, one of the conditions must be met (for the client-server option, only for the server):
- A. VPN peer, must be located directly on the gateway (additional software must be installed, or the device must be able to establish the necessary type of VPN connections).
- B. If it is not possible to start the VPN peer directly on the gateway, you need to configure it so that it can pass the port to another device configured as a VPN peer.
')
Examples of VPN protocols:
Client-server VPN:
- PPTP;
- L2TP;
- OpenVPN;
- PPPoE;
- ...
Peer VPN:
- IPSec;
- ...
Thus, the choice of the option - Client-server VPN becomes obvious. So how to change from the client does not need anything in this version.
Which client-server options to choose?
And the first thing that comes to mind is the good old PPTP. He has a lot of security flaws, although there are more advanced, newer versions. Despite security flaws, PPTP has another very unpleasant feature - the GRE protocol used by the PPTP client to establish a connection to the server. If a connection is established according to the scheme specified in Note1.B, the equipment that performs port forwarding (Port Forwarding) must be able to pass a PPTP connection (often located in the Application Level Gateway section) through itself (The function is often called pass through PPTP). and translates to skip PPTP through itself). This is due to the peculiarities of the protocol and the fact that PPTP was not originally designed to work through NAT. If there is no such function, then in this scheme the VPN channel will not be established for the simple reason that the server will not see the incoming connection request.
PPPoE, L2TP and PPTP use the far from perfect authorization protocols pap, chap, mscap1 and mscap2.
Fortunately, the OpenVPN protocol is devoid of most of the above drawbacks, does not use the GRE protocol and was specifically designed taking into account the characteristics of networks using NAT.
A little about Open VPN: Works on port 1194, can use both TCP and UDP protocols. Application level protocol, based on OSI model.
Thus, the choice of these protocols has also become obvious - OpenVPN . Of course, it is not perfect and not a panacea, but for this case it will work best.
Let's summarize a bit.
We will use the OpenVPN server from my office network (where I can change something, by and large I can change everything, I just don’t want to) the server, and from the remote network there will be a client. In order not to greatly change the scheme of your office network, in which the firewall is a hardware device (and which does not have a built-in OpenVPN server), you need to put a device with an OpenVPN server behind it and forward port 1194 to it.
Now we present how the connection between the client and the server will be established, but how will the nodes of the network of my office be able to see the nodes of the remote network?
In order not to make changes to the remote network routers, we will hide the network of my office by NAT. From my office, on the router, we will write down the route to the remote network through the VPN tunnel.
The disadvantage of masking, in this case, may be, not being able to gain access from the nodes of the remote network to the nodes of my office, which in this case is rather an advantage.
Matured scheme.
The diagram in red shows the tunnel established by the client to the server, the black dotted line shows the packet route from the node from my office to the node from the remote office through the tunnel.
On the proxy server 192.168.0.1-192.168.100.3 the following routes were added:
Route 10.0.0.0/8 192.168.100.2
Route 192.168.1.0/30 192.168.100.2
Here we wrap all the packets addressed to the 192.168.1.0/30 and 10.0.0.0/8 networks on the 192.168.100.2-192.168.1.1 router. OpenVPN Server runs on the same router. All packets by default are sent to the Internet through the gateway 192.168.100.1-Real_1, and for the network 10.0.0.0/8 are sent via a virtual channel built on the Internet to the OpenVPN Client 192.168.1.2-10.1.1.2.
For the normal operation of OpenVPN Server, on port 192.168.100.1-Real_1, port 1194 is forwarded to it.
The address from the remote subnet 10.1.1.2 is registered on the OpenVPN Client. The default gateway for it is 10.1.1.1. The client establishes a connection to the Internet through the real IP address Real_1. For the network 192.168.100.0/24, the route through 192.168.1.1-192.168.100.2 is registered in order for the packets that come from my office to return safely. Here, on the client, a rule is set in the firewall (NAT table): packets that come from the 192.168.100.0/24 network are masked (masquerading) as an address from this subnet (10.1.1.2).
Theoretical packet check
So the packets from my network will get to the remote network and back according to the rules:
Packets sent by node 192.168.0.123 from my office to the remote network 10.0.0.0/8 to node 10.0.0.123 will be masked by the gateway 192.168.0.1-192.168.100.3 under the address 192.168.100.3 and will be directed to the router 192.168.100.2-192.168. 1.1, from where they will be redirected through the address 192.168.1.1 to the address of the router 192.168.1.2-10.1.1.2, where they will again be disguised as the address 10.1.1.2, from where they will safely reach the addressee 10.0.0.123. The address 10.0.0.123 will send the answer 10.1.1.2-192.168.1.2, which will send the answer from the address 192.168.1.2 to the address 192.168.1.1-192.168.100.2, which will return the packet from the address 192.168.100.2 to the server 192.168.100.3-192.168.0.1, which will transfer the packet back to 192.168.0.123 from the address 192.168.0.1.
This detailed packet tracing procedure was needed to make sure that all the settings were made correctly and nothing was missed.
What equipment to choose as an OpenVPN server and client?
You can use a regular computer with an installed * nix system and an OpenVPN software package.
And you can use specialized equipment. It so happened that I had two Mikrotik RB450.
Configure RB450 or why I have not tested PPTP.
The fact is that the first time I tried to test everything on PPTP, but the client could not connect to the server, although it was possible to establish a connection from a Windows computer.
The Mikrotik RB450 update from version 3.22 to 4.20:
Only from version 3.25 or higher you can upgrade to 4.20, as it is written on the official website www.mikrotik.com/download.html#2.php .
Therefore, in the download section, select our system, and in the Software section, select Legacy. Here I chose the latest release 3.30, which is placed on top of 3.22 without any questions:
Made by analogy with the article www.asp24antenna.com.ua/obnovlenie-s-328-os-na-routeros-40 .
Open WinBOX go to files, drag the firmware file 3.30 there, reboot and wait for a double peak - all the firmware is already there. Then we go to System> License and click update (the router must be connected to the Internet with configured DNS at this time). After the update, we download again only the new firmware and throw it into the router, reboot - all of us have the newest firmware! I was busy with updating both RB450 microtics from version 3.22 to 3.30 and then at 4.20, but this did not help and did not fix the situation with PPTP :(
Decided to build immediately on OpenVPN.
According to the leadership of this article, wiki.mikrotik.com/wiki/OpenVPN I created certificates and imported them. For details, see this article. I will describe only the key points or those that caused difficulties.
Created an account on CAcert.org , although it is not at all necessary, you can issue a self-signed certificate.
On the router, which will be an OpenVPN server, we execute the commands:
/certificate create-certificate-request
# :
passphrase:
(Your name) common name:
#
certificate-request.pem
private-key.pem
Open the certificate-request.pem file, copy its contents (copy to a computer, for example, via FTP or drag to the desktop from WinBOX) and paste into a form on the CAcert.org website (registration is required) Server Certificates> New, received answer we copy in the file certificate-response.pem (it is necessary to fill in on OpenVPN server).
Now import certificates into WinBOX:
System> Certificates> Import
certificate-response.pem
private-key.pem
After that, the added certificate will be marked KR. If instead you see QR, import private-key.pem again (it helped me).
Now we are starting to create a server (do not forget to change it for your needs):
/ interface ethernet
set ether1 name="ether1"
#
/ interface bridge
add name="lan" arp=proxy-arp
#, arp=proxy-arp!
/ interface bridge port
add interface=ether1 bridge=lan
/ ip address
add address=192.168.1.1/24 interface=lan
#
/ ip pool
add name="ovpn-pool" ranges=192.168.1.2-192.168.1.2
# .
/ ppp profile
add name="ovpn-profile" local-address=192.168.1.1 remote-address=ovpn-pool use-encryption=yes only-one=yes change-tcp-mss=default
#, / ppp %)
/interface ovpn-server server
set enabled=yes auth=sha1 netmask=24 certificate=cert1 max-mtu=1500 port=1194 cipher=aes256 keepalive-timeout=60 mode=ip require-client-certificate=no default-profile=ovpn-profile
#
# mode=ip !
/ ppp secret
add name="user-1" service=pptp password="123456" profile=ovpn-profile
# !
On the router that will be OpenVPN Client we perform:
/interface ovpn-client
add name="ovpn-out1" connect-to=Real_1 port=1194 mode=ip user="user-1" password="123456" profile=default certificate=none cipher=aes256 add-default-route=no
# Real_1 IP OpenVPN .
# !
# mode=ip !
/ip firewall nat
chain=srcnat out-interface=ether1 src-address=192.168.100.0/24 action=masquerade
# 192.168.100.0/24
# :)
Lyrical digression
It is interesting to note that, theoretically, it is possible to establish a VPN connection, without having a single real IP address. The analogue of such a connection is installed by voice Internet messenger like Skype. The essence of such a connection is that there are several nodes and one server. Each node is connected to the server, but when node1 wants to establish a communication session with node2, it requests the parameters of the established connection to the server of node2, from the server, after which it “wedges in” instead of the server until the connection is broken and establishes it directly. This is implemented using SIP (Session Initiation Protocol). That is why Skype servers are not loaded with intermediate traffic generated by clients. The result of such surveys of the installation of the VPN connection of the tunnel using SIP control resulted in the link www.ietf.org/mail-archive/web/sipping/current/msg10092.html . Unfortunately, this idea did not become widespread, despite the fact that there are sketches of VPN-SIP from IETF and there is also a description from ETSI TS 185 010 V2.1.1 (2009-07) (It is necessary to enter "TS 185 010" and be registered member of ETSI to read the document).
Example of setting up a VPN connection using SIP control:
Fig.1 Remote access to the home network.
Still, there are closed, programs with similar functionality, such as Hamachi , Teamviewer , which, quite possibly, use exactly this idea.
Just imagine how the world would be transformed if it had a common and standardized protocol through which a VPN connection could be established using SIP control!
Source: https://habr.com/ru/post/80883/
All Articles