+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Медленная скорость VPN при одностороннем TCP-потоке

Медленная скорость VPN при одностороннем TCP-потоке, RouterOS

NetWorker

Guest

02.04.2021 23:49:00

Всем привет, у меня проблема с VPN, и я никак не могу понять в чём дело. Если хотите, можете пропустить описание фона.

Фон:
Главный офис: Mikrotik RB3011, 30/10 Мбит/с (приём/отдача) на VDSL, Win2008r2 файловый сервер
Удалённый офис: Mikrotik RB2011uias, 10/10 Мбит/с по трёхэтапной беспроводной линии до оптики, Win2016 файловый сервер

Когда-нибудь мы обновим наши физические Windows-серверы, но пока полагаемся на них и делаем резервные копии SMB (robocopy) с удалённого офиса на главный. С тех пор, как я настроил VPN между офисами (4-5 лет назад), у меня постоянно медленная скорость отдачи с удалённого офиса на главный. Тогда я думал, что это из-за известных проблем с SMB (версии 2008 и 2016 не очень дружат или протокол слишком разговорчив для WAN). Я немного поковырялся, но забил — время на резервные копии было терпимым.

На прошлой неделе размер резервных копий удвоился из-за нового софта, и теперь полная копия загружается больше 72 часов. Обычно мы делаем инкрементальные копии, а раз в две недели — полные. Скорость передачи держится где-то на уровне 2–3 Мбит/с. Я решил попробовать FTP и Windows 2016 → Windows 10, но улучшений не увидел.

Год назад мы апгрейднули канал удалённого офиса до симметричных 10/10 Мбит/с, и теперь пинг между офисами устойчиво 25 мс. Короче, я выяснил, что проблема в VPN с однопоточными TCP-соединениями и не связана с приложениями поверх него (SMB, FTP и т. п.).

Сам VPN — L2TP через IPSec с IKE2 и сертификатами. L2TP выбрал, потому что нужен интерфейс для OSPF, а GRE и IPIP требуют статических IP, которых у нас нет. IPSec взял из-за поддержки аппаратного шифрования на 3011 и большей безопасности с сертификатами вместо PSK. Аутентификация SHA256, шифрование AES256cbc.

Симптомы:
- Однопоточные TCP-передачи с 3011 на 2011 максимум 10 Мбит/с
- Однопоточные TCP-передачи с 2011 на 3011 ползут со скоростью 2–3 Мбит/с
- Многопоточные TCP-передачи с 2011 на 3011 могут полностью загружать канал на 10 Мбит/с
- Загрузка ЦП на 2011 примерно 30% при шифровании на 3 Мбит/с
- Загрузка ЦП на 3011 — 2–3%, так как там в основном маршрутизация и аппаратное шифрование при 10 Мбит/с
- Загрузка ЦП на 2011 до 60–70% при расшифровке на 10 Мбит/с
- Однопоточный TCP-запрос в интернет упирается в 10 Мбит/с
- Второй офис с RB2011, настройка такая же, максимальная скорость отдачи 4 Мбит/с, но однопоток ползёт в районе четверти (около 1 Мбит/с), а многопоток полностью загружает канал в 4 Мбит/с

Что пробовал:
- AES256 CTR, AES128 CTR, AES128 CBC
- GRE, IPIP и PPTP вместо L2TP
- MTU и MRU снижал до адекватных значений
- MSS clamp с правилом PMTU

Суть проблемы: однопоточный TCP через VPN нормально идёт в одну сторону, в другую — ползёт примерно в ¼ скорости. Многопоток полностью загружает канал. Похоже, что дело не в шифровании или железе, но я в тупике, что ещё может вызывать такое.

Буду очень благодарен за любые советы!!

NetWorker

Guest

23.04.2021 15:30:00

Ну, на этой неделе я отключил туннель IPSec и L2TP. Не думал, что это проблема, просто чтобы исключить этот вариант. Затем пробовал IPIP-туннель без шифрования (MSS clamp с PTMU=yes) — и получил те же результаты. UDP — 10 Мбит/с, многопоточный TCP — 10 Мбит/с, однопоточный TCP в одну сторону — 2,4 Мбит/с, в другую — 10 Мбит/с. На этом этапе я уже почти готов с этим сдаться. Если это проблема TCP, то, скорее всего, уже вне моего контроля. Когда-нибудь съезжу туда с другим роутером, попробую, чтобы убедиться, что дело не в моей конфигурации. Хотя я уже вдоль и поперёк проверил всё раз сто. Пока что придется подождать — снова карантин из-за коронавируса держит нас взаперти.

