Jump to content
Калькуляторы

Mikrotik SSTP низкая скорость Постоянно рвутся туннели, низкая скорость передачи файлов

Доброго времени суток уважаемые сетевики!

Имеется два микротика: RB1100AHx2 RouterOS 6.27 (дальше микротик1) и CCR1009 RouterOS 6.28 (дальше микротик2).

Микротик1 используется в качестве VPN-сервера, микротик2 - клиент. У сервера пропускная способность канала - 100 Мб/с, у клиента - 1 Гб/с.

 

При соединении по pptp (MTU/MRU 1450, comression, VJ compression, encryption) bandwidth test между девайсами по локальным адресам показывает около 100 Мб/с, а передача файлов по smb колеблется в пределах 50-95 Мб/с.

Если меняем тип соединения на sstp (MTU/MRU 1450, comression, VJ compression, encryption) bandwidth test проходит около 10 секунд и туннель падает. Скорость по smb тоже никакая (еле-еле доползает до 3 Мб/с).

При этом в статусе туннеля вижу, что сервер установил MTU/MRU 1450, а клиент MTU 1450, MRU 1500. Туннель постоянно рвется при более-менее нормальной загрузке канала (~3 Мб/с), если нагрузка небольшая туннель апнут. Такая же ситуация с одинаковыми девайсами и прошивками (с обеих сторон CCR1009, RouterOS 6.28)

 

Подскажите, в какую сторону копать. sstp устраивает в плане безопасности и универсальности, менять его на IPSec, OpenVPN не хочется, но если другого выхода нет, придется делать так, если, конечно, кто-то убедит, что эти варианты работают стабильнее и быстрее.

Данная схема проверялась на разных железках и разных версиях RouterOS. Результат везде одинаков. В динамическое правило change MSS on ppp interfaces не лезу. Возможно, проблема в неправильно выбранном роутеросью MSS?

Edited by devi11

Share this post


Link to post
Share on other sites

У вас проблема в том, что MRU - 1500 означает, что туннель сам фрагментирует пакеты, поэтому если будут потери или нарушится очередность их следования, туннель может обрываться. Поставьте везде значения 1300 и проверьте как работает. Если все нормально, повышайте до 1400 или 1460, в зависимости от максимального размера пакета через туннель. При этом пункты compression, VJ compression нужно поставить в NO и всегда их ставить в NO.

Share this post


Link to post
Share on other sites

Спасибо за совет! Проверю.

При этом пункты compression, VJ compression нужно поставить в NO и всегда их ставить в NO.

Можете аргументированно обосновать на что это влияет?

Share this post


Link to post
Share on other sites

Поставьте везде значения 1300 и проверьте как работает.

Сделал как Вы советовали. Но клиент и сервер не могут согласовать эти значения.

server: interface sstp-server server print

enabled: yes

port: 443

max-mtu: 1300

max-mru: 1300

mrru: disabled

keepalive-timeout: 20

default-profile: default

authentication: mschap2

certificate: none

verify-client-certificate: no

force-aes: no

pfs: no

 

server: interface sstp-server print detail where user=pub-RBEU

Flags: X - disabled, D - dynamic, R - running

0 DR name="<sstp-pub-RBEU>" user="pub-RBEU" mtu=1300

client-address="1.2.3.4" uptime=37s encoding="AES256-CBC"

Тут консоль не показывает MRU, в Winbox'е видно, interface - status - MRU 1300

 

client: interface sstp-client print detail

name="vpn2-pub4" max-mtu=1300 max-mru=1500 mrru=1600

connect-to=5.6.7.8:443 http-proxy=0.0.0.0:443 certificate=none

verify-server-certificate=no verify-server-address-from-certificate=yes

user="pub-RBEU" password="password" profile=default-encryption

keepalive-timeout=20 add-default-route=no dial-on-demand=no

authentication=mschap2 pfs=no

 

Это делалось на одинаковом железе и одинаковой RouterOS с обеих сторон (CCR1009 RouterOS 6.30.2)

Edited by devi11

Share this post


Link to post
Share on other sites

