Ipsec vpn mtu 1400 что это

Ipsec vpn mtu 1400 что это

На сайтах проверки анонимности вы часто можете встретить разновидность такой проверки, как VPN Fingerprint. В этой статье мы ответим на следующие вопросы:

Что такое VPN Fingerprint?

Если перевести с английского название VPN Fingerprint (fingerprint с англ. – отпечаток), становится понятно, что речь идет про отпечаток VPN . Действительно, задача данной проверки состоит в том, чтобы обнаружить пользователя, который использует VPN, по определенным цифровым отпечаткам.

На картинке ниже изображены вариации модуля проверки VPN Fingerprint на нескольких известных сайтах проверки анонимности. Полную версию этого модуля вы можете найти в разделе «Информация о системе».

Так все-таки, на основании чего и как происходит эта проверка?

Постараемся все объяснить как можно проще. Если спешите, можете перейти к проблемам в обнаружении или сразу к выводам 🙂

Итак, как это работает. Допустим, вы хотите зайти на какой-то сайт:

1. Вы вводите в своем браузере нужный сайт и нажимаете enter.

1. В этот самый момент происходят переговоры между вашим ПК и сервером, на котором расположен данный сайт о том, как будет происходить передача данных.

• Возможно вы не знали, но все сетевые устройства передают/принимают данные не сплошным потоком, а разбивают их порционно на пакеты.
• На каждом устройстве заранее установлен максимальный размер пакета, который он может передать (MTU — Maximum Transmission Unit) за один раз.
• Размер MTU обычно задается вашим провайдером и может быть разный на каждом устройстве.

1. Устройства сообщают друг другу, какое максимальное количество данных (MSS — Maximum Segment Size) они могут принять друг от друга в одном пакете MTU, это делается с целью:

• информирования друг друга о возможностях своего интернет-соединения;
• использования канала передачи данных на всю катушку, с максимальной скоростью.

1. Модуль проверки, перехватывает эту информацию и анализирует пакеты MTU / MSS.

• Вообще, стандартный размер MTU 1500, он используется в интернете в подавляющем большинстве случаев.
• А вот, при подключении по PPTP, L2TP (±IPsec), IPsec IKE пакеты меньше. Это связано с тем, что пакеты помещаются в другие пакеты, что приводит к увеличению их размера. Поэтому операционная система вашего ПК уменьшает значение MTU на сетевом интерфейсе, чтобы предотвратить снижение скорости передачи данных.
• При подключении по OpenVPN происходит чуть по-другому, система оставляет значение MTU неизменным, но может изменять размер MSS внутри пакета.

Модуль проверки сверяет размеры пакетов с базой данных различий MTU/MSS и на основании этого делает вывод, используете вы VPN или нет.

Есть очень важные моменты, о которых вы должны знать:

• Если сайт использует такую проверку, то использует исключительно какую-то своюбазу данных.
• В текущий момент времени нет единой базы данных, которую бы 100% использовали все сайты, поэтому проверки на каждом сайте могут быть разные.

Насколько точная получается проверка?

Стоит отметить, что обнаружение пользователей, описанным выше способом, хорошо лишь в теории. В реальности зачастую все происходит далеко не столь гладко и вот основные проблемы:

Проблема № 1 – нет единой базы для всех сайтов.

Как уже указывалось ранее, нет единой базы для всех сайтов, которая бы предоставляла всем одинаковые результаты и при этом была бы авторитетной.

Чтобы наглядно продемонстрировать данную проблему:

• подключимся к VPN;
• будем использовать разные размеры MTU, например: 1396, 1418, 1420.
• проверим на трех разных сайтах, как они определят VPN.

Результат проверки на трех сайтах вы можете видеть на изображении ниже.

• MTU 1396: 2 из 3 сайтов определили VPN;
• MTU 1418: 2 из 3 сайтов определили VPN;
• MTU 1420: 1 из 3 сайтов определил VPN.

Как видим, в проверке участвовало всего лишь 3 сайта, а результаты уже у всех разные.

Вы спросите: «Почему же тогда ваш сайт определил во всех случаях, что используется VPN?»

