VPN for mobile devices at the network level
In RuNet, there is still surprisingly little material about such an old and simple, but convenient, secure and especially relevant in connection with the development of the Internet of things technology, like mobile VPN (virtual private network). In this article I will describe how and why you can configure access to your private network to any device with a SIM card without having to configure specialized software on it.
To begin, answer the question "why?". VPN as a technology is used to solve a variety of network tasks, united by a common feature - isolated data transfer between two devices through a large number of intermediate nodes. On the basis of this, more complex solutions are already being built and those very different tasks are being solved. In the usual, usual case, a fixed-line operator’s network is used to build a VPN (there is excellent material for those who want details) or many different network protocols (GRE, IPSec, L2TP and others are the same author about this ) and software products that work with them (Cisco AnyConnect, OpenVPN, TOR - well, you yourself know), but using them on a specific terminal device immediately puts forward a number of requirements for it, the failure of which leads to certain restrictions.
The first serious limitation is that the device should be able to work with at least one of these protocols at the hardware and software levels. Most often this is determined by software that is easy to find for a laptop or smartphone, but there are cases where the task is too simple from a hardware point of view, or its software has limitations: the water meter wants to use a VPN to transfer its unfortunate byte of readings Once a month, no less than you want to use VPN to edit your LinkedIn profile.
Another important limitation is the need for customization. It works both for the “stupid” devices from the first paragraph, and for classic smartphones and computers that are not aware of the previous limitation. And if with the first ones everything is relatively simple and depends on the amount of time spent on setting up, then with the second ones there are options. Often, organizations use VPN for security purposes in order to protect the service terminal device from going out to the public network without proper corporate protection or from transferring service data through public channels. End users may, for whatever reasons, disable or forget to enable VPN, with the result that many company security systems may be “overboard”.
')
Both of these restrictions are easily removed if access to the VPN is provided at the network level. In the case of mobile communications, this can be implemented using a “mobile VPN”. A device of any complexity capable of transmitting data will transmit it to the correct network. No matter what settings are made on the device, with a properly configured network, it will in any case pass them to the right place and nowhere else.
And as a nice bonus, the device will receive an address from the internal network that is remotely configured, and access to it will be possible to get only from within this network (or physically). For a certain class of devices, this is very important.
It would seem that VPN is a classic service of all telecom operators for the B2B segment, and why in that case to focus on this? The thing is how the data network for devices connected via GPRS, HSPA, LTE or other mobile communication technology is arranged. There are no usual for all network administrators vlan, no switches, not even routers in their usual meaning. But there is a radio access network (RAN) and packet core (PS Core).
Simplified diagram of the mobile operator's packet network. It is slightly different for LTE, but the general meaning remains the same.
In general, each device with a SIM card registered in the packet network (passed the GPRS attach procedure or similar), before starting to transfer data somewhere, must initiate the creation of a data transfer session (PDP context) on the packet core network router, GGSN . Details and purpose of these processes are very well described here in this article . What is important for us: when initiating a session in a request to the GGSN, among others are the parameters that many have seen in their phones or even dealt with them when setting up, for example, usb modems. These are three fields: APN, login and password. APN (access point) is a very important entity in the logic of the GGSN: depending on which APN the session is initiated with, the GGSN acts differently. As a result of successful processing of the user's request, the GGSN must activate the data transfer session and inform the device of its parameters, in particular, the IP address and DNS addresses issued to the device. There are a number of important very important features:
The first three points immediately raise the question: what kind of IP address is given to the subscriber?
This is determined by the settings of the APN with which the request to activate the session came. About 99% of data transfer users in mobile networks use regular Internet access. These are known to all access points internet.mts.ru, internet.beeline.ru and so on. In the case of Internet access, GGSN issues addresses according to the classic DHCP principle from the gray subnets set in the settings. When they enter the public network, they are closed by the classic NAT (or, more precisely, by its version, which is PAT).
But GGSN is capable of more. To select an IP address, he can make an AAA request to the authorization server (Radius, for example). Such logic is configured for individual APNs depending on their purpose. The easiest case is a permanent public IP address service. Such addresses, as a rule, are assigned to subscribers in the billing (BSS) of the operator, and depending on the IT architecture they fall into one or another database, to which the GGSN requests. Due to the fact that he knows the MSISDN (telephone number) of the subscriber, which will be contained in the request, such a database will be quite simple and can contain only a bunch of numbers and addresses. In addition, if the client plans to use one SIM card to connect several devices (if the SIM card is in the WiFi router of the remote office, for example), this table may also contain the so-called “framed route” - the prefix of the network located “ for a SIM card that will be announced to all devices on the network using dynamic routing protocols.
In addition to issuing addresses, you also need to deliver subscriber traffic to customer networks, each to its own. Everything here works much more traditionally. On GGSN, traffic specialized for working with a VPN APN is routed to a separate operator’s network router (it can be called differently, sometimes a VPN router), which in turn performs the function of a classic PE in L3VPN scheme. It adds the necessary labels, headers, and this is all and sends all this traffic flow through the routers of the transport network to the pre-configured junctions or tunnels to the client’s network. This part is much more traditional and has been described in other places many times, so I will not focus on it in this material.
With all these details, there can be several ways to organize a mobile VPN, and they will differ from each other in a combination of the following features:
There are several dozens of such combinations with different types of tunneling, balancing traffic between the access channels to the "main" VPN client and the principle of issuing addresses. For most cases, the general scheme is as follows:
As a result, after a fairly quick registration process in the network and obtaining an IP address, the device gets access to the client’s network, and the client’s network gets access to the device. At the same time, the subscriber is isolated from all other subscribers of the operator who are not related to a particular client, he does not need any additional settings, and all traffic is unconditionally sent to the client’s network, where it is processed in accordance with the client’s internal policies.
Tasks and limitations
To begin, answer the question "why?". VPN as a technology is used to solve a variety of network tasks, united by a common feature - isolated data transfer between two devices through a large number of intermediate nodes. On the basis of this, more complex solutions are already being built and those very different tasks are being solved. In the usual, usual case, a fixed-line operator’s network is used to build a VPN (there is excellent material for those who want details) or many different network protocols (GRE, IPSec, L2TP and others are the same author about this ) and software products that work with them (Cisco AnyConnect, OpenVPN, TOR - well, you yourself know), but using them on a specific terminal device immediately puts forward a number of requirements for it, the failure of which leads to certain restrictions.
The first serious limitation is that the device should be able to work with at least one of these protocols at the hardware and software levels. Most often this is determined by software that is easy to find for a laptop or smartphone, but there are cases where the task is too simple from a hardware point of view, or its software has limitations: the water meter wants to use a VPN to transfer its unfortunate byte of readings Once a month, no less than you want to use VPN to edit your LinkedIn profile.
Another important limitation is the need for customization. It works both for the “stupid” devices from the first paragraph, and for classic smartphones and computers that are not aware of the previous limitation. And if with the first ones everything is relatively simple and depends on the amount of time spent on setting up, then with the second ones there are options. Often, organizations use VPN for security purposes in order to protect the service terminal device from going out to the public network without proper corporate protection or from transferring service data through public channels. End users may, for whatever reasons, disable or forget to enable VPN, with the result that many company security systems may be “overboard”.
')
Both of these restrictions are easily removed if access to the VPN is provided at the network level. In the case of mobile communications, this can be implemented using a “mobile VPN”. A device of any complexity capable of transmitting data will transmit it to the correct network. No matter what settings are made on the device, with a properly configured network, it will in any case pass them to the right place and nowhere else.
And as a nice bonus, the device will receive an address from the internal network that is remotely configured, and access to it will be possible to get only from within this network (or physically). For a certain class of devices, this is very important.
How it works
PS Core
It would seem that VPN is a classic service of all telecom operators for the B2B segment, and why in that case to focus on this? The thing is how the data network for devices connected via GPRS, HSPA, LTE or other mobile communication technology is arranged. There are no usual for all network administrators vlan, no switches, not even routers in their usual meaning. But there is a radio access network (RAN) and packet core (PS Core).
Simplified diagram of the mobile operator's packet network. It is slightly different for LTE, but the general meaning remains the same.
In general, each device with a SIM card registered in the packet network (passed the GPRS attach procedure or similar), before starting to transfer data somewhere, must initiate the creation of a data transfer session (PDP context) on the packet core network router, GGSN . Details and purpose of these processes are very well described here in this article . What is important for us: when initiating a session in a request to the GGSN, among others are the parameters that many have seen in their phones or even dealt with them when setting up, for example, usb modems. These are three fields: APN, login and password. APN (access point) is a very important entity in the logic of the GGSN: depending on which APN the session is initiated with, the GGSN acts differently. As a result of successful processing of the user's request, the GGSN must activate the data transfer session and inform the device of its parameters, in particular, the IP address and DNS addresses issued to the device. There are a number of important very important features:
- In a request to initiate a session, the device never requests which IP address it would like to receive;
- In addition to the “APN”, “login” and “password” fields specified in the device settings, the GGSN request also sends the subscriber’s phone number (MSISDN) (hereinafter “subscriber” is the end user, one device with a SIM card, and "Client" - the customer organization of the service, which includes subscribers);
- When a session is activated, the GGSN creates an entry in its routing table about the new IP address. All subscribers to GGSN are indicated by entries in the routing table with the prefix / 32, i.e. 1 subscriber - 1 entry in the table. GGSN is a very productive router;
- The operator’s network may, at different stages (on both SGSN and GGSN), for various reasons, change the APN field in the session initiation request. This allows in some cases to reduce, and in some even eliminate the configuration of network parameters on devices with a SIM card.
The first three points immediately raise the question: what kind of IP address is given to the subscriber?
This is determined by the settings of the APN with which the request to activate the session came. About 99% of data transfer users in mobile networks use regular Internet access. These are known to all access points internet.mts.ru, internet.beeline.ru and so on. In the case of Internet access, GGSN issues addresses according to the classic DHCP principle from the gray subnets set in the settings. When they enter the public network, they are closed by the classic NAT (or, more precisely, by its version, which is PAT).
But GGSN is capable of more. To select an IP address, he can make an AAA request to the authorization server (Radius, for example). Such logic is configured for individual APNs depending on their purpose. The easiest case is a permanent public IP address service. Such addresses, as a rule, are assigned to subscribers in the billing (BSS) of the operator, and depending on the IT architecture they fall into one or another database, to which the GGSN requests. Due to the fact that he knows the MSISDN (telephone number) of the subscriber, which will be contained in the request, such a database will be quite simple and can contain only a bunch of numbers and addresses. In addition, if the client plans to use one SIM card to connect several devices (if the SIM card is in the WiFi router of the remote office, for example), this table may also contain the so-called “framed route” - the prefix of the network located “ for a SIM card that will be announced to all devices on the network using dynamic routing protocols.
Not a single GGSN
In addition to issuing addresses, you also need to deliver subscriber traffic to customer networks, each to its own. Everything here works much more traditionally. On GGSN, traffic specialized for working with a VPN APN is routed to a separate operator’s network router (it can be called differently, sometimes a VPN router), which in turn performs the function of a classic PE in L3VPN scheme. It adds the necessary labels, headers, and this is all and sends all this traffic flow through the routers of the transport network to the pre-configured junctions or tunnels to the client’s network. This part is much more traditional and has been described in other places many times, so I will not focus on it in this material.
With all these details, there can be several ways to organize a mobile VPN, and they will differ from each other in a combination of the following features:
- IP addresses, as already described, can be issued dynamically (each time a different address from a given subnet) and statically (each time the same address for a particular subscriber), which is determined by both / or APN settings and / or Radius server settings ;
- IP addresses can be issued by a Radius server under the control of an operator or under the control of a client;
- Devices connected to a mobile VPN can communicate either only with each other or have access to the client’s usual L3VPN network through a direct interface (VPN port) with an operator or through tunneling over the Internet;
- In some cases, the use of a login and password for successful activation of the session may be necessary, and sometimes it is not even necessary to fill in the “APN” field.
There are several dozens of such combinations with different types of tunneling, balancing traffic between the access channels to the "main" VPN client and the principle of issuing addresses. For most cases, the general scheme is as follows:
As a result, after a fairly quick registration process in the network and obtaining an IP address, the device gets access to the client’s network, and the client’s network gets access to the device. At the same time, the subscriber is isolated from all other subscribers of the operator who are not related to a particular client, he does not need any additional settings, and all traffic is unconditionally sent to the client’s network, where it is processed in accordance with the client’s internal policies.
Source: https://habr.com/ru/post/444946/
All Articles