Редактирование: bpwl, только что перечитал твой пост и забыл упомянуть, что я уже пробовал FTP на Ubuntu LTS-сервер (см. оригинальный пост). Кажется, использовал Filezilla в роли клиента. Но не знал, что в Filezilla есть опция многопоточной передачи. Полагаю, что это работает только с сервером Filezilla, ведь, насколько я знаю, это не входит в стандартный FTP, или нет? Я разберусь с этим позже на этой неделе.

Я также посмотрел на Expand Networks и Riverbed. Первый уже не существует, его остатки выкупил Riverbed. Но, насколько я понял, эта линейка продуктов уже в прошлом. В любом случае, мы не в США, и специализированное оборудование такого рода достать очень сложно или невозможно. =(

Спасибо ещё раз за все советы и предложения!

mikegleasonjr Guest	#3 0 27.08.2021 23:25:00 У меня примерно та же проблема, ты как-то ее решил?

sindy

Guest

28.08.2021 07:06:00

Я столкнулся с похожей проблемой (одиночное TCP-соединение с помощью /tool bandwidth-test между двумя CHR-роутерами, работающими у одного провайдера), и корень проблемы низкой пропускной способности — снижение с 200 Мбит/с до менее 0,5 Мбит/с — оказался в том, что 25 % крошечных вторичных фрагментов транспортных пакетов просто не доходили до пункта назначения (и 0,2 % больших первых фрагментов, если уж быть честным). И всё это на сетевом пути с задержкой всего 1,6 мс в обе стороны по ping, при том что CHR-роутеры находятся всего в 5-7 маршрутизаторах друг от друга.

@bpwl уже всё объяснил, но я расскажу ещё раз своими словами, чтобы подчеркнуть главное: поскольку пропускная способность TCP рассчитывается по успешно доставленным данным, а повторные передачи пакетов происходят с экспоненциально растущей задержкой, если теряется не только первоначальный пакет с конкретным фрагментом потока данных, но и несколько его повторных передач (в моём случае — из-за потери фрагмента), то промежутки в доставке данных могут достигать нескольких секунд. Такие паузы влияют на результат гораздо сильнее, чем кажется по уровню потери пакетов.

У меня даже был случай, когда RouterOS сам завершил тест, потому что даже последняя попытка повторной передачи не удалась. (Я не проверял, что произойдёт, если запускать тест с connection-count больше 1 и одно из соединений упадёт подобным образом — будет ли оно заменено новым или нет).

Сейчас я жду отзыв от участника форума, который проводит такой же тест между двумя CCR на расстоянии примерно 3000 км, где выбор локального провайдера на одном конце решает, будет ли всё «как обычно» или «совсем нерабоче». Конечно, ваши результаты тестов тоже будут полезны — просто одновременно запустите /tool sniffer на обоих роутерах, сохраняя результаты в файл и фильтруя только по IP-адресу противоположного роутера (без фильтрации по портам, потому что фрагменты её не содержат) во время выполнения /tool bandwidth-test протокол=tcp connection-count=1.

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

NetWorker

Guest

28.08.2021 20:51:00

Привет, mikegleasonjr! Нет, я так и не нашёл решения этой проблемы. Мне удалось уменьшить размер полного бэкапа так, что теперь он занимает около 30 часов. Учитывая, что я делаю полные бэкапы только раз в две недели, а ежедневные — инкрементальные и загружаются меньше чем за час, и что я уже потратил на это несколько рабочих дней, то решил, что пока можно жить с этим ограничением.

Привет, sindy! Я вас понимаю. В общем, пропущенные ACK, а особенно повторные передачи фрагментированных пакетов заставляют механизм избегания перегрузки TCP запускать задержки передачи экспоненциально, из-за чего реально скорость передачи очень сильно падает, независимо от фактической загрузки канала.

Хотя, думаю, вы отчасти правы, мне кажется, это должно одинаково влиять на несколько TCP-потоков, как и на один. Процент потерь будет одинаковым, так что соотношение повторных передач к доставленным пакетам должно быть такое же. Но я такого поведения не наблюдаю.

С другой стороны, думаю, что поток с меньшей пропускной способностью, пострадавший от экспоненциальной задержки передачи или потери кадров, может быстрее восстанавливаться, поскольку общий объём байт для повторной передачи после одного события меньше. Однако это при условии, что потери равномерно распределены во времени. Если же нет, а обычно так бывает, это должно приводить к одновременному сбою нескольких потоков и сильным колебаниям доставки, чего я тоже не вижу. По крайней мере при использовании больше одного TCP соединения.

Только что быстро проверил:

1 поток = 2,4 Mbps
2 потока = 4,0 Mbps
4 потока = 6,2 Mbps
8 потоков = 8,3 Mbps

Для максимальной загрузки канала (10 Mbps, реально 9,5 Mbps) нужно 10 соединений. И при этом одно соединение способно максимально загрузить канал в другую сторону — 10 Mbps.

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

Но прошу, не переставайте выкладывать свои мысли!

sindy

Guest

29.08.2021 10:44:00

Публиковать особо нечего без входных данных (от вас и/или от кого-то ещё, кого затрагивает этот «гремлин») для анализа. Я проверил, в чём разница на стороне bandwidth-test между тестом с одним TCP-соединением и тестом с несколькими.

Если при тесте с одним соединением данные не проходят примерно 30 секунд (может, 32), тест завершается. А вот если в многосоединительном тесте один из потоков не получает данных длительное время (минуты), то не только сам тест не завершается, но и клиент, и сервер bandwidth-test продолжают пытаться восстановить этот поток и возобновляют его работу, если данные возобновляются. Пока этот поток «бодался», другие потоки занимают доступную полосу пропускания. Так что в многопотоковом тесте с достаточным количеством сессий всегда есть достаточно «здоровых» потоков, чтобы компенсировать потерю скорости на «сломанных» — независимо от причины.

Остальное — статистика.

Что касается потери пакетов, есть практическое различие: если потеря затрагивает только (или по большей части) фрагменты, меры по предотвращению фрагментации решают проблему; если же теряются и целые (нефрагментированные) пакеты, предотвратить фрагментацию — почти бесполезно.

Не тратьте слишком много времени: если вы используете что-то поверх IPsec, а передача файла занимает 30 часов, просто снимайте трафик в файл одновременно с обеих сторон в любой момент работы передачи, фильтруя по ip-address=ip.of.the.remote.peer. Минуты записи с каждой стороны хватит, чтобы понять, что происходит (начинаете запись на роутере А, потом на роутере Б, ждёте минуту, останавливаете запись на роутере Б, затем на роутере А).

А раз данные зашифрованы, анализ записей, который занимает много времени, можно перепоручить другим. Если хотите скрыть даже реальные IP-адреса в pcap-файлах — можно использовать для этого tracewrangler.

NetWorker Guest	#7 0 03.05.2022 13:34:00 Всем привет! Вчера мы подключились к новому провайдеру по симметричной линии GPON в нашем головном офисе (наконец-то дожили до техники уровня 2015 года, ха-ха). В общем, проблемы с VPN теперь решены. Виноват оказался наш провайдер DSL-линии. Так и не понял точно в чём была беда, но подозреваю, что дело в их pppoe-сервере или роутере, который работает по pppoe. Если у вас такая же проблема, то советую активно «докучать» техподдержке вашего провайдера, чтобы они действительно взялись за решение. Пока отмечаю эту проблему как решённую (хотя реального решения так и не предложили). Огромное спасибо bpwl и sindy за помощь!! Отменяю всё сказанное. Проблема вовсе не решена. Ужасающая ситуация затянулась настолько, что я даже забыл поставить количество tcp потоков в 1. И сразу подумал: «Вот дьявол, работает!» Но прошлой ночью, когда начал переносить бэкап, скорость всё равно была низкая — около 4.5 Мбит/с. Это немного лучше, чем было раньше. Задержка снизилась до стабильных 8 мс. По совету bpwl я решил просто настроить FTP-сервер и клиент, и при трёх одновременных передачах смог выжать максимум из 10 Мбит/с на удалённом офисе и за ночь (примерно 9 часов) залить всё — при том, что бэкапы опять выросли в размере. Когда ничего не помогает — возвращайся к основам, ха-ха. На данный момент подозреваю, что тут играет роль не один фактор. Возможно, имеет место TCP-конгестия. При возросшей нагрузке ЦП RB2011 едва справляется с шифрованием, а Wi-Fi-связь в удалённом офисе, которая по своей природе полудуплексная, и, возможно, ещё что-то — всё это мешает моей сетевой магии. Следующий шаг — вероятно, замена удалённого роутера на модель с аппаратным шифрованием, например, 3011 или аналогичной. Если когда-нибудь раскопаю, в чём правда, дам знать, а пока так и работаю.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры