Скорость в тунеле заметно ниже минимальной скорости подключения к интернету

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Сетевые технологии (http://forum.oszone.net/forumdisplay.php?f=31)

Скорость в тунеле заметно ниже минимальной скорости подключения к интернету

Здравствуйте.

Имеется пара офисов соединённых при помощи 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 на интерфейсах 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 у себя на интерфейсах?

Цитата:

Цитата Tonny_Bennet

При передаче пакета из локальной сети 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 байта.... »

Решил проверить эту схему при помощи 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 интерфейс провайдера. Почему?

на моей практике вот что было.
Был центральный офис, к нему по VPN подключалось порядка 80 точек. VPN был на OpenSolaris.
И вот значит одна точка (расстояние 200 км) подключалась, но передача данных была не возможна.
Выяснилось на месте, что провайдер назначил MTU меньше стандарта 1500. Начали подпирать значение для себя - остановились на 1460.
Большего сказать не могу.

Мне просто интересно что делать: менять значение MTU у себя во всех сетях и подгонять под одно и то же значение (меньше 1492)? Или есть другие методы решения?

Просто обидно за то, что канал не эффективно используется.

Цитата:

Цитата Tonny_Bennet

менять значение MTU у себя во всех сетях и подгонять под одно и то же значение »

я вот не помню... мы меняли или на компе или на роутере, который VPN поддерживал.
Во всех сетях точно не нужно, т.к. проблема же только на одной стороне.

Цитата:

Цитата Tonny_Bennet

менять значение MTU у себя во всех сетях и подгонять под одно и то же значение »

попробуй подогнать под большее

Устанавливая в настройках сервера и клиента любое значение MTU, после перезапуска подключения на интерфейсе устанавливается значение на 4 байта меньше. Больше 1496 байт установить не получается.

Указал в настройках сервера MTU 1400. Подключился клиентом. На VPN интерфейсах обеих серверов установился MTU 1396. Сделал тестовую прокачку iperf. В туннеле 1Мбит/с; без туннеля 2 Мбит/с.

Решил для чистоты эксперимента совсем отключить шифрование в тунеле. Отключил. MTU на обеих интерфейсах 1500. Скорость прокачки в тунеле 700-730Кбит/с. Мистика какая-то...

Вопрос так и не решился. Может у кого-нибудь будут другие предложения по поводу организации туннеля?

P.S. в Ubutntu можно использовать чистый GRE тунель без шифрования. Я пока думаю над вопросами безопасности. В принципе тунель используется только для RDP подключений, которые сами защищены и очень редко для передачи файлов и почты (в почте настроен SSL). Скажите стоит ли пробовать???