Тоже испытываю проблемы со скоростью SSTP,также у меня через SSTP не работают EoIP туннели. EoIP получилось запустить через PPtP и OpenVPN.

Share this post


Link to post
Share on other sites

Можете аргументированно обосновать на что это влияет?

 

Это влияет на все, что связано со стабильностью. На вкладке Protocols настроек профиля PPP все должно стоять в No.

В этом случае будет максимально надежный и стабильный канал.

Аргументировать тут нечего. Можно либо использовать этот совет, либо ловить проблемы.

 

client: interface sstp-client print detail

name="vpn2-pub4" max-mtu=1300 max-mru=1500 mrru=1600

connect-to=5.6.7.8:443 http-proxy=0.0.0.0:443 certificate=none

verify-server-certificate=no verify-server-address-from-certificate=yes

user="pub-RBEU" password="password" profile=default-encryption

keepalive-timeout=20 add-default-route=no dial-on-demand=no

authentication=mschap2 pfs=no

 

Это делалось на одинаковом железе и одинаковой RouterOS с обеих сторон (CCR1009 RouterOS 6.30.2)

 

Так вы вручную задайте параметры mrru и все заработает.

Share this post


Link to post
Share on other sites
Это влияет на все, что связано со стабильностью. На вкладке Protocols настроек профиля PPP все должно стоять в No. В этом случае будет максимально надежный и стабильный канал. Аргументировать тут нечего. Можно либо использовать этот совет, либо ловить проблемы.

Сколько ни крутил во фрёвом mpd5 эти компресии и прочие фишки, работало стабильно.

Share this post


Link to post
Share on other sites

Это влияет на все, что связано со стабильностью.

Каким образом? Раскрой тему?

Share this post


Link to post
Share on other sites

Так вы вручную задайте параметры mrru и все заработает.

Задавал, не помогло. Результаты в картинках ниже.

 

А про аргументацию я не ради "докопаться" спрашиваю. Просто привык осознанно вносить изменения в конфигурацию. Насколько я понимаю, если при отключении компрессий, соединение становится стабильнее, значит софт микротика некорректно обрабатывает пересборку сжатых пакетов и заголовков и поэтому сессия валится. Так?

post-115839-091771000 1438907629_thumb.jpg

post-115839-076098400 1438907764_thumb.jpg

Edited by devi11

Share this post


Link to post
Share on other sites

А про аргументацию я не ради "докопаться" спрашиваю. Просто привык осознанно вносить изменения в конфигурацию. Насколько я понимаю, если при отключении компрессий, соединение становится стабильнее, значит софт микротика некорректно обрабатывает пересборку сжатых пакетов и заголовков и поэтому сессия валится. Так?

 

У меня, например, часть абонентов подключены через PPPoE, и на сервере в настройках профиля везде стоит No.

Другая часть абонентов подключены через публичный интернет, там аналогичные настройки.

Везде где есть микротик, аналогичные настройки.

 

Далее второй вопрос - тест скорости как делали? Если вы указали максимальный размер пакета по туннелю 1450 байт, то и btest нужно делать пакетами такого же размера. Если на маленьких пакетах нормальная скорость, а на 1500 пакетах она плавает, при этом вами учтены накладные расходы на передачу довесков в виде 10 процентов от максимальной пропускной способности, то что-то не так с каналом передачи данных между микротиками. Часто такое бывает, когда в каждую сторону через интернет трафик идет по разным маршрутам, тогда и получается что в одну сторону скорость нормальная, а в другую очень низкая. Пожалуешься оператору, он там что-то подкрутит и нормально заработает.

Share this post


Link to post
Share on other sites

myst, не надо в общественном месте опускаться до хамства и нецензурщины.

Share this post


Link to post
Share on other sites

myst, не надо в общественном месте опускаться до хамства и нецензурщины.

Вот что-то ни хамства ни нецензурщены я не увидел. Лично мне реально интересны соображения по поводу влияния на стабильность у микротикак включенной компрессии.

Share this post


Link to post
Share on other sites

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

 

