Имеется пара офисов соединённых при помощи VPN: 192.168.0.0/24 с шлюзом 192.168.0.10, и 192.168.3.0 с шлюзом 192.168.3.1. Шлюзы под Ubuntu Server. Решил протестировать скорость соединения между точками соединения при помощи iperf.
На первом сервере запускаю iperf -s на втором запускаю iperf -c <внешний_адрес_первого сервера> скорость порядка 2 Mbit/s. В моём случае приемлемо ибо это минимальная скорость одного из тарифных планов.
На первом сервере запускаю iperf -s на втором запускаю iperf -c 192.168.0.10 и скорость порядка 1Mbit/s (523Kbit/s-1,2Mbit/s). И тут возникает вопрос почему такая большая разница? Я понимаю, что есть шифрование (в моём случае это MPPE-128), но в таком случае наверное загрузка процессора должна зашкаливать и сразу будет видно тонкое место. У меня загрузка более 2% не возрастает. Я понимаю, что VPN предусматривает инкапсуляцию и за счёт этого растёт длина служебных заголовков пакетов. Но не в два раза же?
Один бывший коллега (ведущий инженер связи у одного из провайдеров) написал мне что проблема скорее всего в MTU. Начал копаться. Нашёл пару статей, но понимания вопроса пока нет.
Первый сервер:
eth0 (192.168.0.10) MTU 1500 смотрит в локальную сеть.
ppp0 (PPPoE от провайдёра) MTU 1492 смотрит в интернет
ppp1 (192.168.2.1 VPN сервер) MTU 1496 серверная точка VPN тунеля
Второй сервер:
eth0 (192.168.3.1) MTU 1500 смотрит в локальную сеть
ppp0 (192.168.2.3) MTU 1496 клиентская точка VPN тунеля
eth1 (канал от провайдера) MTU 1500 смотрит в интернет
При передаче пакета из локальной сети 192.168.0.0/24 в сеть 192.168.3.0/24 размером в 1500 байт, как мне казалось, произойдёт следующее:
1. Он попадёт на интерфейс eth0 с MTU 1500
2. Затем будет инкапсулирован GRE и при попытке впихнуть его в интерфейс ppp1 с MTU 1496 его поделят на два пакета
3. Затем при попытке передачи через интерфейс провайдера ppp0 с MTU 1492, первый пакет из тех двух снова придётся делить на два ибо не влезет
4. В итоге первый пакет размером 1500 байт был разделен на три пакета с наибольшим размером в 1492 байта....
Изменить MTU на интерфейсе провайдера скорее всего не получится, тогда придётся изменять MTU на VPN интерфейсах. Но тогда в всё равно будет фрагментация пакета при передачи данных из локальной сети в интернет и VPN тунель.
Стоит ли понижать MTU на интерфейсах серверов, подключенных к локальным сетям? Будут ли клиенты локальной сети (Windows) адекватно изменять MSS/MTU у себя на интерфейсах?
Решил проверить эту схему при помощи ICMP запросов с заданным размером буфера отправки и флагом, запрещающим фрагментацию пакета:
Код:
C:\Users\User>ping 192.168.3.3 -l 1468 -n 1 -f
Обмен пакетами с 192.168.3.3 по с 1468 байтами данных:
Ответ от 192.168.3.3: число байт=1468 время=61мс TTL=126пакет проходит... ответ возвращается....
Вывод tcpdump, показывает запрос и ответ. Видно, что результирующая длина пакета была 1496 байт = MTU моего VPN интерфейса
Код:
00:02:44.916563 IP (tos 0x0, ttl 128, id 10484, offset 0, flags [DF], proto ICMP (1), length 1496)
192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 76, length 1476
00:00:00.063331 IP (tos 0x0, ttl 126, id 17431, offset 0, flags [none], proto ICMP (1), length 1496)
192.168.3.3 > 192.168.0.97: ICMP echo reply, id 1, seq 76, length 1476Если отправить пакет на 1 байт больше, то он не пройдёт:
Код:
C:\Users\User>ping 192.168.3.3 -l 1469 -n 1 -f
Обмен пакетами с 192.168.3.3 по с 1469 байтами данных:
Ответ от 192.168.0.10: Требуется фрагментация пакета, но установлен запрещающий флаг.tcpdump показывает следующее:
Код:
00:00:48.703631 IP (tos 0x0, ttl 128, id 10693, offset 0, flags [DF], proto ICMP (1), length 1497)
192.168.0.97 > 192.168.3.3: ICMP echo request, id 1, seq 78, length 1477Т.о. получается, что пакеты при данной схеме передачи не фрагментируются при прохождении пакета через PPPoE интерфейс провайдера. Почему?
Устанавливая в настройках сервера и клиента любое значение MTU, после перезапуска подключения на интерфейсе устанавливается значение на 4 байта меньше. Больше 1496 байт установить не получается.
Указал в настройках сервера MTU 1400. Подключился клиентом. На VPN интерфейсах обеих серверов установился MTU 1396. Сделал тестовую прокачку iperf. В туннеле 1Мбит/с; без туннеля 2 Мбит/с.
Решил для чистоты эксперимента совсем отключить шифрование в тунеле. Отключил. MTU на обеих интерфейсах 1500. Скорость прокачки в тунеле 700-730Кбит/с. Мистика какая-то...