• На основании своего опыта, мы предположили, что пользователь с таким размером MTU, вероятно подключен к VPN.
• Мы внесли корректировки в нашу базу данных. Теперь всех пользователей с таким размером MTU будет определять, будто они используют VPN. Хотя в реальности, этого может и не быть (проблема № 2, о ней чуть позже).
• Мы вам наглядно продемонстрировали, что такой результат будет отображаться только на одном сайте, в данном случае, на нашем.

Если учесть тот факт, что сайтов в мире более миллиарда, и нет единой базы, то вряд ли уважающий себя сайт, будет на сто процентов полагаться только на результат проверки VPN fingerprint.

Проблема № 2 – размер MTU задается провайдером.

Как уже писали, размер пакетов MTU задается вашим провайдером. В большинстве случаев используют стандартный размер MTU 1500.

Но, довольно часто провайдеры используют специфический размер MTU. В большинстве случаев это делают для того, чтобы согласовать работу сетевого оборудования. Например, оборудование Cisco считает размер MTU без учета заголовка, а оборудование Juniper вместе с заголовком L2 и размер MTU у них будет разный, поэтому необходимо согласовать размер MTU.

В качестве наглядного примера, приведем крупных российских провайдеров. Например, в некоторых регионах провайдер Yota использовал MTU 1358, а Мегафон MTU 1440. Оба эти MTU определяются, как подключенные к VPN. Хотя в реальноcти пользователь может и не использовать VPN. Действительно ли на стороне провайдеров есть туннели или это так оборудование настроено, знает лишь провайдер, но пользователей определяет будто они подключены к VPN.

Проблема 3 – MTU меняют сами пользователи.

Довольно часто такую рекомендацию, как сменить размер MTU вручную, можно встретить в Интернете. В некоторых случаях подобная рекомендация может помочь при решении следующих проблем:

• По неизвестной причине не открываются определенные веб-страницы или появилась/увеличилась задержка при их загрузке.
• Присутствуют ошибки при передаче файлов.
• Большой пинг, который необходимо уменьшить и т.д.

Не спешите сразу менять MTU, к этому процессу нужно подходить с умом, поэтому хотим вас заранее предостеречь: если вы выставите неправильное значение, у вас может перестать работать интернет, либо ощутимо пострадает скорость работы.

Чтобы убедиться в несовершенстве проверки VPN Fingerprint, просто сменим размер MTU в своем роутере. Установим, например, значение MTU 1408. В роутере TP-LINK это делается так:

Получим следующий результат:

К VPN мы не подключены, однако сайты определяют, будто мы используем VPN. Как видите, полагаться только на VPN Fingerprint не имеет смысла.

Хотелось бы добавить, что основной задачей данной статьи было не показать, на каком сайте проверке анонимности слабее или сильнее тесты. Все сайты справляются с данной задачей на все сто процентов. А объяснить принцип и наглядно продемонстрировать несовершенство такого способа проверки в целом.

Стоит ли бояться того, что VPN Fingerprint меня обнаружил?

На основании вышеизложенного можно сделать вывод, что бояться этого точно не стоит.

Результат проверки получается весьма поверхностный и к тому же зависит от соблюдения множества условий. Выходит, что нельзя до конца определить используете ли вы VPN или может это у вас настройки провайдера такие, а возможно это просто криво настроен маршрутизатор/софт на ПК, или специально установлен такой размер MTU для удобства взаимодействия с определенными устройствам и т.д.

Поэтому, можете спать спокойно и серфить в интернете не взирая на подобные сообщения, вы в безопасности.

Главное помните, что после смены IP адреса, обязательно удостоверьтесь в следующем:

MTU woes in IPsec tunnels and how you can fix it

Today I ran into a problem with IPsec Xauth PSK and the built-in Android VPN client (Android 4.1.2), resulting in some sites (such as www.yahoo.com) not loading through the VPN tunnel. Turns out I was dealing with MTU issues. When the Android VPN is started, it sets the MTU to 1500 on the tun0 interface:

Looking at the Android Source, it appears someone must have forgotten to take care of IPsec Xauth PSK. With PPTP and L2TP based VPNs, the MTU is reduced to 1400 (line 758 – 778).

• strongSwan Android client: MTU 1400
• OS X / iOS 7 built-in IPsec client: MTU 1280 (for what it’s worth, 1280 is also the minimum IPv6 packet size and thus the MTU minimum required to make IPv6 work)
• Windows 7 built-in IPsec client: MTU 1400
• Cisco VPN client: MTU 1300

