We define VPN users (and their settings!) And proxy from the site

^{We can save the day from dark
There's no one we need}

Many of you use a VPN or proxy in everyday life. Someone uses it constantly, gaining access to resources blocked at the state or corporate level, many use it occasionally to bypass the restrictions on geographic location. As you may know, major Internet players in the field of video streaming, music, and game sales have never liked users who easily bypass geographical restrictions, unlocking inaccessible content in their country, or making purchases much cheaper. There is no need to go far for examples: Netflix changed its usage agreement by adding a clause about blocking a VPN, just 2 months ago; Hulu also sinned blocking users, and Steam is generally suspicious of non-Russian-speaking users from Russia. Recently, companies are trying to block not specific users, but the IP addresses of VPN services themselves, creating certain inconveniences for the VPN service itself and its users. It seems that they do not use any special means, but block selectively and manually. Although I do not support any blockages at all, I was interested in the technical part of the question: can I somehow determine the use of proxy servers and VPN from the server side without making any special efforts?
It is possible, under certain conditions. And quite accurately.

MSS and MTU

MTU, or Maximum Transmission Unit - the maximum amount of data that can be transmitted in one packet. MTU is installed on each network adapter, even on those routers through which traffic from you to the remote server goes in transit. In the overwhelming majority of cases, MTU 1500 is used on the Internet, however, there are noticeable exceptions, which, by the way, are often subject to certain rules.
')
When your browser or any other software working with a network creates a TCP connection to a remote server, the Maximum Segment Size (MSS) value is placed in the packet headers, which tells the server what maximum size of segments it can transmit in one packet. This value is very close to the MTU, it immediately makes the server understand the possibilities of your Internet connection, eliminating unnecessary fragmentation and allowing you to utilize your channel to the full.
When you send a packet while connected to a VPN using some protocol (PPTP, L2TP (± IPsec), IPsec IKE), it is placed (encapsulated) into another packet that introduces its overhead, and large packets that sent without fragmentation without VPN, now have to be fragmented. To avoid such fragmentation, the OS installs less MTUs on the network interface than the real network interface MTU, which is why the OS does not attempt to create large packets that would require fragmentation.
In the case of PPTP, L2TP (± IPsec), IPsec, as I understand it, there are no standards for the MTU of the tunnel, everyone sets these values ​​to work in most cases, and they are installed by eye. As a rule, it is 1400, which allows using, say, PPTP on channels with an MTU of up to 1440 without fragmentation (for example, when you need another tunnel to access the Internet, as is often the case with Russian providers). OpenVPN - perhaps the most popular VPN option - on the contrary, went the other way.

Openvpn

In order to be compatible with old or simply crooked software, OpenVPN by default does not set a lower MTU value on the VPN interface, but changes the MSS value inside the encapsulated TCP packet. The mssfix parameter, which is set to 1450 by default, is responsible for this. It modifies the MSS so that it fully utilizes the channel from the MTU 1450, i.e. calculates their overhead in such a way that they pass through the channel with MTU 1450 or more without fragmentation. As a result, we have the opportunity not only to define OpenVPN users with standard mssfix 1450, but also to define their connection protocol (IPv4, IPv6), transport protocol (TCP, UDP), encryption, compression and MAC parameters, since they contribute their unique overhead and are reflected in the MSS.
Let's look at typical MSS values:

Protocol	Block size	MAC	Compression	MSS
UDP	64	SHA1	-	1369
UDP	64	SHA1	+	1368
Tcp	64	SHA1	-	1367
Tcp	64	SHA1	+	1366
UDP	128	SHA1	-	1353
UDP	128	SHA1	+	1352
Tcp	128	SHA1	-	1351
Tcp	128	SHA1	+	1350
UDP	128	SHA256	-	1341
UDP	128	SHA256	+	1340
Tcp	128	SHA256	-	1339
Tcp	128	SHA256	+	1338

If a cipher with a block size of 64 bits is used, this is probably Blowfish, if 128 is probably AES.

For greater theory testing, 2 VPN services were tested: VyprVPN and ibVPN. Both services are subject to the definition of settings by the method described.
If you do not want to be detected in this way, you can either disable mssfix by setting it to 0 both on the server and on the clients, thus obtaining MSS 1460 (in the case of IPv4), which corresponds to the MTU 1500 — the typical MTU for a normal wired connection that the vast majority of users have. However, in this case, you will get excessive fragmentation, which leads to increased delays and reduced throughput, so it may make sense to set the MTU to 1400, 1380 or similar (should be a multiple of 2, and better than 10), because Such values ​​are often used by providers, for example, the mobile Internet.

Proxy

There are not many ways to define a proxy server if it does not add any headers (like X-Forwarded-For). What is the technical difference between a proxy and a VPN? In the case of VPN, the remote server receives from you the package that your OS created, in an unchanged (often) form. The proxy, on the contrary, receives only all the information about the remote server (IP, port, other parameters) and data, creating a packet on the side of the proxy itself, and sends it. Different operating systems create packages in different ways, differences can be found even from version to version. We can accurately determine the OS of the creator of the package, the version does not interest us much.
As it seems to me, proxies are most often run on Linux and BSD, and are used more often under Windows. Users often do not think about changing the User-Agent, which includes the operating system used, in the browser, and this is good for us.

p0f

There is a wonderful project p0f that fits perfectly with our needs. Passively listening to the traffic, it can determine the OS, MTU and browser, notify the OS of the creator of the packages and the OS in the User-Agent. In addition, it has an API. By slightly modifying it , adding MTU export via API and updating signatures, we can detect users of popular VPN protocols, proxy users and users who fake a User-Agent with a certain accuracy.

ＷＩＴＣＨ？

A little thought, I decided to make a small web service to implement my ideas, because, for some reason, I could not find anything like that.
This resulted in ＷＩＴＣＨ？, which will easily tell you about the settings of your OpenVPN connection (if you didn’t touch mssfix, of course), try to determine your OS and compare it with the OS in the User-Agent, get a PTR record for your IP and compare it with a set of rules, determining whether you are using an Internet channel designed for home or server users.

First seen = 2015/07/24 17:19:29 Last update = 2015/07/24 18:39:37 Total flows = 7 Detected OS = Linux 3.11 and newer HTTP software = Firefox 10.x or newer (ID seems legit) MTU = 1409 Network link = OpenVPN UDP bs64 SHA1 Language = Russian Distance = 15 Uptime = 1 days 19 hrs 39 min (modulo 165 days) PTR test = Probably home user Fingerprint and OS match. No proxy detected. OpenVPN detected. Block size is 64 bytes long (probably Blowfish), MAC is SHA1. 

ＷＩＴＣＨ？ also easily identifies users of the Tor Browser, since it uses the same static User-Agent (with Windows) on all operating systems, and exit nodes are running under Linux and FreeBSD.


During the tests, many interesting details emerged:

• Mobile Internet from Beeline passes all connections through a proxy for Linux. It was discovered when a person with Beeline came from the iPhone to？, and the OS was defined as Linux. It is probably through him that they change HTML tags , add a toolbar with mail.ru search and change the design of sites .
• The MTU of mobile devices can literally be anything, but, as a rule, ends at 0. The exception is Yota from 1358. What it depends on is not clear, I suspect that from the settings on the operator’s side and from the telephone module. The same SIM in different phones uses different MTU.
• The code that is responsible for mssfix in OpenVPN is very slow. If you have knowledge of networks, C, desire and time, please see if it can be optimized.

So it goes.