[Tonny_Bennet]

Итак... медленно стали проясняться детали... Один бывший коллега (ведущий инженер связи у одного из провайдеров) написал мне что проблема скорее всего в 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 интерфейс провайдера. Почему?

[exo]

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

[Tonny_Bennet]

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

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

[exo]

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

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

[freese]

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

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

[Tonny_Bennet]

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

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

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

[Tonny_Bennet]

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

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