Among the tested clients, only the connection through the Android VPN client was causing the issue with stalling websites. In a nutshell, I was able to fix it with the following on the VPN server:

And here is why.

IP fragmentation – The original problem.

On the VPN server side, we have the interface set to a standard Ethernet MTU 1500. In the scenario with the Android client, the MTU along the entire path is 1500. This leaves room for up to 1460 bytes of data payload per packet (also referred to as the maximum segment size MSS).

Keep in mind that IPsec in tunnel mode adds an ESP header and an additional IP header for tunneling the packet (usually with an additional size of around 70-80 bytes). When a packet is nearly the size of the MTU and when you tack on this encapsulation overhead, it is likely to exceed the MTU of the outbound link. That’s where IP fragmentation kicks in – which could lead to performance degradation of your VPN tunnel. Or worse…

Path MTU discovery (PMTUD). A failed solution.

To avoid IP fragmentation, many TCP/IP stacks have path MTU discovery (PMTUD) implemented. To tell you right away: It doesn’t work for me, and it’s not going to work for you either. PMTUD attempts to discover the largest IP datagram that may be sent without fragmentation through an IP path. Instead of fragmenting a too-large IP packet, the VPN server is told (through the Don’t Fragment (DF) flag in the IP header of the sender) to discard the packet and reply with an ICMP fragmentation required (type3, subtype 4) message.

Recap: The sender is the website that you try to load on your VPN client.

When the sender receives this ICMP packet, it learns to use a smaller MTU for packets sent to our VPN server. In theory. In reality, many websites (senders like www.yahoo.com) stupidly implement ICMP filters that break PMTUD functionality. And that’s where hell breaks loose. The sender is expecting an acknowledgement for the original packet from our server, but since the packet was discarded, the acknowledgment never comes. Time goes by, then the sender repeats sending the too-large packet. The result? The VPN sender discards the packet, again, sends yet another ICMP message, and so on. Meanwhile our client on the other end of the VPN tunnel cannot tell what’s happening and is desperately waiting for some data. Everything appears to be stalled – a state which is also referred to as a black hole connection.

Because PMTUD doesn’t always work on the Internet, the use of it only makes sense in a site-to-site VPN, where basically one operator maintains the networks and is able to enable the forwarding of the “fragmentation required” ICMP (type 3, subtype 4) notifications in all firewalls in between.

MSS size reduction. A working solution.

So we can rule out PMTUD, but there is another way to assure that our VPN connection is working properly.

This iptables rule reduces the size of the allowed packet size by reducing the MSS of TCP SYN packets. The –set-mss value explicitly sets the MSS to 1360, which is a customary size for IPsec IPv4 interfaces. The –mss option is used to match only those MSS that are between 1361 and 1536 bytes (we don’t want to rewrite the MSS of a VPN client that uses a smaller MSS). The result in a tcpdump:

In line 1, you see the request from our Android client through the tunnel to yahoo.com. Notice the MSS is 1460. In the second line, it is our VPN host initiating the TCP handshake with the external site. Only now the MSS value is rewritten to 1360, thanks to our iptables rule. As a consequence, the TCP connection will use the lower MSS of the two end points, which is 1360. Voila!

You can go further and restrict the iptables rule to rewrite only those packets that are forwarded from our VPN client:

This assumes that the address pool of your virtual IPs is 172.16.16.0/24 (see rightsourceip in /etc/ipsec.conf).

There is also an option to determine the MSS size dynamically (“MSS clamping”, via the –clamp-mss-to-pmtu option), but it wouldn’t fix IPsec for clients that set their MTU too high (like in the Android example).

The MSS iptables rule doesn’t work with UDP applications. UDP is a connectionless protocol; hence there is no way to negotiate a MSS during the handshake. The only solution to guarantee that UDP works is to disable the Don’t Fragment (DF) bit in the IP header of the sender. This will allow our VPN server to fragment any UDP packet, if necessary. In Linux, you do it like this:

The VPN server will fragment outgoing UDP packets that exceed the interface MTU, which may not be as great for performance and reliability reasons, but at least it doesn’t break the tunnel connection. Fortunately, most folks don’t use UDP for anything much greater than DNS.