Компрессия всегда влияет на стабильность. Однако не ясно, для какой цели, практической, ее можно использовать. Сейчас в интернете все и так оптимизировано - картинки не сжимаются, флешки не сжимаются, видео и т.п. тоже не сжимается. Остается только описание страничек в текстовом виде, но на общем фоне передаваемых данных это довольно низкий процент.

 

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

Share this post


Link to post
Share on other sites

Компрессия всегда влияет на стабильность

Ответ домохозяйки а не IT специалиста. Как она влияет? Почему она влияет?

 

Сейчас в интернете все и так оптимизировано - картинки не сжимаются, флешки не сжимаются, видео и т.п. тоже не сжимается. Остается только описание страничек в текстовом виде, но на общем фоне передаваемых данных это довольно низкий процент.

Казалось бы причем тут интернет? Помимо подключения абонентиков к интернету у VPN (читаем как оно расшифровывается) есть и другое предназначение.

Share this post


Link to post
Share on other sites

Ответ домохозяйки а не IT специалиста. Как она влияет? Почему она влияет?

 

А ответ IP специалиста каким должен быть? Как вы думаете, упаковка работает с кадрами равным мту, или она агрегирует несколько пакетов передачи данных?

 

Казалось бы причем тут интернет? Помимо подключения абонентиков к интернету у VPN (читаем как оно расшифровывается) есть и другое предназначение.

 

Есть упаковка пакетов со сжатием, в микротике IP Packing, почему бы ее не использовать?

Share this post


Link to post
Share on other sites

А если на другой стороне не микротик? Плакал пакинг?

 

Да в таком случае и на PPP не всегда получится установить связь.

Share this post


Link to post
Share on other sites

А ответ IP специалиста каким должен быть?

Он должен на прямой технический вопрос содержать техническую информацию а не отговорку на уровне "ой все".

 

Есть упаковка пакетов со сжатием, в микротике IP Packing, почему бы ее не использовать?

Безумная идея с проприетарной технологией. От этого давным давно отказались даже крупные производители.

 

Да в таком случае и на PPP не всегда получится установить связь.

 

Фиеричный бред опять же на уровне домохозяйки. По какой причине кроме глючности микротика связь могла бы не установиться?

Share this post


Link to post
Share on other sites

Далее второй вопрос - тест скорости как делали? Если вы указали максимальный размер пакета по туннелю 1450 байт, то и btest нужно делать пакетами такого же размера. Если на маленьких пакетах нормальная скорость, а на 1500 пакетах она плавает, при этом вами учтены накладные расходы на передачу довесков в виде 10 процентов от максимальной пропускной способности, то что-то не так с каналом передачи данных между микротиками.

 

Скорость меряю передачей файлов по smb с винды по одну сторону VPN на винду по другую сторону. Получается такая схема WIN1<->Mikrotik1<->internet(SSTP)<->Mikrotik2<->WIN2

btest с размером 1500 показывает 90 Мб/с на белый адрес. Внутри тоннеля, естественно, тоннель ложится, как я и писал выше.

Share this post


Link to post
Share on other sites

Скорость меряю передачей файлов по smb с винды по одну сторону VPN на винду по другую сторону. Получается такая схема WIN1<->Mikrotik1<->internet(SSTP)<->Mikrotik2<->WIN2

btest с размером 1500 показывает 90 Мб/с на белый адрес. Внутри тоннеля, естественно, тоннель ложится, как я и писал выше.

 

Вам надо произвести следующие замеры:

1. Определить максимальный размер пакета, который проходит без фрагментации через туннель.

2. Сделать тест скорости на передачу с этим размером пакета, определить скорость. Например получили под 100 мегабит.

3. Сделать тот же тест, но на прием.

4. Установить ограничение в тесте на 90М и проверить еще раз, при этом можно запустить пинги, они не должны сильно увеличиваться, ведь у вас еще есть запас в 10 процентов.

5. Сделать те же тесты но пакетами 1500 байт, если тоннель ложится, убавить скорость до 90М, потом до 80М, найти ту, при которой пинги не увеличиваются.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this