Симптомы
- Наблюдаем низкую скорость передачи данных через Site-to-Site VPN
- У клиентов Remote Access VPN низкая скорость скачивания файлов через туннель
Решение
Для измерения скорости передачи трафика через VPN потребуется настроить утилиту iperf на узлах с двух сторон туннеля, а затем выполнить замеры с указанием количества потоков:
iperf3 -P <cpu_num> -c <iperf3_server_address> (число потоков = число ядер NGFW)
В результате получится список измерений, нас интересуют последние строчки с тегом [SUM]:
[SUM] 0.00-10.01 sec 103 MBytes 85.2 Mbits/sec sender
[SUM] 0.00-10.03 sec 100 MBytes 84.7 Mbits/sec receiver
Эти значения и будут являться текущей скоростью передачи трафика через туннель между двумя хостами. L2TP/IPsec на реальных скоростях приводит к минус 20–40% от максимума канала.
Если скорость действительно низкая, выполните следующие рекомендации:
- Отключите модуль fastpath по статье https://sd.usergate.com/articles/14
- Сделайте исключения защиты от DoS для внешних IP адресов интерфейсов, которые используются для построения VPN-туннеля. Исключения добавляются в свойствах зоны (например Untrusted), которой принадлежит интерфейс, в разделе Сеть ➜ Зоны.
- Уменьшите значение MTU на туннельных интерфейсах до 1384 согласно следующей статье https://docs.usergate.com/nizkaya-skorost6-peredachi-dannyh-v-tunnele-site-to-site-vpn-mezhdu-dvumya-ustrojstvami-usergate_750.html
- Попробуйте понизить алгоритмы шифрования в профиле безопасности VPN
- При наличии возможности переключите туннель на другого провайдера и замерьте скорость через него
- Имеется возможность проверить скорость передачи файлов по SMB через VPN туннель без влияния провайдера. Для этого создайте новое правило VPN в сторону локальной сети (соединения Site-to-Site между двумя NGFW и Remote Access VPN поднимаются аналогично по L2TP/IPsec), создайте правило NAT для данного соединения, чтобы ответные пакеты также шли через туннель. Подключите одну машину из локальной сети к VPN и попробуйте загрузить файл, затем отключитесь от VPN и еще раз выполните загрузку.
Рекомендация
- По какой причине наблюдается низкая скорость передачи файлов по SMB?
SMB работает совсем по-другому, чем iperf, он гораздо тяжелее для VPN-туннеля. Протокол SMB с многоступенчатым подтверждением, если ping через VPN хотя бы 20-40 ms, скорость по SMB резко падает, а если имеется джиттер или минимальная потеря, падение ещё сильнее. iperf качает данные потоками, без сложной логики, и при тестировании в несколько потоков показывает максимальную скорость туннеля. SMB же обычно качает в 1 поток, и при больших RTT (времени приема-передачи) скорость падает кратно. У L2TP/IPSec реальный MTU составляет 1360–1400, но SMB пакеты крупные, при фрагментировании скорость сильно падает. Итого:
- SMB плохо работает при задержке + L2TP/IPsec
- MTU слишком низкий, проблема фрагментации
- Один поток TCP
Так как в рамках L2TP/IPSec значительно изменить ситуацию в лучшую сторону не получится, даже путём понижения алгоритмов шифрования, имеется следующий вариант решения - переход на GRE over IPSec или IKEv2.
GRE over IPSec обычно даёт прирост скорости по сравнению с L2TP/IPSec на 20-40%, а IKEv2 ещё больше - до 50-70%.
- L2TP/IPSec это самый тяжёлый и старый вариант реализации VPN туннеля (двойная инкапсуляция, низкий MTU, проблемы фрагментации), в результате получается просадка 30–50% от всей ширины канала.
- GRE over IPSec это одна инкапсуляция + чистый IPSec, проще MTU, стабильнее пропускная способность.
- IKEv2 это чистый IPSec без лишних протоколов.
Примечание
Как пример - использование PPPoE на клиенте, которое добавляет дополнительные байты в заголовок.
Проверка эффекта от уменьшения MTU:
- На клиенте замерить скорость скачивания с интернет через VPN:
curl -4kO https://speedtest.selectel.ru/10MB -x 172.29.255.1:8090
где 172.29.255.1 - адрес туннельного интерфейса на сервере
- Можно не меняя MTU на туннельном интерфейсе, изменить на клиенте MSS для сервера:
ip ro add 172.29.255.1 dev tunnel3 advmss 1360
- отменить изменение MSS:
ip ro del 172.29.255.1 dev tunnel3 advmss 1360
- Проверить скорость после изменений (повторная проверка показала рост скорости в 30+ раз)